On Sat, Feb 25, 2017 at 4:43 PM, Rob Clark <robdcl...@gmail.com> wrote:
> Probably a symptom of needing finer grained locking, but if we wait on
> the incoming fence-fd (which could come from a different context) while
> holding struct_mutex, that blocks retire_worker so gpu fences cannot get
> scheduled.
> This causes a problem if userspace manages to get more than a frame
> ahead, leaving the atomic-commit worker blocked waiting on fences that
> cannot be signaled because submit is blocked waiting for a fence
> signalled from vblank (after the atomic commit which is blocked).
> If we start having multiple fence ctxs for the gpu, submit_fence_sync()
> would probably need to move outside of struct_mutex as well.
> Signed-off-by: Rob Clark <robdcl...@gmail.com>

It's unfortunately not yet landed, but as soon as it's there I think
we should annotate fences using the cross-release stuff that's


That should be able to catch deps between waiter/signaller vs. locking.
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Freedreno mailing list

Reply via email to