On Mon, May 04, 2015 at 11:40:49PM +0000, Konduru, Chandra wrote: > > > > -----Original Message----- > > From: Daniel Vetter [mailto:daniel.vetter@xxxxxxxx] On Behalf Of Daniel Vetter > > Sent: Monday, May 04, 2015 8:01 AM > > To: Konduru, Chandra > > Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Vetter, Daniel; Syrjala, Ville > > Subject: Re: [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@xxxxxxxxx> > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
