On Thu, Feb 28, 2013 at 4:26 PM, Alex Deucher <alexdeuc...@gmail.com> wrote: > On Thu, Feb 28, 2013 at 4:05 AM, Marek Olšák <mar...@gmail.com> wrote: >> TF2 doesn't use CP DMA with this patch at all, so I'm not seeing any >> issue obviously. This patch is an optimization, not a workaround. It >> also doesn't affect CP DMA in any way. It only detects when a buffer >> range can be mapped without the CPU-GPU synchronization, which is the >> most efficient way of mapping a buffer (no GEM_WAIT_IDLE, no temporary >> staging resource, no copying in buffer_unmap). >> >> CP DMA is still probably not reliable with 6xx/7xx, but we won't be >> able to use TF2 anymore to test it. > > Well, it's possible there are hardware issues with it, but CP DMA has > been around since r100 and from what I can tell internally, it's > pretty reliable. I think the issue with TF2 were more circumstantial, > due to the combination of state and buffers (even streamout failed to > work correctly in those circumstances). Maybe a env var to > selectively enable it? I'm not pressed either way, just seems a shame > not to use it.
IIRC, this the status of the various methods and their reliability: R600: streamout - garbled screen with TF2 CP DMA - never enabled due to issues async DMA - never enabled due to issues R700: streamout - garbled screen with TF2 CP DMA - garbled screen with TF2 async DMA - works Evergreen: streamout - works CP DMA - works async DMA - works Considering that TF2 is fixed with this patch, I'll discard the patch disallowing DISCARD_RANGE handling on r6xx and the patch disallowing CP DMA on r7xx. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
