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