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. Which is fine so long as you get userspace to only use explicit fence passing to the compositor. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
