Re: [PATCH v16 5/7] drm/vkms: Create KUnit tests for YUV conversions

José Expósito
2025-01-31T16:57:39Z

On Fri, Jan 31, 2025 at 02:02:14PM +0100, Louis Chauvet wrote:
> On 31/01/25 - 09:41, José Expósito wrote:
> > Hi Louis,
> >
> > > From: Arthur Grillo <arthurgrillo@riseup.net>
> > >
> > > Create KUnit tests to test the conversion between YUV and RGB. Test each
> > > conversion and range combination with some common colors.
> > >
> > > The code used to compute the expected result can be found in comment.
> > >
> > > [Louis Chauvet:
> > > - fix minor formating issues (whitespace, double line)
> > > - change expected alpha from 0x0000 to 0xffff
> > > - adapt to the new get_conversion_matrix usage
> > > - apply the changes from Arthur
> > > - move struct pixel_yuv_u8 to the test itself]
> > >
> > > Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net>
> > > Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > > Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > ---
>
> [...]
>
> > > + /*
> > > + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> > > + * K=colour.WEIGHTS_YCBCR["ITU-R BT.709"],
> > > + * in_bits = 16,
> > > + * in_legal = False,
> > > + * in_int = True,
> > > + * out_bits = 8,
> > > + * out_legal = False,
> > > + * out_int = True)
> > > + * Test cases for conversion between YUV BT709 full range and RGB
> > > + * using the ITU-R BT.709 weights.
> > > + */
> > > + {
> > > + .encoding = DRM_COLOR_YCBCR_BT709,
> > > + .range = DRM_COLOR_YCBCR_FULL_RANGE,
> > > + .n_colors = 4,
> >
> > If I understood correctly, "n_colors" here indicates the number of items in
> > "colors", but there is a mismatch between both lengths.
> >
> > It also applies to the other test cases where "n_colors = 4".
>
> I don't know how I miss it, I am 100% sure I did the exact same comment to
> Arthur few mounth ago, thanks!
>
> > > + .colors = {
> > > + { "white", { 0xff, 0x80, 0x80 }, { 0xffff, 0xffff, 0xffff, 0xffff }},
> > > + { "gray", { 0x80, 0x80, 0x80 }, { 0xffff, 0x8080, 0x8080, 0x8080 }},
> > > + { "black", { 0x00, 0x80, 0x80 }, { 0xffff, 0x0000, 0x0000, 0x0000 }},
> > > + { "red", { 0x36, 0x63, 0xff }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
> > > + { "green", { 0xb6, 0x1e, 0x0c }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
> > > + { "blue", { 0x12, 0xff, 0x74 }, { 0xffff, 0x0000, 0x0000, 0xffff }},
> > > + },
> > > + },
> > > + /*
>
> [...]
>
> > > +/*
> > > + * vkms_format_test_yuv_u8_to_argb_u16 - Testing the conversion between YUV
> > > + * colors to ARGB colors in VKMS
> > > + *
> > > + * This test will use the functions get_conversion_matrix_to_argb_u16 and
> > > + * argb_u16_from_yuv888 to convert YUV colors (stored in
> > > + * yuv_u8_to_argb_u16_cases) into ARGB colors.
> > > + *
> > > + * The conversion between YUV and RGB is not totally reversible, so there may be
> > > + * some difference between the expected value and the result.
> > > + * In addition, there may be some rounding error as the input color is 8 bits
> > > + * and output color is 16 bits.
> > > + */
> > > +static void vkms_format_test_yuv_u8_to_argb_u16(struct kunit *test)
> > > +{
> > > + const struct yuv_u8_to_argb_u16_case *param = test->param_value;
> > > + struct pixel_argb_u16 argb;
> > > +
> > > + for (size_t i = 0; i < param->n_colors; i++) {
> > > + const struct format_pair *color = &param->colors[i];
> > > + struct conversion_matrix matrix;
> > > +
> > > + get_conversion_matrix_to_argb_u16
> > > + (DRM_FORMAT_NV12, param->encoding, param->range, &matrix);
> > > +
> > > + argb = argb_u16_from_yuv888(color->yuv.y, color->yuv.u, color->yuv.v, &matrix);
> >
> > Running the test on ppc64 (big endian) doesn't fail. For reference:
> >
> > $ sudo dnf install powerpc64-linux-gnu-gcc
> > $ sudo dnf install qemu-system-ppc64
> > $ ./tools/testing/kunit/kunit.py run \
> > --kunitconfig=drivers/gpu/drm/vkms/tests \
> > --arch=powerpc --cross_compile=powerpc64-linux-gnu- \
> > --make_options CF=-D__CHECK_ENDIAN__ \
> > --kconfig_add CONFIG_KASAN=y \
> > --kconfig_add CONFIG_KASAN_VMALLOC=y
> >
> > However, I wonder if endianness is correctly handled. I always find endianness
> > difficult to reason about, but I'll try my best to explain it.
> >
> > On a big endian architecture, color->yuv is stored in big endian. This might not
> > be an issue, because its components (y, u and v) are u8.
> > However, I think that the return value of argb_u16_from_yuv888(), which is the
> > result of argb_u16_from_u16161616(), is returned in big endian while it should
> > be little endian.
>
> The goal of `struct argb_u16` is to hide machine-specific issues. We want
> to be able to do addition, multiplication... without
> `le_from_cpu`/`cpu_to_le` everywhere.
>
> If you look at the rest of the vkms driver, we never do bit manipulation
> on `struct argb_u16`, only mathematical operations.
>
> > Since you are comparing argb.a (big endian) with color->argb.a (big endian) the
> > test succedess, but in this case it should fail because, if I remember
> > correctly, colors must be stored in little endian and therefore, the color
> > returned by argb_u16_from_yuv888() should be little endian.
>
> The colors are stored in a specific endian only in framebuffers, but in
> our case, this is not a framebuffer. For the `argb_u16_to_ARGB16161616`,
> you can see we use `cpu_to_le16` to store the data in the proper order.
>
> > If you replace this 4 KUNIT_EXPECT_LE_MSG() with KUNIT_EXPECT_MEMEQ(), all test
> > will fail, but you'll notice that the buffers printed in the error log are
> > different depending on the endianness (x86_64 vs ppc64).
> >
> > What do you think? Did I overlook the conversion?
>
> I think yes, but thanks to make me think about it, I will steal your
> command line to test on powerPC :)

Well, at least the command was useful :P Thanks for the explanation.
I have been looking with more detail into get_pixel_write_function()
and what you mention makes sense now.

Thanks!

> > Have a look to the tests present in drm_format_helper_test.c. They use different
> > functions (cpubuf_to_le32, le32buf_to_cpu, etc) to make sure that colors are
> > represented in little endian and that comparing the expected and actual results
> > happens in the same endian.
>
> Those tests are testing conversion "buffer to buffer", so yes, there is
> some endian-dependant issues.
>
> …