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

[Souza, Jose]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-HACK-Make-drm_atomic_helper_dirtyfb-non-blocking.patch
Type: text/x-patch
Size: 1244 bytes
Desc: 0001-HACK-Make-drm_atomic_helper_dirtyfb-non-blocking.patch
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20210913/02d44cea/attachment.bin>