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

[Christian König]

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.

Christian.

> -Daniel