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

From: "Christian König" <christian.koenig@amd.com>
To: Daniel Stone <daniel@fooishbar.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Steven Price <steven.price@arm.com>,
	"moderated list:DMA BUFFER SHARING FRAMEWORK"
	<linaro-mm-sig@lists.linaro.org>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>
Subject: Re: [Linaro-mm-sig] [PATCH 04/11] drm/panfrost: Fix implicit sync
Date: Fri, 21 May 2021 15:09:15 +0200	[thread overview]
Message-ID: <39aa30e4-2726-a0ba-3537-3be609dbc0b5@amd.com> (raw)
In-Reply-To: <CAPj87rOzV1mC=Nv2zfsYXrD4ARV7cmmJmkUCSwRSw1Ksy0k-aA@mail.gmail.com>

Am 21.05.21 um 14:54 schrieb Daniel Stone:
> On Fri, 21 May 2021 at 13:28, Christian König <christian.koenig@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