Re: [Intel-gfx] [PATCH xf86-video-intel 2/2] sna: Eliminate sna_mode_wants_tear_free()

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH xf86-video-intel 2/2] sna: Eliminate sna_mode_wants_tear_free()
Date: Wed, 29 Jan 2020 21:19:11 +0200	[thread overview]
Message-ID: <20200129191911.GY13686@intel.com> (raw)
In-Reply-To: <157590439302.6399.13307864068739805449@skylake-alporthouse-com>

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

So thinking about this thing again. If we go with the mappable vs. gtt
size check, what do we want to do with the meson/autoconf tearfree knob.
Just nuke it? Or maybe we want it to override all the heuristics?

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx