On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote: > Hi everyone, > > This set of patches tries to improve read after write hazard handling > for reservation objects. > > It allows us to specify for each shared fence if it represents a write > operation. > > Based on this the i915 driver is modified to always wait for all writes > before pageflip and the previously used workaround is removed from > amdgpu. Hm, I thought after the entire discussions we agreed again that it's _not_ the write hazard we want to track, but whether there's an exclusive fence that must be observed for implicit buffer sync. That's why it's called the exclusive fence, not the write fence! If you want multiple of those, I guess we could add those, but that doesn't really make sense - how exactly did you end up with multiple exclusive fences in the first place? i915 (and fwiw, any other driver) does _not_ want to observe all write fences attached to a dma-buf. We want to _only_ observe the single exclusive fence used for implicit buffer sync, which might or might not exist. Otherwise the entire point of having explicit sync and explicit fences in the atomic ioctl is out of the window and the use case of 2 draw/flip loops using a single buffer is defeated. Again: How exactly you construct that exclusive fences, and how exactly the kernel and userspace cooperate to figure out when to set the exclusive fences, is 100% up to amdgpu. If you do explicit sync by default, and only switch to implicit sync (and setting the exclusive fence) as needed, that's perfectly fine. No need at all to leak that into core code and confuse everyone that there's multiple exclusive fences they need to somehow observe. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
