[Mesa-dev] [PATCH 09/13] r300g, r600g, radeonsi: add support for ARB_buffer_storage

[Alex Deucher]

On Fri, Jan 31, 2014 at 7:05 AM, Marek Olšák <maraeo at gmail.com> wrote:
> I think we always flush the HDP cache after (before?) command submission.
>

The kernel flushes the HDP cache in the fence command sequence.

Alex

> This patch adds nothing new to the drivers - we have always had
> persistent buffer mappings for all buffers and it has always worked.
> The only thing this does is that persistent mappings are now also
> supported by Gallium and OpenGL.
>
> If there is a missing cache flush somewhere, the new
> ARB_buffer_storage piglit test will show it.
>
> Marek
>
> On Fri, Jan 31, 2014 at 2:04 AM, Michel Dänzer <michel at daenzer.net> wrote:
>> On Don, 2014-01-30 at 23:46 +0100, Fredrik Höglund wrote:
>>> On Thursday 30 January 2014, Marek Olšák wrote:
>>> > From: Marek Olšák <marek.olsak at amd.com>
>>> >
>>> > All GTT memory mappings are coherent and therefore can be persistent.
>>>
>>> As we discussed on IRC, I think there should be a comment somewhere
>>> explaining that VRAM mappings are uncached, so the memory_barrier
>>> implementations don't need to do anything for those.
>>
>> VRAM is mapped uncacheable by the CPU, but there is an HDP cache which
>> must be flushed to ensure coherency between the CPU and GPU. So I
>> suspect memory_barrier actually needs to flush the HDP cache for VRAM.
>>
>> I'm wondering about GTT mappings on AGP as well. I think we're using CPU
>> write-combining for those, so we probably need to flush the
>> write-combining buffers?
>>
>>
>> --
>> Earthling Michel Dänzer            |                  http://www.amd.com
>> Libre software enthusiast          |                Mesa and X developer
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev