[Intel-gfx] [Linaro-mm-sig] [PATCH 04/11] drm/panfrost: Fix implicit sync

[Christian König]

Am 21.05.21 um 14:54 schrieb Daniel Stone:
> On Fri, 21 May 2021 at 13:28, Christian König <christian.koenig at amd.com> wrote:
>> Am 21.05.21 um 14:22 schrieb Daniel Stone:
>>> Yeah, the 'second-generation Valhall' GPUs coming later this year /
>>> early next year are starting to get pretty weird. Firmware-mediated
>>> job scheduling out of multiple queues, userspace having direct access
>>> to the queues and can do inter-queue synchronisation (at least I think
>>> so), etc. For bonus points, synchronisation is based on $addr = $val
>>> to signal and $addr == $val to wait, with a separate fence primitive
>>> as well.
>> Well that sounds familiar :)
> I laughed when I first saw it, because it was better than crying I guess.

In Germany we say "Ich freue mich drauf wie auf Zahnschmerzen".

> If you're curious, the interface definitions are in the csf/ directory
> in the 'Bifrost kernel driver' r30p0 download you can get from the Arm
> developer site. Unfortunately the exact semantics aren't completely
> clear.

Well it is actually relatively simple. Take a look at the timeline 
semaphores from Vulkan, everybody is basically implementing the same 
semantics now.

When you queued up a bunch of commands on your hardware, the first one 
will write value 1 to a 64bit memory location, the second one will write 
value 2, the third value 3 and so on. After writing the value the 
hardware raises and interrupt signal to everybody interested.

In other words pretty standard memory fence behavior.

When you now have a second queue which depends on work of the first one 
you look at the memory location and do a compare. If you depend on the 
third submission you just wait for the value to be >3 and are done.

Regards,
Christian.

>
>>> Obviously Arm should be part of this conversation here, but I guess
>>> we'll have to wait for a while yet to see how everything's shaken out
>>> with this new gen, and hope that whatever's been designed upstream in
>>> the meantime is actually vaguely compatible ...
>> Yeah, going to keep you in CC when we start to code and review user fences.
> Awesome, thanks Christian. Appreciate it. :)
>
> Cheers,
> Daniel