On 09/08/2016 08:30 AM, Chris Wilson wrote:
On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote:
amdgpu-kms uses shared fences for its prime exported dmabufs,
instead of an exclusive fence. Therefore we need to wait for
all fences of the dmabuf reservation object to prevent
unsynchronized rendering and flipping.
No. Fix the root cause as this affects not just flips but copies -
this implies that everybody using the resv object must wait for all
fences. The resv object is not just used for prime, but all fencing, so
this breaks the ability to schedule parallel operations across engine.
-Chris
Ok. I think i now understand the difference, but let's check: The
exclusive fence is essentially acting a bit like a write-lock, and the
shared fences as readers-locks? So you can have multiple readers but
only one writer at a time?
Ie.:
Writer must wait for all fences before starting write access to a
buffer, then attach the exclusive fence and signal it on end of write
access. E.g., write to renderbuffer, write to texture etc.
Readers must wait for exclusive fence, then attach a shared fence per
reader and signal it on end of read access? E.g., read from texture, fb,
scanout?
Is that correct? In that case we'd have a missing exclusive fence in
amdgpu for the linear target dmabuf? Probably beyond my level of
knowledge to fix this?
thanks,
-mario
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
