summaryrefslogtreecommitdiff
path: root/src/gallium/drivers/r300/r300_context.c
AgeCommit message (Collapse)Author
2011-03-08r300g: decide whether a flush should be asynchronous when calling itMarek Olšák
Thread offloading is not sometimes desirable, e.g. when mapping a buffer.
2011-03-05r300g: cleanup parameters of draw functionsMarek Olšák
2011-03-04r300g: preliminary implementation of clamping controlsMarek Olšák
2011-03-04r300g: implement FP16 alpha testMarek Olšák
2011-03-02r300g: require DRM 2.3.0 (kernel 2.6.34)Marek Olšák
Running any older kernel is not recommended anyway.
2011-03-01r300g: initialize some r500 PS3 regsMarek Olšák
2011-03-01r300g: fix printing whether Z compression is enabledMarek Olšák
2011-03-01r300g: fix HiZ memory size computation and deciding when to use HiZMarek Olšák
I removed the HiZ memory management, because the HiZ RAM is too small and I also did it in hope that HiZ will be enabled more often. This also sets aligned strides to HIZ_PITCH and ZMASK_PITCH.
2011-02-28r300g: initialize SC_SCREENDOORMarek Olšák
2011-02-22r300g: fix missing initializers warningBrian Paul
2011-02-19r300g: fix a possible race when counting contextsMarek Olšák
Atomics aren't sufficient here.
2011-02-15r300g: implement fences using dummy relocationsMarek Olšák
So finally we have them.
2011-02-11r300g: import the last bits of libdrm and cleanup the whole thingMarek Olšák
Based on Dave's branch. The majority of this commit is a cleanup, mainly renaming things. There wasn't much code to import, just ioctl calls. Also done: - implemented unsynchronized bo_map (important optimization!) - radeon_bo_is_referenced_by_cs is no longer a refcount hack - dropped the libdrm_radeon dependency I'm surprised that this has resulted in less code in the end.
2011-02-10r300g: consolidate buffers and textures to r300_resourceMarek Olšák
Transfers and create/destroy are still handled separately.
2011-02-10r300g: simplify WRITE_RELOC API and cleanupMarek Olšák
2011-02-08r300g: use the same upload buffer for vertices and indicesMarek Olšák
2011-02-08u_vbuf_mgr: add a way to specify the BIND flag for the upload bufferMarek Olšák
2011-02-07r300g: use the new vertex buffer managerMarek Olšák
2011-01-30r300g: rework vertex format fallbackMarek Olšák
1) Only translate the [min_index, max_index] range. 2) Upload translated vertices via the uploader. 3) Rename valid_vertex_buffer[] to real_vertex_buffer[]
2011-01-27r300g: print driver info if RADEON_DEBUG=infoMarek Olšák
2011-01-27r300g: fix some bugs with zbuffer compression (v4)Marek Olšák
This drops the memblock manager for ZMASK. Instead, only one zbuffer can be compressed at a time. Note that this does not necessarily have to be slower. When there is a large number of zbuffers, compression might be used more often than it was before. It's also easier to debug. How it works: 1) 'clear' turns the compression on. 2) If some other zbuffer is set or the currently-bound zbuffer is used for texturing, the driver decompresses it and then turns the compression off. Notes: - The ZMASK clear has been refactored, so that only one packet3 is used to clear ZMASK. - The 8x8 compression mode is disabled. I couldn't make it work without issues. - Also removed driver-specific stuff from u_blitter. Driver status: - RV530 and R580 appear to just work (finally). - RV570 should work, but there may be an issue that we don't correctly calculate the number of dwords to clear, resulting in a partially uninitialized zbuffer. - RS690 misrenders as if no ZMASK clear happened. No idea what's going on. - RV350 may even hardlock. This issue was already present and this patch doesn't fix it. I think we are still missing some hardware info we need to make the zbuffer compression work fully. Note that there is also an issue with HiZ, resulting in a sort of blocky zigzagged corruption around some objects.
2011-01-24Revert "r300g/swtcl: re-enable LLVM"Jakob Bornecrantz
This reverts commit 88550083b3857184445075e70fed8b2eed4952a1.
2011-01-07r300g: derive user buffer sizes at draw timeMarek Olšák
This only uploads the [min_index, max_index] range instead of [0, userbuf size], which greatly speeds up user buffer uploads. This is also a prerequisite for atomizing vertex arrays in st/mesa.
2010-12-25r300g: increase the size of upload buffersMarek Olšák
2010-12-24r300g/swtcl: re-enable LLVMMarek Olšák
Based on a patch from Drill <drill87@gmail.com>. NOTE: This is a candidate for the 7.10 branch.
2010-12-22r300g: Remove unnecessary headers.Vinson Lee
2010-12-05r300g: optimize looping over atomsMarek Olšák
This also removes DBG_STATS (the stats can be obtained with valgrind instead).
2010-12-03r300g: fix buildMarek Olšák
2010-12-03r300g: Drop unnecessary castnobled
2010-12-03r300g: Abort if draw_create() failsnobled
The other drivers need to be updated to do this, too.
2010-12-03r300g: Abort if atom allocations failnobled
2010-11-30util: rename u_mempool -> u_slabMarek Olšák
2010-11-20r300g: fix rendering with no vertex elementsMarek Olšák
Fixes glsl-vs-point-size, although I meant to fix glsl-novertexdata. Since swrast fails glsl-novertexdata too, I guess it's a core issue.
2010-11-10r300g: rename has_hyperz -> can_hyperzMarek Olšák
2010-08-29r300g,u_blitter: use u_framebufferMarek Olšák
Removing another function duplication in u_blitter.
2010-08-25draw: specialized cliptesting routinesKeith Whitwell
2010-08-17r300g: fix context destroy under hyperzDave Airlie
we were destroying the mm before unrefing all the objects, so segfault. Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-08-16r300g: fix an invalid pointer in freeMarek Olšák
2010-08-16r300g: Let hyperz init failnobled
Signed-off-by: Marek Olšák <maraeo@gmail.com>
2010-08-16r300g: Fix leaks in failed context creationnobled
This changes r300_destroy_context() so it can be called on a partially-initialized context, and uses it when r300_create_context() hits a fatal error. This makes sure r300_create_context() doesn't leak memory or neglect to call r300_update_num_contexts() when it fails. Signed-off-by: Marek Olšák <maraeo@gmail.com>
2010-08-16r300g: Fix macronobled
This fixes a potential bug if (has_hyperz) is false (it would still init the atom as if has_hyperz were true). Signed-off-by: Marek Olšák <maraeo@gmail.com>
2010-08-06r300g: do not emit GB_Z_PEQ_CONFIG on non-r500 if DRM < 2.6.0Marek Olšák
2010-08-05r300g: always emit hyperz state atom.Dave Airlie
2010-08-05r300g: implement hyper-z support. (v4)Dave Airlie
This implements fast Z clear, Z compression, and HiZ support for r300->r500 GPUs. It also allows cbzb clears when fast Z clears are being used for the ZB. It requires a kernel with hyper-z support. Thanks to Marek Olšák <maraeo@gmail.com>, who started this off, and Alex Deucher at AMD for providing lots of hints. v2: squashed zmask ram size fix] squashed r300g/blitter: fix Z readback when compressed] v3: rebase around texture changes in master - .1 fix more bits v4: migrated to using u_mm in r300_texture to manage hiz/zmask rams consistently disabled HiZ when using OQ flush z-cache before turning hyper-z off update hyper-z state on dsa state change store depthclearvalue across cbzb clears and replace it afterwards. Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-07-19r300g: fix possible crash in destroy_contextMarek Olšák
The problem is destroy_context is almost NEVER called. The only test for destroy_context I know is compiz. Reported by Vinson Lee. FDO bug #29150.
2010-07-19r300g: fix typoMarek Olšák
2010-07-19r300g: use memory pools for buffer_create and get_transferMarek Olšák
The improvement in Tremulous: 68.9 fps -> 71.1 fps.
2010-07-16r300g: rebuild winsys and command submission to support multiple contextsMarek Olšák
2010-07-12r300g: implement fast color clearMarek Olšák
An initial implementation made by Dave Airlie. For it to be used, a color-only clear must be invoked and exactly one point-sampled render target must be set. The render target must be macrotiled (for us to overcome alignment issues) and bpp must be either 16 or 32. I can't see a difference in performance. :( Conflicts: src/gallium/drivers/r300/r300_blit.c
2010-07-12r300g: clear and copy a resource with a rectangular point spriteMarek Olšák
With an ordinary quad, the pixels on the main diagonal are computed and stored twice, which is somewhat inefficient and might not work well with specialized clear codepaths.