[Mesa-dev] [PATCH 5/5] r600g: always map uninitialized buffer range as unsynchronized

[Marek Olšák]

On Thu, Feb 28, 2013 at 4:26 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Thu, Feb 28, 2013 at 4:05 AM, Marek Olšák <maraeo at 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