[Intel-gfx] [PATCH 7/8] drm/i915/display/skl+: Drop frontbuffer rendering support

[Ville Syrjälä]

On Wed, Aug 25, 2021 at 12:49:25AM +0000, Souza, Jose wrote:
> On Thu, 2021-08-19 at 19:07 +0300, Ville Syrjälä wrote:
> > On Wed, Aug 18, 2021 at 07:48:03PM +0000, Souza, Jose wrote:
> > > On Wed, 2021-08-18 at 17:55 +0300, Ville Syrjälä wrote:
> > > > On Tue, Aug 17, 2021 at 05:42:15PM -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.
> > > > 
> > > > Blocking atomic commits instead of the current lightweight frontbuffer
> > > > interface sounds like a terrible plan. How unusable is X with this
> > > > approach?
> > > 
> > > 100% usable, had no issues when running X in TGL and ADL-P.
> > > Added a debug message in intel_user_framebuffer_dirty() and X is not even using frontbuffer rendering at all.
> > 
> > Turn off your compositor if you want to test front buffer rendering.
> 
> Worked fine on Plasma with a 4K panel, was not able to find how to do that in Gnome.

I didn't think you can turn off composition with either one of those.
You actually confirmed it's running with everytithing unredirected and
eg. there was no lag moving windows around and wiggling the mouse?

Avoiding that lag is pretty much the sole reason why the legacy
cursor unsynced update stuff even exists in the driver. Hard to
imagine you wouldn't hit the same issue with the server getting
blocked on dirtyfb all the time.

-- 
Ville Syrjälä
Intel