From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
Cc: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
"Syrjala, Ville" <ville.syrjala@intel.com>,
"Peres, Martin" <martin.peres@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t v5] lib/igt_fb: Added XYUV format support for testing
Date: Tue, 11 Sep 2018 18:47:38 +0300 [thread overview]
Message-ID: <20180911154738.GJ5565@intel.com> (raw)
In-Reply-To: <6673c3508863be8cdbfedb9453e6330bfeb13273.camel@intel.com>
On Tue, Sep 11, 2018 at 01:22:23PM +0000, Lisovskiy, Stanislav wrote:
> On Tue, 2018-09-11 at 15:50 +0300, Ville Syrjälä wrote:
> > On Tue, Sep 11, 2018 at 08:26:29AM +0000, Lisovskiy, Stanislav wrote:
> > > On Mon, 2018-09-10 at 13:03 +0300, Stanislav Lisovskiy wrote:
> > > > XYUV format support has been added to DRM, modified
> > > > IGT to reflect those changes.
> > > >
> > > > v2: Fixed merge conflict, started to use new yuv<=>rgb
> > > > conversion functions.
> > > >
> > > > v3: Fixed kms_available_modes_crc test to support new XYUV
> > > > format. Fixed a problem, where test complains that two
> > > > outputs might use same pipe at the same time.
> > > >
> > > > v4: Fixed convertion procedure in igt_fb to support XYUV
> > > > properly.
> > > >
> > > > v5: Fixed a coding typo.
> > >
> > > Minor comment: this change will fail all test cases where
> > > drmModeAddFB2 is called with DRM_FORMAT_XYUV until correspondent
> > > kernel patch is not in use, as many igt test cases do not check
> > > if that kernel format is supported or not, so drmModeAddFB2 will
> > > simply fail.
> >
> > Which tests are those? They should be fixed.
>
> Those are:
>
> igt@kms_flip@basic-flip-vs-dpms
>
> igt@kms_flip@basic-flip-vs-modeset
>
> igt@kms_flip@basic-flip-vs-wf_vblank
>
> igt@kms_flip@basic-plain-flip
>
> igt@kms_setmode@basic-clone-single-crtc
>
> Probably good idea to fix it so that it chooses only formats
> specified in drm_plane->formats and igt_fb_supported_format, like in
> kms_plane.
> Otherwise for example in kms_flip, it uses igt_bpp_depth_to_drm_format
> which chooses any format with matching bpp and depth, which in case of
> XRGB8888, also is the same for XYUV.
IIRC all YUV formats should have a depth of -1 in that table, pretty
much exactly for this reason. You never want to pick an YUV format when
just specifying depth/bpp.
>
>
> > > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com
> > > > >
> > > > ---
> > > > include/drm-uapi/drm_fourcc.h | 1 +
> > > > lib/igt_fb.c | 89
> > > > +++++++++++++++++++++++++++++++++++
> > > > 2 files changed, 90 insertions(+)
> > > >
> > > > diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-
> > > > uapi/drm_fourcc.h
> > > > index e04613d3..0bf66de2 100644
> > > > --- a/include/drm-uapi/drm_fourcc.h
> > > > +++ b/include/drm-uapi/drm_fourcc.h
> > > > @@ -112,6 +112,7 @@ extern "C" {
> > > > #define DRM_FORMAT_VYUY fourcc_code('V', 'Y',
> > > > 'U',
> > > > 'Y') /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> > > >
> > > > #define DRM_FORMAT_AYUV fourcc_code('A', 'Y',
> > > > 'U',
> > > > 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > > > +#define DRM_FORMAT_XYUV fourcc_code('X', 'Y',
> > > > 'U',
> > > > 'V') /* [31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
> > > >
> > > > /*
> > > > * 2 plane RGB + A
> > > > diff --git a/lib/igt_fb.c b/lib/igt_fb.c
> > > > index ae71d967..b60b73b4 100644
> > > > --- a/lib/igt_fb.c
> > > > +++ b/lib/igt_fb.c
> > > > @@ -72,6 +72,10 @@ static struct format_desc_struct {
> > > > .cairo_id = CAIRO_FORMAT_RGB16_565,
> > > > .num_planes = 1, .plane_bpp = { 16, },
> > > > },
> > > > + { .name = "XYUV", .depth = 24, .drm_id =
> > > > DRM_FORMAT_XYUV,
> > > > + .cairo_id = CAIRO_FORMAT_RGB24,
> > > > + .num_planes = 1, .plane_bpp = { 32, },
> > > > + },
> > > > { .name = "XRGB8888", .depth = 24, .drm_id =
> > > > DRM_FORMAT_XRGB8888,
> > > > .cairo_id = CAIRO_FORMAT_RGB24,
> > > > .num_planes = 1, .plane_bpp = { 32, },
> > > > @@ -415,6 +419,10 @@ static int create_bo_for_fb(int fd, int
> > > > width,
> > > > int height,
> > > > memset(ptr + offsets[1], 0x80,
> > > > calculated_stride *
> > > > height/2);
> > > > break;
> > > > + case DRM_FORMAT_XYUV:
> > > > + wmemset(ptr, full_range ?
> > > > 0x000f8080
> > > > : 0x000f8080,
> > > > + calculated_stride *
> > > > height /
> > > > sizeof(wchar_t));
> > > > + break;
> > > > case DRM_FORMAT_YUYV:
> > > > case DRM_FORMAT_YVYU:
> > > > wmemset(ptr, full_range ?
> > > > 0x80008000
> > > > : 0x80108010,
> > > > @@ -1500,6 +1508,79 @@ static void convert_nv12_to_rgb24(struct
> > > > igt_fb *fb, struct fb_convert_blit_uplo
> > > > free(buf);
> > > > }
> > > >
> > > > +static void convert_yuv444_to_rgb24(struct igt_fb *fb, struct
> > > > fb_convert_blit_upload *blit)
> > > > +{
> > > > + int i, j;
> > > > + uint8_t *yuv24;
> > > > + uint8_t *rgb24 = blit->rgb24.map;
> > > > + unsigned rgb24_stride = blit->rgb24.stride,
> > > > planar_stride =
> > > > blit->linear.stride;
> > > > + uint8_t *buf = malloc(blit->linear.size);
> > > > + struct igt_mat4 m = igt_ycbcr_to_rgb_matrix(fb-
> > > > > color_encoding,
> > > >
> > > > + fb-
> > > > > color_range);
> > > >
> > > > +
> > > > + /*
> > > > + * Reading from the BO is awfully slow because of lack
> > > > of
> > > > read caching,
> > > > + * it's faster to copy the whole BO to a temporary
> > > > buffer
> > > > and convert
> > > > + * from there.
> > > > + */
> > > > + igt_memcpy_from_wc(buf, blit->linear.map, blit-
> > > > > linear.size);
> > > >
> > > > + yuv24 = &buf[blit->linear.offsets[0]];
> > > > +
> > > > + for (i = 0; i < fb->plane_height[0]; i++) {
> > > > + for (j = 0; j < fb->plane_width[0]; j++) {
> > > > + float y, u, v;
> > > > + struct igt_vec4 yuv;
> > > > + struct igt_vec4 rgb;
> > > > +
> > > > + v = yuv24[i * planar_stride +
> > > > j*sizeof(uint32_t)];
> > > > + u = yuv24[i * planar_stride +
> > > > j*sizeof(uint32_t) + 1];
> > > > + y = yuv24[i * planar_stride +
> > > > j*sizeof(uint32_t) + 2];
> > > > + yuv.d[0] = y;
> > > > + yuv.d[1] = u;
> > > > + yuv.d[2] = v;
> > > > + yuv.d[3] = 1.0f;
> > > > +
> > > > + rgb = igt_matrix_transform(&m, &yuv);
> > > > +
> > > > + write_rgb(&rgb24[i * rgb24_stride +
> > > > j*sizeof(uint32_t)], &rgb);
> > > > + }
> > > > + }
> > > > +
> > > > + free(buf);
> > > > +}
> > > > +
> > > > +
> > > > +static void convert_rgb24_to_yuv444(struct igt_fb *fb, struct
> > > > fb_convert_blit_upload *blit)
> > > > +{
> > > > + int i, j;
> > > > + uint8_t *rgb24;
> > > > + uint8_t *yuv444 = blit->linear.map;
> > > > + unsigned rgb24_stride = blit->rgb24.stride,
> > > > planar_stride =
> > > > blit->linear.stride;
> > > > + struct igt_mat4 m = igt_rgb_to_ycbcr_matrix(fb-
> > > > > color_encoding,
> > > >
> > > > + fb-
> > > > > color_range);
> > > >
> > > > +
> > > > + rgb24 = blit->rgb24.map;
> > > > +
> > > > + for (i = 0; i < fb->plane_height[0]; i++) {
> > > > + for (j = 0; j < fb->plane_width[0]; j++) {
> > > > + struct igt_vec4 rgb;
> > > > + struct igt_vec4 yuv;
> > > > + float y, u, v;
> > > > +
> > > > + read_rgb(&rgb, &rgb24[i * rgb24_stride +
> > > > j*sizeof(uint32_t)]);
> > > > +
> > > > + yuv = igt_matrix_transform(&m, &rgb);
> > > > +
> > > > + yuv444[i * planar_stride +
> > > > j*sizeof(uint32_t)] = yuv.d[2];
> > > > + yuv444[i * planar_stride +
> > > > j*sizeof(uint32_t) + 1] = yuv.d[1];
> > > > + yuv444[i * planar_stride +
> > > > j*sizeof(uint32_t) + 2] = yuv.d[0];
> > > > + }
> > > > + }
> > > > +}
> > > > +
> > > > +
> > > > +
> > > > +
> > > > static void convert_rgb24_to_nv12(struct igt_fb *fb, struct
> > > > fb_convert_blit_upload *blit)
> > > > {
> > > > int i, j;
> > > > @@ -1756,6 +1837,9 @@ static void
> > > > destroy_cairo_surface__convert(void
> > > > *arg)
> > > > case DRM_FORMAT_VYUY:
> > > > convert_rgb24_to_yuyv(fb, blit, yuyv_swizzle(fb-
> > > > > drm_format));
> > > >
> > > > break;
> > > > + case DRM_FORMAT_XYUV:
> > > > + convert_rgb24_to_yuv444(fb, blit);
> > > > + break;
> > > > default:
> > > > igt_assert_f(false, "Conversion not implemented
> > > > for
> > > > formats 0x%x\n",
> > > > fb->drm_format);
> > > > @@ -1809,6 +1893,9 @@ static void
> > > > create_cairo_surface__convert(int
> > > > fd, struct igt_fb *fb)
> > > > case DRM_FORMAT_VYUY:
> > > > convert_yuyv_to_rgb24(fb, blit, yuyv_swizzle(fb-
> > > > > drm_format));
> > > >
> > > > break;
> > > > + case DRM_FORMAT_XYUV:
> > > > + convert_yuv444_to_rgb24(fb, blit);
> > > > + break;
> > > > default:
> > > > igt_assert_f(false, "Conversion not implemented
> > > > for
> > > > formats 0x%x\n",
> > > > fb->drm_format);
> > > > @@ -1825,6 +1912,7 @@ static void
> > > > create_cairo_surface__convert(int
> > > > fd, struct igt_fb *fb)
> > > > blit,
> > > > destroy_cairo_surface__convert);
> > > > }
> > > >
> > > > +
> > > > /**
> > > > * igt_get_cairo_surface:
> > > > * @fd: open drm file descriptor
> > > > @@ -2011,6 +2099,7 @@ bool igt_format_is_yuv(uint32_t drm_format)
> > > > case DRM_FORMAT_YVYU:
> > > > case DRM_FORMAT_UYVY:
> > > > case DRM_FORMAT_VYUY:
> > > > + case DRM_FORMAT_XYUV:
> > > > return true;
> > > > default:
> > > > return false;
> > >
> > > --
> > > Best Regards,
> > >
> > > Lisovskiy Stanislav
> > > _______________________________________________
> > > igt-dev mailing list
> > > igt-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> >
> >
> --
> Best Regards,
>
> Lisovskiy Stanislav
--
Ville Syrjälä
Intel
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2018-09-11 15:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-10 10:03 [igt-dev] [PATCH i-g-t v5] lib/igt_fb: Added XYUV format support for testing Stanislav Lisovskiy
2018-09-10 16:29 ` [igt-dev] ✗ Fi.CI.BAT: failure for lib/igt_fb: Added XYUV format support for testing (rev5) Patchwork
2018-09-11 8:26 ` [igt-dev] [PATCH i-g-t v5] lib/igt_fb: Added XYUV format support for testing Lisovskiy, Stanislav
2018-09-11 12:50 ` Ville Syrjälä
2018-09-11 13:22 ` Lisovskiy, Stanislav
2018-09-11 15:47 ` Ville Syrjälä [this message]
2018-09-12 7:25 ` Lisovskiy, Stanislav
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180911154738.GJ5565@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=martin.peres@intel.com \
--cc=stanislav.lisovskiy@intel.com \
--cc=ville.syrjala@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.