[Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support

[Ville Syrjälä]

On Wed, Sep 15, 2021 at 06:57:19PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 15, 2021 at 04:48:49PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 13, 2021 at 10:54:14PM +0000, Souza, Jose wrote:
> > > On Thu, 2021-09-09 at 23:28 +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 09, 2021 at 08:23:20PM +0000, Souza, Jose wrote:
> > > > > On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote:
> > > > > > On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> > > > > > > By now all the userspace applications should have migrated to atomic
> > > > > > > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> > > > > > > 
> > > > > > > With that we can kill frontbuffer rendering support in i915 for
> > > > > > > modern platforms.
> > > > > > > 
> > > > > > > So here converting legacy APIs into atomic commits so it can be
> > > > > > > properly handled by driver i915.
> > > > > > > 
> > > > > > > Several IGT tests will fail with this changes, because some tests
> > > > > > > were stressing those frontbuffer rendering scenarios that no userspace
> > > > > > > should be using by now, fixes to IGT should be sent soon.
> > > > > > > 
> > > > > > 
> > > > > > I just gave this a try here and it's unusable. glxgears went from
> > > > > > 9000 to 120 fps (was expecting 60fps tbh, not sure why I get
> > > > > > double), everything lags like mad, if I drag a window around
> > > > > > glxgears/other windows stop updating entirely, etc. NAK
> > > > > 
> > > > > Can you share your setup? What GPU? Desktop environment? Mesa version? resolutions of sinks?
> > > > > Will try it in my end.
> > > > 
> > > > Doesn't really matter as long as you don't have a compositor making a
> > > > mess of things. This machine is a cfl running mate w/ compositor off,
> > > > and some 1920x1200 display.
> > > > 
> > > 
> > > Making drm_atomic_helper_dirtyfb() do a non-blocking atomic commit makes user experience pretty similar to the one with compositing enabled:
> > > drm_atomic_commit() + compositor off: https://youtu.be/NBt6smXs99U
> > > drm_atomic_nonblocking_commit() + compositor off: https://youtu.be/QiMhkeGX_L8
> > > drm_atomic_nonblocking_commit() + compositor on: https://youtu.be/KdpJyJ5k6sQ
> > > 
> > > 
> > > I do not completly agree with the comment in drm_atomic_helper_dirtyfb() about why it uses a blocking implementation.
> > > With frontbuffer rendering the registers are programmed but the content could only show up for user a whole frame later.
> > > 
> > > Perhaps if this solutions is accetable we could have a non-blocking version of drm_atomic_helper_dirtyfb() so the drivers current using it don't have
> > > their behavior changed.
> > 
> > Non-blocking update would make sense to me, whereas a blocking
> > update makes no sense given how this is used by actual userspace.
> 
> Actually neither maybe makes total sense since userspace probably
> isn't expecting -EBUSY from dirtyfb. So we might end up with stale
> junk on the screen if no further updates come in after an -EBUSY.

One option would be to teach userspace to retry after an -EBUSY, but
without a completion event from dirtyfb it's going to be hard to know
when to retry.

> 
> The current frontbuffer stuff works much more like a mailbox style
> update so we don't lose stuff and neither do we block.

I suppose the obvious solution would be to teach kms to do proper
mailbox updates. But that is not entirely trivial. One way to simplify
the proposal a bit is to limit it to pure pageflips, which would
suffice for dirtyfb as well obviously. That way watermarks and other
potentially tricky stuff wouldn't change.

But actually figuring out the proper commit sequence for this might
take some doing. The way I think it should work is that we just let
each commit through without blocking on the previous one. A later
commit may simply overwrite the hardware registers before the
values written by the previous commit get latched. The vblank evasion
stuff would make it perfectly safe.

The hardest thing there is probably figuring out how to handle all
the pre/post_plane_update() stuff  properly since we can't know
ahead of time whether the flip gets latched or not, and so we can't
really use the old state during state computation to make any
decisions affecting our future behaviour. But given that async flips
are more or less working today might mean that I'm worried about nothing.
Either that or async flips are in fact broken in some funny ways I've not
yet realized...

The other problem for actual mailbox page flips is completion events/out
fences. The current out fence I think is not really suitable for cases
where a flip ends up getting overwritten by a later one, and thus the
fb rotation no longer follows the normal fifo order. But of we don't
expose actual mailbox page flips through the uapi then we could avoid
worrying about this stuff initially.

-- 
Ville Syrjälä
Intel