[Intel-gfx] [PATCH xf86-video-intel 2/2] sna: Eliminate sna_mode_wants_tear_free()
Ville Syrjälä
ville.syrjala at linux.intel.com
Mon Dec 9 15:43:42 UTC 2019
On Mon, Dec 09, 2019 at 03:13:13PM +0000, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-12-09 15:01:37)
> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >
> > The modparam checks performed by sna_mode_wants_tear_free() don't
> > generally work when the server is running as a regular user. Hence
> > we can't rely on them to indicate whether FBC/PSR/etc is enabled.
> > A lso the "Panel Self-Refresh" connector property doesn't actually
> > exist so we can nuke that part as well. Let's just nuke the whole
> > thing and assume we want dirtyfb always when tearfree is not enabled.
> >
> > I'll anyway want to enable FBC by default across the board soonish
> > so the check wouldn't really buy us much (would just exclude i830
> > and a few old desktop chipsets which don't have FBC hardware).
> >
> > Additionally if we don't have working dirtyfb we really should
> > enable tearfree by default because otherwise we're going to
> > get horrible lag due to missing frontbuffer flushes.
>
> But we also want to enable TearFree anyway in most cases, and here we
> are defaulting to off in cases where it was already on.
>
> I still don't know on what grounds the cut-off should be based, the
> primary question is can we afford to keep an extra framebuffer plus any
> gubbins memory? The worry about perf are now larger moot, so it boils
> down to available memory -- in quite a few cases TearFree is a big
> improvement on power management, but that I guess is currently snb+
> (although we can fix ilk render powerstandby).
>
> How about GTT > mappable aperture, based on the idea that we have room
> to spare that can't be used for scanout? That would only disable gen2 by
> default.
Not sure. Ideally we should perhaps make it dynamic and enable tearfree
only when the extra framebuffers won't hog too much of the gtt/physical
RAM? But since it's not dynamic currently I guess that would involve
some actual work.
--
Ville Syrjälä
Intel
More information about the Intel-gfx
mailing list