Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
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?
Maybe you misunderstood me, we don't have multiple exclusive fences.
What we have are multiple writers which write to the BO. In other words
multiple engines which compose the content of the BO at the same time.
For page flipping we need to wait for all of them to completed.
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.
What do you mean with that?
Even for the atomic IOCTL with implicit fencing I strongly suspect that
we can wait for multiple fences before doing the flip. Otherwise it
would not really be useful to us.
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.
I simply never have a single exclusive fence provided by userspace.
I always have multiple command submissions accessing the buffer at the
same time.
See to me the explicit fence in the reservation object is not even
remotely related to implicit or explicit synchronization.
Regards,
Christian.
Cheers, Daniel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel