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

[Daniel Vetter]

On Fri, Aug 10, 2018 at 10:24 AM, Christian König
<christian.koenig at amd.com> wrote:
> 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 at 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.

Fences can be merge. This works, really :-) In amdgpu's implementation
of EGL_ANDROID_native_fence_sync you will need to do that before
passing the result to the caller.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch