[Intel-gfx] [PATCH] drm/i915: Adding dbuf support for skl nv12 format.

[Daniel Vetter]

On Mon, May 04, 2015 at 11:40:49PM +0000, Konduru, Chandra wrote:
> 
> 
> > -----Original Message-----
> > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel Vetter
> > Sent: Monday, May 04, 2015 8:01 AM
> > To: Konduru, Chandra
> > Cc: intel-gfx at lists.freedesktop.org; Vetter, Daniel; Syrjala, Ville
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Adding dbuf support for skl nv12
> > format.
> > 
> > On Mon, Apr 27, 2015 at 03:47:37PM -0700, Chandra Konduru wrote:
> > > Skylake nv12 format requires dbuf (aka. ddb) calculations and
> > > programming for each of y and uv sub-planes. Made minor changes to
> > > reuse current dbuf calculations and programming for uv plane. i.e.,
> > > with this change, existing computation is used for either packed
> > > format or uv portion of nv12 depending on incoming format. Added new
> > > code for dbuf computation and programming for y plane.
> > >
> > > This patch is a pre-requisite for adding NV12 format support.
> > > Actual nv12 support is coming in later patches.
> > >
> > > Signed-off-by: Chandra Konduru <chandra.konduru at intel.com>
> > 
> > Just aside (and not a blocker for this patch really). Do we have nv12 subtest in all
> > the relevant plane tests (rotation, scaling, ...) to exercise this code? Not sure
> > whether we can redo the yuv->rgb conversion correctly in software to match
> > hw, might need to pick special colors that convert accurately.
> > 
> > Anyway given how often we've broken the sprite code I really think we need full
> > functional tests (i.e. including crc checks).
> 
> I have written an i-g-t test kms_nv12 to test/exercise this patch and 
> subsequent NV12 patch series which was submitted last week after
> this patch. It tests nv12 along with rotation, scaling and does
> some crc checks. 
> But because chrome upsampling is done using scaler which uses multiple taps,
> crcs aren't going to match with original reference flip with RGB format. I tried with 
> simple solid color. Can you please take a look that?

Oh right the upsampling will result in a smudge when we change visible
colors, so the 4 color pattern used for checking rotation doesn't work.
Just an idea (without yet looking at your code):
- Create a tall&narrow sprite view, and a big buffer which would fit that
  sprite view in any orentiation.
- Only draw a slice exactly matching the sprite view (horizontal/vertical)
  in one solid color, leave the remaining buffer black.

That way we can at least do some basic checks to make sure the
rotation/alignment is correct. We won't be able to detect when the buffer
is mirrored wrongly, but at least we'll have some coverage.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch