Am 10.08.2018 um 10:32 schrieb Daniel Vetter:
On Fri, Aug 10, 2018 at 10:24 AM, Christian König
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
Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
See to me the explicit fence in the reservation object is not even
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
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.
dri-devel mailing list