On Thu, Feb 28, 2013 at 11:11 AM, Marek Olšák <mar...@gmail.com> wrote: > 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.
Sounds good. Any objections to enabling CP DMA on 6xx via my previous patch set? Alex _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
