Re: [PATCH 5/7] drm/i915: fix FBC buffer size checks

From: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
To: "chris@chris-wilson.co.uk" <chris@chris-wilson.co.uk>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 5/7] drm/i915: fix FBC buffer size checks
Date: Wed, 30 Sep 2015 20:10:32 +0000	[thread overview]
Message-ID: <1443643831.2212.47.camel@intel.com> (raw)
In-Reply-To: <20150923165949.GN6739@nuc-i3427.alporthouse.com>

Em Qua, 2015-09-23 às 17:59 +0100, Chris Wilson escreveu:
> On Wed, Sep 23, 2015 at 12:52:25PM -0300, Paulo Zanoni wrote:
> > According to my experiments, the maximum sizes mentioned in the
> > specification delimit how far in the buffer the hardware tracking
> > can
> > go. And the hardware seems to calculate the size based on the plane
> > address and x/y offsets we specify to it. So adjust the code to do
> > the
> > proper checks.
> > 
> > On platforms that do the x/y offset adjustment trick it will be
> > really
> > hard to reproduce a bug, but on the current SKL we can reproduce
> > the
> > bug with igt/kms_frontbuffer_tracking/fbc-farfromfence. With this
> > patch, we'll go from "CRC assertion failure" to "FBC unexpectedly
> > disabled", which is still a failure on the test suite but is not a
> > perceived user bug - you will just not save as much power as you
> > could
> > be if FBC is disabled.
> > 
> > Testcase: igt/kms_frontbuffer_tracking/fbc-farfromfence (SKL)
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> 
> Same query again for using src_[wh].

After clarification from the HW guys (which CCd you), I wrote new
versions of these patches.

>  Do we have tests for FBC + panel
> fitting?

The --use-small-modes option forces a 1024x768 mode for eDP, which
triggers the panel fitter in case its native resolution is not
1024x768. This is not the default option, but I run it eventually.

For this specific patch, the real "failure" is when you do a GTT write
and then the hardware tracking doesn't detect it and you end with a CRC
error.

For the other patch that's related with sizes (the CFB size patch) what
we need is a stolen memory checker, like we have for slabs: allocate an
extra page at the exact end of the CFB, write magic bits to it, enable
FBC, check if the magic bits are still there.

> 
> Did I miss some explanation in the code that isn't visible in the
> diffs?
> -Chris
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx