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

[Daniel Vetter]

On Fri, Aug 10, 2018 at 10:51 AM, Christian König
<christian.koenig at amd.com> wrote:
> Am 10.08.2018 um 10:32 schrieb 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.
>
> Yeah, but that is for the userspace API. Not for any internal handling in
> the driver.

dma_fence_array? Or how do you think this fence merging for userspace
is implemented?

The only trouble is that amdgpu doesn't have an explicit hand-over
point in the uapi where an explicitly synced buffer (all of them
really) gets its fences for implicit syncing attached.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch