Re: [PATCH] drm: Don't allow legacy cursor updates to stall others or be stalled

From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH] drm: Don't allow legacy cursor updates to stall others or be stalled
Date: Tue, 23 Aug 2016 13:35:03 +0200	[thread overview]
Message-ID: <20160823113503.GC10980@phenom.ffwll.local> (raw)
In-Reply-To: <20160823112644.GJ20834@nuc-i3427.alporthouse.com>

On Tue, Aug 23, 2016 at 12:26:44PM +0100, Chris Wilson wrote:
> On Tue, Aug 23, 2016 at 11:48:34AM +0100, Chris Wilson wrote:
> > Legacy cursor updates are entirely asynchronous with respect to all
> > other users of the atomic pipeline. They neither wait for any
> > outstanding flips, nor do they cause subsequent flips to be delayed. The
> > only ordering we do require is given by making the legacy cursor update
> > nonblocking (so the sequence of userspace calls from a process is
> > ordered from the pov of the client).
> 
> Hmm, it is also not entirely true. A modeset (reconfiguration of the
> pipe size) would require all cursor updates to be flushed, or else we
> may make the cursor out-of-bounds which can cause GPU hangs. At the
> moment, I think that is governed by the crtc lock and the blocking
> nature of the modeset + cursor update. But in the future we want far
> more fine grained control over (mostly) asynchronous updates.

Yup, that's why I chickened out of fixing this properly ;-) What we could
do is set a flag that it's a modeset in drm_crtc_commit, and hand a flag
to stall_check to only look for modeset updates. Entirely elliding isn't a
good idea.

The other issue is how to order cursor updates through the legacy update
ioctl against atomic updates on the plane. Not that userspace should mix
those, but it could, and we need to make sure they're ordered properly.
This is especially painful when watermarks have changed, which is entirely
driver-dependent.

At that point it's probably time to ragequit.

Aside: i915 atomic commit is atm stalling way too much, it signals hw_done
too late. Iirc I've sprinkled a fixme into either the commit or code about
what needs to be done for that. Legacy cursor updates with hw_done
signalled early enough (i.e. when we wrote the register, before the hw has
committed the update) should fix this stalling issue too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx