On Fri, Aug 10, 2018 at 10:51 AM, Christian König <christian.koenig@xxxxxxx> 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@xxxxxxx> 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@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
