Re: [PATCH 6/7] drm/radeon: allow asynchronous waiting on foreign fences

["Christian König" <deathsimple@vodafone.de>]

> I need to check the docs how to do this correctly,
The docs don't really cover this case.

For the GPU waiting on an address there is an extra document just for 
this case which I don't have at hand right now. But IIRC it was 
recommended to use the local memory of the device waiting on the 
semaphore. I'm just not sure if that's for pure performance reasons to 
avoid accessing the bus or if there's a hard and unavoidable hardware 
reason to do so.

For the GPU signaling case there is a special bit in the semaphore 
instructions that you need to set if any user outside of the GPU should 
see the write.

In general it is explicitly supported to use semaphores for inter device 
synchronization on the bus (that's what the block is made for), but it's 
not intended to be used for synchronization between the CPU and the 
device. So I'm not sure if things like cache snooping is implemented and 
correctly supported.

Well I see the feature more like nice to have and needs a bunch of 
testing, so I would say either wait with the patch for now or make it 
optional to use or something like that.

Regards,
Christian.

Am 04.09.2014 um 14:25 schrieb Christian König:
> Am 04.09.2014 um 14:08 schrieb Maarten Lankhorst:
>> Hey,
>>
>> Op 04-09-14 om 13:54 schreef Christian König:
>>> Am 04.09.2014 um 13:42 schrieb Maarten Lankhorst:
>>>> Use the semaphore mechanism to make this happen, this uses signaling
>>>> from the cpu instead of signaling by the gpu.
>>> I'm not sure if this will work reliable when the semaphores are in 
>>> system memory. We might need to reserve some VRAM for them instead.
>>>
>>> Regards,
>>> Christian.
>> Why would it be unreliable? I mostly kept it in semaphore for 
>> simplicity.
>
> The semaphore block tries to avoid memory accesses whenever possible.
>
> For example when a signal for address A arrives the block doesn't 
> necessary writes that to memory but instead tries to match it 
> immediately with a wait for address A. Similar is true if a wait for 
> address A arrives and the semaphore block thinks it knows the memory 
> value at address A.
>
> Also I'm not sure if the semaphore block really polls the memory 
> address for changes, instead it might just snoop the MC for writes to 
> this address. Since CPU writes to system memory aren't seen by the GPU 
> MC the semaphore block would never know something changed.
>
> I need to check the docs how to do this correctly,
> Christian.
>
>>
>> ~Maarten
>>
>