Re: [Intel-gfx] RFC: Add write flag to reservation object fences

From: "Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>
To: Chris Wilson
	<chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>,
	Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
Cc: intel-gfx
	<intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	amd-gfx list
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [Intel-gfx] RFC: Add write flag to reservation object fences
Date: Fri, 10 Aug 2018 10:24:08 +0200	[thread overview]
Message-ID: <4e16823b-ea25-47ff-f2f5-ef2425a08b83@amd.com> (raw)
In-Reply-To: <153388746770.6849.17431969057959926472@skylake-alporthouse-com>

Am 10.08.2018 um 09:51 schrieb Chris Wilson:
> Quoting Christian König (2018-08-09 15:54:31)
>> Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
>>> On Thu, Aug 9, 2018 at 3:58 PM, Christian König
>>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>>> Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
>>>>> On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
>>>>> [SNIP]
>>>> See to me the explicit fence in the reservation object is not even remotely
>>>> related to implicit or explicit synchronization.
>>> Hm, I guess that's the confusion then. The only reason we have the
>>> exclusive fence is to implement cross-driver implicit syncing. What
>>> else you do internally in your driver doesn't matter, as long as you
>>> keep up that contract.
>>>
>>> And it's intentionally not called write_fence or anything like that,
>>> because that's not what it tracks.
>>>
>>> Of course any buffer moves the kernel does also must be tracked in the
>>> exclusive fence, because userspace cannot know about these. So you
>>> might have an exclusive fence set and also an explicit fence passed in
>>> through the atomic ioctl. Aside: Right now all drivers only observe
>>> one or the other, not both, so will break as soon as we start moving
>>> shared buffers around. At least on Android or anything else using
>>> explicit fencing.
>> Actually both radeon and nouveau use the approach that shared fences
>> need to wait on as well when they don't come from the current driver.
> nouveau has write hazard tracking in its api , and is using the
> excl fence for it was well.
>
> As far as I can tell, this is all about fixing the lack of
> acknowledgement of the requirement for implicit fence tracking in
> amdgpu's (and its radeon predecessor) ABI.

Well I agree that implicit fencing was a bad idea to begin with, but the 
solution you guys came up with is not going to work in all cases either.

> Which is fine so long as you
> get userspace to only use explicit fence passing to the compositor.

Well exactly that's the problem.

I can't pass exactly one explicit fence to the compositor because I have 
multiple command submissions which run asynchronously and need to finish 
before the compositor can start to use the surface.

So the whole concept of using a single exclusive fence doesn't work in 
the case of amdgpu. And to be honest I think all drivers with multiple 
engines could benefit of that as well.

Christian.

> -Chris

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx