[igt-dev] [PATCH i-g-t 7/8] igt: fb: Fallback on KMS dumb buffer allocation for YUV buffers

[Ville Syrjälä]

On Fri, Dec 07, 2018 at 04:29:54PM +0100, Maxime Ripard wrote:
> On Tue, Dec 04, 2018 at 09:32:05PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 04, 2018 at 11:08:22AM +0100, Maxime Ripard wrote:
> > > The current YUV buffer allocation only works on the i915 driver, since
> > > it uses some private ioctl. However, we can to use that code on other
> > > drivers that implement only KMS, so if the driver is something else
> > > than the i915 driver, let's allocate a dumb buffer.
> > > 
> > > Signed-off-by: Maxime Ripard <maxime.ripard at bootlin.com>
> > > ---
> > >  lib/igt_fb.c | 35 +++++++++++++++++++++++++++++++++--
> > >  1 file changed, 33 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/lib/igt_fb.c b/lib/igt_fb.c
> > > index d6242a6652f1..f2e6c89f3884 100644
> > > --- a/lib/igt_fb.c
> > > +++ b/lib/igt_fb.c
> > > @@ -501,6 +501,8 @@ static int i915_create_gem_for_fb(struct igt_fb *fb)
> > >  
> > >  static int create_yuv_bo_for_fb(struct igt_fb *fb)
> > >  {
> > > +	unsigned int virtual_height;
> > > +	unsigned int bpp;
> > >  	uint64_t size = calc_fb_size(fb);
> > >  	int fd = fb->fd;
> > >  
> > > @@ -511,8 +513,37 @@ static int create_yuv_bo_for_fb(struct igt_fb *fb)
> > >  	if (is_i915_device(fd))
> > >  		return i915_create_gem_for_fb(fb);
> > >  
> > > -	/* We cannot allocate any other buffer type */
> > > -	igt_assert(true);
> > > +	switch (fb->drm_format) {
> > > +	case DRM_FORMAT_NV12:
> > > +		bpp = 8;
> > > +		break;
> > > +
> > > +	case DRM_FORMAT_UYVY:
> > > +	case DRM_FORMAT_VYUY:
> > > +	case DRM_FORMAT_YUYV:
> > > +	case DRM_FORMAT_YVYU:
> > > +		bpp = 16;
> > > +		break;
> > > +
> > > +	default:
> > > +		igt_assert_f(false, "Unsupported YUV format\n");
> > > +	}
> > > +
> > > +	switch (fb->drm_format) {
> > > +	case DRM_FORMAT_NV12:
> > > +		virtual_height = fb->height * 3 / 2;
> > > +		break;
> > 
> > A bit of a hack. The main problem with this is that the kernel won't
> > know anything about any stride alignment limitations etc. If we do use
> > this hack I guess it would be more technically correct to write it as
> > DIV_ROUND_UP(fb->size, fb->stride[0]), or something along those lines.
> 
> It's the same algorithm that modetest is using, which is why I went
> for that. It must have been tested on a wide variety of platforms.

People actually use modetest?

Anyways, I guess it's sort of correct in the sense that we override
fb->strides[0] and fb->size based on the data returned from the
crerate_dumb ioctl. Though DIV_ROUND_UP(height * 3, 2) would
seem like a sane idea anyway.

But what's missing is the handling for the nv12 chroma plane. We'd
probably want to rewrite offsets[1] and strides[1] as well. Although
we'll still be totally guessing since the kernel wasn't told that
we want NV12 and so there's is no guarantee that it'll accept the
resulting fb.

> 
> > Which also brings me to the other issue we have. calc_plane_stride()
> > and calc_plane_size() are somewhat i915 specific. We should probably
> > do something about that.
> 
> Ah, right, I missed that.
> 
> When will we start to put some intel specific code in a generic code
> path?

Do you mean stop? Hopefully we've already stopped.

-- 
Ville Syrjälä
Intel