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

[Souza, Jose]

On Wed, 2021-09-15 at 19:49 +0300, Ville Syrjälä wrote:
> 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.

1000 dirtyfb calls will only have a different dirty areas, when executing a dirtyfb atomic commit we could append all the pending dirty areas into
this atomic commit and remove all the pending dirtyfb atomic commits.
I doubt that userspace will be able to fill WQ_MAX_ACTIVE dirtyfb calls in one single frame.

> 
> 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.
>