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

[Christian König]

> Is there a way to do the HDP flush at the bottom of the pipe? Can this
> be fixed in the kernel?

I'm not 100% sure, but I don't think so. As far as I know the only thing 
you can do on the bottom of the pipe is writing a fence/timestamp value 
or signaling a semaphore (the different EOP events).

> For now, it would be safer to use GTT for all persistent mappings.
> I'll update the patch.

That sounds like a good idea anyway. Persistent mappings seems to make 
only sense with stuff that is accessed allot by the CPU and VRAM isn't a 
good choice for that.

Christian.

Am 02.02.2014 19:29, schrieb Marek Olšák:
> Is there a way to do the HDP flush at the bottom of the pipe? Can this
> be fixed in the kernel?
>
> For now, it would be safer to use GTT for all persistent mappings.
> I'll update the patch.
>
> Marek
>
> On Sat, Feb 1, 2014 at 11:58 AM, Christian König
> <deathsimple at vodafone.de> wrote:
>> Am 31.01.2014 21:36, schrieb 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.
>>
>> But we do this at the top of the pipe instead of the bottom and then
>> silently assume that between the top and the bottom the CPU isn't accessing
>> this VRAM buffer.
>>
>> At least theoretically this can lead to a problem if the CPU wants to read a
>> buffer value that's in the same cache line as a value the GPU writes. For
>> example if a stupid application tries something like
>> "while(!value_written_by_GPU_in_VRAM);" this won't work correctly.
>>
>> Christian.
>>
>>
>>> 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
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>