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

[Alex Deucher]

On Thu, Feb 28, 2013 at 11:11 AM, Marek Olšák <maraeo at gmail.com> wrote:
> 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.

Sounds good.  Any objections to enabling CP DMA on 6xx via my previous
patch set?

Alex