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>
---
drivers/gpu/drm/vkms/Kconfig | 15 ++
drivers/gpu/drm/vkms/Makefile | 1 +
drivers/gpu/drm/vkms/tests/.kunitconfig | 4 +
drivers/gpu/drm/vkms/tests/Makefile | 3 +
drivers/gpu/drm/vkms/tests/vkms_format_test.c | 271 ++++++++++++++++++++++++++
drivers/gpu/drm/vkms/vkms_formats.c | 7 +-
drivers/gpu/drm/vkms/vkms_formats.h | 5 +
7 files changed, 304 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/Kconfig b/drivers/gpu/drm/vkms/Kconfig
index 9def079f685bd30e1df3e4082e4818e402395391..d4665e913de7702fbd5c0f047876dad9715c690a 100644
--- a/drivers/gpu/drm/vkms/Kconfig
+++ b/drivers/gpu/drm/vkms/Kconfig
@@ -14,3 +14,18 @@ config DRM_VKMS
a VKMS.
If M is selected the module will be called vkms.
+
+config DRM_VKMS_KUNIT_TESTS
+ tristate "KUnit tests for VKMS." if !KUNIT_ALL_TESTS
+ depends on DRM_VKMS && KUNIT
+ default KUNIT_ALL_TESTS
+ help
+ This builds unit tests for VKMS. This option is not useful for
+ distributions or general kernels, but only for kernel
+ developers working on VKMS.
+
+ For more information on KUnit and unit tests in general,
+ please refer to the KUnit documentation in
+ Documentation/dev-tools/kunit/.
+
+ If in doubt, say "N".
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 1b28a6a32948b557867dda51d2ccfdea687a2b62..8d3e46dde6350558a0aab4254df0dfe863f9c6ce 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -9,3 +9,4 @@ vkms-y := \
vkms_writeback.o
obj-$(CONFIG_DRM_VKMS) += vkms.o
+obj-$(CONFIG_DRM_VKMS_KUNIT_TESTS) += tests/
diff --git a/drivers/gpu/drm/vkms/tests/.kunitconfig b/drivers/gpu/drm/vkms/tests/.kunitconfig
new file mode 100644
index 0000000000000000000000000000000000000000..70e378228cbdaa025f01641f207a93a6c01f0853
--- /dev/null
+++ b/drivers/gpu/drm/vkms/tests/.kunitconfig
@@ -0,0 +1,4 @@
+CONFIG_KUNIT=y
+CONFIG_DRM=y
+CONFIG_DRM_VKMS=y
+CONFIG_DRM_VKMS_KUNIT_TESTS=y
diff --git a/drivers/gpu/drm/vkms/tests/Makefile b/drivers/gpu/drm/vkms/tests/Makefile
new file mode 100644
index 0000000000000000000000000000000000000000..2d1df668569e4f243ed9a06c1e16e595c131c4f6
--- /dev/null
+++ b/drivers/gpu/drm/vkms/tests/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_DRM_VKMS_KUNIT_TESTS) += vkms_format_test.o
diff --git a/drivers/gpu/drm/vkms/tests/vkms_format_test.c b/drivers/gpu/drm/vkms/tests/vkms_format_test.c
new file mode 100644
index 0000000000000000000000000000000000000000..aa81347ddce2288933abc2ff5b79f0ee11ff4271
--- /dev/null
+++ b/drivers/gpu/drm/vkms/tests/vkms_format_test.c
@@ -0,0 +1,271 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <kunit/test.h>
+
+#include <drm/drm_fixed.h>
+#include <drm/drm_fourcc.h>
+
+#include "../../drm_crtc_internal.h"
+
+#include "../vkms_formats.h"
+
+#define TEST_BUFF_SIZE 50
+
+MODULE_IMPORT_NS("EXPORTED_FOR_KUNIT_TESTING");
+
+struct pixel_yuv_u8 {
+ u8 y, u, v;
+};
+
+/*
+ * struct yuv_u8_to_argb_u16_case - Reference values to test the color
+ * conversions in VKMS between YUV to ARGB
+ *
+ * @encoding: Encoding used to convert RGB to YUV
+ * @range: Range used to convert RGB to YUV
+ * @n_colors: Count of test colors in this case
+ * @format_pair.name: Name used for this color conversion, used to
+ * clarify the test results
+ * @format_pair.rgb: RGB color tested
+ * @format_pair.yuv: Same color as @format_pair.rgb, but converted to
+ * YUV using @encoding and @range.
+ */
+struct yuv_u8_to_argb_u16_case {
+ enum drm_color_encoding encoding;
+ enum drm_color_range range;
+ size_t n_colors;
+ struct format_pair {
+ char *name;
+ struct pixel_yuv_u8 yuv;
+ struct pixel_argb_u16 argb;
+ } colors[TEST_BUFF_SIZE];
+};
+
+/*
+ * The YUV color representation were acquired via the colour python framework.
+ * Below are the function calls used for generating each case.
+ *
+ * For more information got to the docs:
+ * https://colour.readthedocs.io/en/master/generated/colour.RGB_to_YCbCr.html
+ */
+static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
+ /*
+ * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
+ * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
+ * in_bits = 16,
+ * in_legal = False,
+ * in_int = True,
+ * out_bits = 8,
+ * out_legal = False,
+ * out_int = True)
+ *
+ * Test cases for conversion between YUV BT601 full range and RGB
+ * using the ITU-R BT.601 weights.
+ */
+ {
+ .encoding = DRM_COLOR_YCBCR_BT601,
+ .range = DRM_COLOR_YCBCR_FULL_RANGE,
+ .n_colors = 6,
+ .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", { 0x4c, 0x55, 0xff }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
+ { "green", { 0x96, 0x2c, 0x15 }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
+ { "blue", { 0x1d, 0xff, 0x6b }, { 0xffff, 0x0000, 0x0000, 0xffff }},
+ },
+ },
+ /*
+ * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
+ * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
+ * in_bits = 16,
+ * in_legal = False,
+ * in_int = True,
+ * out_bits = 8,
+ * out_legal = True,
+ * out_int = True)
+ * Test cases for conversion between YUV BT601 limited range and RGB
+ * using the ITU-R BT.601 weights.
+ */
+ {
+ .encoding = DRM_COLOR_YCBCR_BT601,
+ .range = DRM_COLOR_YCBCR_LIMITED_RANGE,
+ .n_colors = 6,
+ .colors = {
+ { "white", { 0xeb, 0x80, 0x80 }, { 0xffff, 0xffff, 0xffff, 0xffff }},
+ { "gray", { 0x7e, 0x80, 0x80 }, { 0xffff, 0x8080, 0x8080, 0x8080 }},
+ { "black", { 0x10, 0x80, 0x80 }, { 0xffff, 0x0000, 0x0000, 0x0000 }},
+ { "red", { 0x51, 0x5a, 0xf0 }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
+ { "green", { 0x91, 0x36, 0x22 }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
+ { "blue", { 0x29, 0xf0, 0x6e }, { 0xffff, 0x0000, 0x0000, 0xffff }},
+ },
+ },
+ /*
+ * 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,
+ .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 }},
+ },
+ },
+ /*
+ * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
+ * K=colour.WEIGHTS_YCBCR["ITU-R BT.709"],
+ * in_bits = 16,
+ * int_legal = False,
+ * in_int = True,
+ * out_bits = 8,
+ * out_legal = True,
+ * out_int = True)
+ * Test cases for conversion between YUV BT709 limited range and RGB
+ * using the ITU-R BT.709 weights.
+ */
+ {
+ .encoding = DRM_COLOR_YCBCR_BT709,
+ .range = DRM_COLOR_YCBCR_LIMITED_RANGE,
+ .n_colors = 4,
+ .colors = {
+ { "white", { 0xeb, 0x80, 0x80 }, { 0xffff, 0xffff, 0xffff, 0xffff }},
+ { "gray", { 0x7e, 0x80, 0x80 }, { 0xffff, 0x8080, 0x8080, 0x8080 }},
+ { "black", { 0x10, 0x80, 0x80 }, { 0xffff, 0x0000, 0x0000, 0x0000 }},
+ { "red", { 0x3f, 0x66, 0xf0 }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
+ { "green", { 0xad, 0x2a, 0x1a }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
+ { "blue", { 0x20, 0xf0, 0x76 }, { 0xffff, 0x0000, 0x0000, 0xffff }},
+ },
+ },
+ /*
+ * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
+ * K=colour.WEIGHTS_YCBCR["ITU-R BT.2020"],
+ * in_bits = 16,
+ * in_legal = False,
+ * in_int = True,
+ * out_bits = 8,
+ * out_legal = False,
+ * out_int = True)
+ * Test cases for conversion between YUV BT2020 full range and RGB
+ * using the ITU-R BT.2020 weights.
+ */
+ {
+ .encoding = DRM_COLOR_YCBCR_BT2020,
+ .range = DRM_COLOR_YCBCR_FULL_RANGE,
+ .n_colors = 4,
+ .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", { 0x43, 0x5c, 0xff }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
+ { "green", { 0xad, 0x24, 0x0b }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
+ { "blue", { 0x0f, 0xff, 0x76 }, { 0xffff, 0x0000, 0x0000, 0xffff }},
+ },
+ },
+ /*
+ * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
+ * K=colour.WEIGHTS_YCBCR["ITU-R BT.2020"],
+ * in_bits = 16,
+ * in_legal = False,
+ * in_int = True,
+ * out_bits = 8,
+ * out_legal = True,
+ * out_int = True)
+ * Test cases for conversion between YUV BT2020 limited range and RGB
+ * using the ITU-R BT.709 weights.
+ */
+ {
+ .encoding = DRM_COLOR_YCBCR_BT2020,
+ .range = DRM_COLOR_YCBCR_LIMITED_RANGE,
+ .n_colors = 4,
+ .colors = {
+ { "white", { 0xeb, 0x80, 0x80 }, { 0xffff, 0xffff, 0xffff, 0xffff }},
+ { "gray", { 0x7e, 0x80, 0x80 }, { 0xffff, 0x8080, 0x8080, 0x8080 }},
+ { "black", { 0x10, 0x80, 0x80 }, { 0xffff, 0x0000, 0x0000, 0x0000 }},
+ { "red", { 0x4a, 0x61, 0xf0 }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
+ { "green", { 0xa4, 0x2f, 0x19 }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
+ { "blue", { 0x1d, 0xf0, 0x77 }, { 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 = ¶m->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);
+
+ KUNIT_EXPECT_LE_MSG(test, abs_diff(argb.a, color->argb.a), 0x1ff,
+ "On the A channel of the color %s expected 0x%04x, got 0x%04x",
+ color->name, color->argb.a, argb.a);
+ KUNIT_EXPECT_LE_MSG(test, abs_diff(argb.r, color->argb.r), 0x1ff,
+ "On the R channel of the color %s expected 0x%04x, got 0x%04x",
+ color->name, color->argb.r, argb.r);
+ KUNIT_EXPECT_LE_MSG(test, abs_diff(argb.g, color->argb.g), 0x1ff,
+ "On the G channel of the color %s expected 0x%04x, got 0x%04x",
+ color->name, color->argb.g, argb.g);
+ KUNIT_EXPECT_LE_MSG(test, abs_diff(argb.b, color->argb.b), 0x1ff,
+ "On the B channel of the color %s expected 0x%04x, got 0x%04x",
+ color->name, color->argb.b, argb.b);
+ }
+}
+
+static void vkms_format_test_yuv_u8_to_argb_u16_case_desc(struct yuv_u8_to_argb_u16_case *t,
+ char *desc)
+{
+ snprintf(desc, KUNIT_PARAM_DESC_SIZE, "%s - %s",
+ drm_get_color_encoding_name(t->encoding), drm_get_color_range_name(t->range));
+}
+
+KUNIT_ARRAY_PARAM(yuv_u8_to_argb_u16, yuv_u8_to_argb_u16_cases,
+ vkms_format_test_yuv_u8_to_argb_u16_case_desc
+);
+
+static struct kunit_case vkms_format_test_cases[] = {
+ KUNIT_CASE_PARAM(vkms_format_test_yuv_u8_to_argb_u16, yuv_u8_to_argb_u16_gen_params),
+ {}
+};
+
+static struct kunit_suite vkms_format_test_suite = {
+ .name = "vkms-format",
+ .test_cases = vkms_format_test_cases,
+};
+
+kunit_test_suite(vkms_format_test_suite);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Kunit test for vkms format conversion");
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c
index 1f3ce4f334be9560e62c9a7fd933fa0ed6640e8f..0b867444999105262c855a24bf03bc66d9ebea1b 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -7,6 +7,8 @@
#include <drm/drm_rect.h>
#include <drm/drm_fixed.h>
+#include <kunit/visibility.h>
+
#include "vkms_formats.h"
/**
@@ -247,8 +249,8 @@ static struct pixel_argb_u16 argb_u16_from_RGB565(const __le16 *pixel)
return out_pixel;
}
-static struct pixel_argb_u16 argb_u16_from_yuv888(u8 y, u8 channel_1, u8 channel_2,
- const struct conversion_matrix *matrix)
+VISIBLE_IF_KUNIT struct pixel_argb_u16 argb_u16_from_yuv888(u8 y, u8 channel_1, u8 channel_2,
+ const struct conversion_matrix *matrix)
{
u16 r, g, b;
s64 fp_y, fp_channel_1, fp_channel_2;
@@ -278,6 +280,7 @@ static struct pixel_argb_u16 argb_u16_from_yuv888(u8 y, u8 channel_1, u8 channel
return argb_u16_from_u16161616(0xffff, r, g, b);
}
+EXPORT_SYMBOL_IF_KUNIT(argb_u16_from_yuv888);
/*
* The following functions are read_line function for each pixel format supported by VKMS.
diff --git a/drivers/gpu/drm/vkms/vkms_formats.h b/drivers/gpu/drm/vkms/vkms_formats.h
index d583855cb32027d16b73d2a5b5a0644b13191d08..b4fe62ab9c65d465925d29911f26612193a80799 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.h
+++ b/drivers/gpu/drm/vkms/vkms_formats.h
@@ -13,4 +13,9 @@ void get_conversion_matrix_to_argb_u16(u32 format, enum drm_color_encoding encod
enum drm_color_range range,
struct conversion_matrix *matrix);
+#if IS_ENABLED(CONFIG_KUNIT)
+struct pixel_argb_u16 argb_u16_from_yuv888(u8 y, u8 channel_1, u8 channel_2,
+ const struct conversion_matrix *matrix);
+#endif
+
#endif /* _VKMS_FORMATS_H_ */
--
2.47.1Hi 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>
> ---
> drivers/gpu/drm/vkms/Kconfig | 15 ++
> drivers/gpu/drm/vkms/Makefile | 1 +
> drivers/gpu/drm/vkms/tests/.kunitconfig | 4 +
> drivers/gpu/drm/vkms/tests/Makefile | 3 +
> drivers/gpu/drm/vkms/tests/vkms_format_test.c | 271 ++++++++++++++++++++++++++
> drivers/gpu/drm/vkms/vkms_formats.c | 7 +-
> drivers/gpu/drm/vkms/vkms_formats.h | 5 +
> 7 files changed, 304 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/Kconfig b/drivers/gpu/drm/vkms/Kconfig
> index 9def079f685bd30e1df3e4082e4818e402395391..d4665e913de7702fbd5c0f047876dad9715c690a 100644
> --- a/drivers/gpu/drm/vkms/Kconfig
> +++ b/drivers/gpu/drm/vkms/Kconfig
> @@ -14,3 +14,18 @@ config DRM_VKMS
> a VKMS.
>
> If M is selected the module will be called vkms.
> +
> +config DRM_VKMS_KUNIT_TESTS
> + tristate "KUnit tests for VKMS." if !KUNIT_ALL_TESTS
> + depends on DRM_VKMS && KUNIT
> + default KUNIT_ALL_TESTS
> + help
> + This builds unit tests for VKMS. This option is not useful for
> + distributions or general kernels, but only for kernel
> + developers working on VKMS.
> +
> + For more information on KUnit and unit tests in general,
> + please refer to the KUnit documentation in
> + Documentation/dev-tools/kunit/.
> +
> + If in doubt, say "N".
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> index 1b28a6a32948b557867dda51d2ccfdea687a2b62..8d3e46dde6350558a0aab4254df0dfe863f9c6ce 100644
> --- a/drivers/gpu/drm/vkms/Makefile
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -9,3 +9,4 @@ vkms-y := \
> vkms_writeback.o
>
> obj-$(CONFIG_DRM_VKMS) += vkms.o
> +obj-$(CONFIG_DRM_VKMS_KUNIT_TESTS) += tests/
> diff --git a/drivers/gpu/drm/vkms/tests/.kunitconfig b/drivers/gpu/drm/vkms/tests/.kunitconfig
> new file mode 100644
> index 0000000000000000000000000000000000000000..70e378228cbdaa025f01641f207a93a6c01f0853
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/tests/.kunitconfig
> @@ -0,0 +1,4 @@
> +CONFIG_KUNIT=y
> +CONFIG_DRM=y
> +CONFIG_DRM_VKMS=y
> +CONFIG_DRM_VKMS_KUNIT_TESTS=y
> diff --git a/drivers/gpu/drm/vkms/tests/Makefile b/drivers/gpu/drm/vkms/tests/Makefile
> new file mode 100644
> index 0000000000000000000000000000000000000000..2d1df668569e4f243ed9a06c1e16e595c131c4f6
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/tests/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +obj-$(CONFIG_DRM_VKMS_KUNIT_TESTS) += vkms_format_test.o
> diff --git a/drivers/gpu/drm/vkms/tests/vkms_format_test.c b/drivers/gpu/drm/vkms/tests/vkms_format_test.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..aa81347ddce2288933abc2ff5b79f0ee11ff4271
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/tests/vkms_format_test.c
> @@ -0,0 +1,271 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include <kunit/test.h>
> +
> +#include <drm/drm_fixed.h>
> +#include <drm/drm_fourcc.h>
> +
> +#include "../../drm_crtc_internal.h"
> +
> +#include "../vkms_formats.h"
> +
> +#define TEST_BUFF_SIZE 50
> +
> +MODULE_IMPORT_NS("EXPORTED_FOR_KUNIT_TESTING");
> +
> +struct pixel_yuv_u8 {
> + u8 y, u, v;
> +};
> +
> +/*
> + * struct yuv_u8_to_argb_u16_case - Reference values to test the color
> + * conversions in VKMS between YUV to ARGB
> + *
> + * @encoding: Encoding used to convert RGB to YUV
> + * @range: Range used to convert RGB to YUV
> + * @n_colors: Count of test colors in this case
> + * @format_pair.name: Name used for this color conversion, used to
> + * clarify the test results
> + * @format_pair.rgb: RGB color tested
> + * @format_pair.yuv: Same color as @format_pair.rgb, but converted to
> + * YUV using @encoding and @range.
> + */
> +struct yuv_u8_to_argb_u16_case {
> + enum drm_color_encoding encoding;
> + enum drm_color_range range;
> + size_t n_colors;
> + struct format_pair {
> + char *name;
> + struct pixel_yuv_u8 yuv;
> + struct pixel_argb_u16 argb;
> + } colors[TEST_BUFF_SIZE];
> +};
> +
> +/*
> + * The YUV color representation were acquired via the colour python framework.
> + * Below are the function calls used for generating each case.
> + *
> + * For more information got to the docs:
> + * https://colour.readthedocs.io/en/master/generated/colour.RGB_to_YCbCr.html
> + */
> +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
> + /*
> + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
> + * in_bits = 16,
> + * in_legal = False,
> + * in_int = True,
> + * out_bits = 8,
> + * out_legal = False,
> + * out_int = True)
> + *
> + * Test cases for conversion between YUV BT601 full range and RGB
> + * using the ITU-R BT.601 weights.
> + */
> + {
> + .encoding = DRM_COLOR_YCBCR_BT601,
> + .range = DRM_COLOR_YCBCR_FULL_RANGE,
> + .n_colors = 6,
> + .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", { 0x4c, 0x55, 0xff }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
> + { "green", { 0x96, 0x2c, 0x15 }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
> + { "blue", { 0x1d, 0xff, 0x6b }, { 0xffff, 0x0000, 0x0000, 0xffff }},
> + },
> + },
> + /*
> + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
> + * in_bits = 16,
> + * in_legal = False,
> + * in_int = True,
> + * out_bits = 8,
> + * out_legal = True,
> + * out_int = True)
> + * Test cases for conversion between YUV BT601 limited range and RGB
> + * using the ITU-R BT.601 weights.
> + */
> + {
> + .encoding = DRM_COLOR_YCBCR_BT601,
> + .range = DRM_COLOR_YCBCR_LIMITED_RANGE,
> + .n_colors = 6,
> + .colors = {
> + { "white", { 0xeb, 0x80, 0x80 }, { 0xffff, 0xffff, 0xffff, 0xffff }},
> + { "gray", { 0x7e, 0x80, 0x80 }, { 0xffff, 0x8080, 0x8080, 0x8080 }},
> + { "black", { 0x10, 0x80, 0x80 }, { 0xffff, 0x0000, 0x0000, 0x0000 }},
> + { "red", { 0x51, 0x5a, 0xf0 }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
> + { "green", { 0x91, 0x36, 0x22 }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
> + { "blue", { 0x29, 0xf0, 0x6e }, { 0xffff, 0x0000, 0x0000, 0xffff }},
> + },
> + },
> + /*
> + * 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".
> + .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 }},
> + },
> + },
> + /*
> + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> + * K=colour.WEIGHTS_YCBCR["ITU-R BT.709"],
> + * in_bits = 16,
> + * int_legal = False,
> + * in_int = True,
> + * out_bits = 8,
> + * out_legal = True,
> + * out_int = True)
> + * Test cases for conversion between YUV BT709 limited range and RGB
> + * using the ITU-R BT.709 weights.
> + */
> + {
> + .encoding = DRM_COLOR_YCBCR_BT709,
> + .range = DRM_COLOR_YCBCR_LIMITED_RANGE,
> + .n_colors = 4,
> + .colors = {
> + { "white", { 0xeb, 0x80, 0x80 }, { 0xffff, 0xffff, 0xffff, 0xffff }},
> + { "gray", { 0x7e, 0x80, 0x80 }, { 0xffff, 0x8080, 0x8080, 0x8080 }},
> + { "black", { 0x10, 0x80, 0x80 }, { 0xffff, 0x0000, 0x0000, 0x0000 }},
> + { "red", { 0x3f, 0x66, 0xf0 }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
> + { "green", { 0xad, 0x2a, 0x1a }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
> + { "blue", { 0x20, 0xf0, 0x76 }, { 0xffff, 0x0000, 0x0000, 0xffff }},
> + },
> + },
> + /*
> + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> + * K=colour.WEIGHTS_YCBCR["ITU-R BT.2020"],
> + * in_bits = 16,
> + * in_legal = False,
> + * in_int = True,
> + * out_bits = 8,
> + * out_legal = False,
> + * out_int = True)
> + * Test cases for conversion between YUV BT2020 full range and RGB
> + * using the ITU-R BT.2020 weights.
> + */
> + {
> + .encoding = DRM_COLOR_YCBCR_BT2020,
> + .range = DRM_COLOR_YCBCR_FULL_RANGE,
> + .n_colors = 4,
> + .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", { 0x43, 0x5c, 0xff }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
> + { "green", { 0xad, 0x24, 0x0b }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
> + { "blue", { 0x0f, 0xff, 0x76 }, { 0xffff, 0x0000, 0x0000, 0xffff }},
> + },
> + },
> + /*
> + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> + * K=colour.WEIGHTS_YCBCR["ITU-R BT.2020"],
> + * in_bits = 16,
> + * in_legal = False,
> + * in_int = True,
> + * out_bits = 8,
> + * out_legal = True,
> + * out_int = True)
> + * Test cases for conversion between YUV BT2020 limited range and RGB
> + * using the ITU-R BT.709 weights.
> + */
> + {
> + .encoding = DRM_COLOR_YCBCR_BT2020,
> + .range = DRM_COLOR_YCBCR_LIMITED_RANGE,
> + .n_colors = 4,
> + .colors = {
> + { "white", { 0xeb, 0x80, 0x80 }, { 0xffff, 0xffff, 0xffff, 0xffff }},
> + { "gray", { 0x7e, 0x80, 0x80 }, { 0xffff, 0x8080, 0x8080, 0x8080 }},
> + { "black", { 0x10, 0x80, 0x80 }, { 0xffff, 0x0000, 0x0000, 0x0000 }},
> + { "red", { 0x4a, 0x61, 0xf0 }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
> + { "green", { 0xa4, 0x2f, 0x19 }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
> + { "blue", { 0x1d, 0xf0, 0x77 }, { 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 = ¶m->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.
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.
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?
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.
> +
> + KUNIT_EXPECT_LE_MSG(test, abs_diff(argb.a, color->argb.a), 0x1ff,
> + "On the A channel of the color %s expected 0x%04x, got 0x%04x",
> + color->name, color->argb.a, argb.a);
> + KUNIT_EXPECT_LE_MSG(test, abs_diff(argb.r, color->argb.r), 0x1ff,
> + "On the R channel of the color %s expected 0x%04x, got 0x%04x",
> + color->name, color->argb.r, argb.r);
> + KUNIT_EXPECT_LE_MSG(test, abs_diff(argb.g, color->argb.g), 0x1ff,
> + "On the G channel of the color %s expected 0x%04x, got 0x%04x",
> + color->name, color->argb.g, argb.g);
> + KUNIT_EXPECT_LE_MSG(test, abs_diff(argb.b, color->argb.b), 0x1ff,
> + "On the B channel of the color %s expected 0x%04x, got 0x%04x",
> + color->name, color->argb.b, argb.b);
> + }
> +}
> +
> +static void vkms_format_test_yuv_u8_to_argb_u16_case_desc(struct yuv_u8_to_argb_u16_case *t,
> + char *desc)
> +{
> + snprintf(desc, KUNIT_PARAM_DESC_SIZE, "%s - %s",
> + drm_get_color_encoding_name(t->encoding), drm_get_color_range_name(t->range));
> +}
> +
> +KUNIT_ARRAY_PARAM(yuv_u8_to_argb_u16, yuv_u8_to_argb_u16_cases,
> + vkms_format_test_yuv_u8_to_argb_u16_case_desc
> +);
> +
> +static struct kunit_case vkms_format_test_cases[] = {
> + KUNIT_CASE_PARAM(vkms_format_test_yuv_u8_to_argb_u16, yuv_u8_to_argb_u16_gen_params),
> + {}
> +};
> +
> +static struct kunit_suite vkms_format_test_suite = {
> + .name = "vkms-format",
> + .test_cases = vkms_format_test_cases,
> +};
> +
> +kunit_test_suite(vkms_format_test_suite);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Kunit test for vkms format conversion");
> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c
> index 1f3ce4f334be9560e62c9a7fd933fa0ed6640e8f..0b867444999105262c855a24bf03bc66d9ebea1b 100644
> --- a/drivers/gpu/drm/vkms/vkms_formats.c
> +++ b/drivers/gpu/drm/vkms/vkms_formats.c
> @@ -7,6 +7,8 @@
> #include <drm/drm_rect.h>
> #include <drm/drm_fixed.h>
>
> +#include <kunit/visibility.h>
> +
> #include "vkms_formats.h"
>
> /**
> @@ -247,8 +249,8 @@ static struct pixel_argb_u16 argb_u16_from_RGB565(const __le16 *pixel)
> return out_pixel;
> }
>
> -static struct pixel_argb_u16 argb_u16_from_yuv888(u8 y, u8 channel_1, u8 channel_2,
> - const struct conversion_matrix *matrix)
> +VISIBLE_IF_KUNIT struct pixel_argb_u16 argb_u16_from_yuv888(u8 y, u8 channel_1, u8 channel_2,
> + const struct conversion_matrix *matrix)
> {
> u16 r, g, b;
> s64 fp_y, fp_channel_1, fp_channel_2;
> @@ -278,6 +280,7 @@ static struct pixel_argb_u16 argb_u16_from_yuv888(u8 y, u8 channel_1, u8 channel
>
> return argb_u16_from_u16161616(0xffff, r, g, b);
> }
> +EXPORT_SYMBOL_IF_KUNIT(argb_u16_from_yuv888);
>
> /*
> * The following functions are read_line function for each pixel format supported by VKMS.
> diff --git a/drivers/gpu/drm/vkms/vkms_formats.h b/drivers/gpu/drm/vkms/vkms_formats.h
> index d583855cb32027d16b73d2a5b5a0644b13191d08..b4fe62ab9c65d465925d29911f26612193a80799 100644
> --- a/drivers/gpu/drm/vkms/vkms_formats.h
> +++ b/drivers/gpu/drm/vkms/vkms_formats.h
> @@ -13,4 +13,9 @@ void get_conversion_matrix_to_argb_u16(u32 format, enum drm_color_encoding encod
> enum drm_color_range range,
> struct conversion_matrix *matrix);
>
> +#if IS_ENABLED(CONFIG_KUNIT)
> +struct pixel_argb_u16 argb_u16_from_yuv888(u8 y, u8 channel_1, u8 channel_2,
> + const struct conversion_matrix *matrix);
> +#endif
> +
> #endif /* _VKMS_FORMATS_H_ */
>
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 = ¶m->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 :)
> 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.
[...]
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 = ¶m->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.
>
> [...]
On Tue, Jan 21, 2025 at 11:48:06AM +0100, Louis Chauvet wrote:
> +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
> + /*
> + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
> + * in_bits = 16,
> + * in_legal = False,
> + * in_int = True,
> + * out_bits = 8,
> + * out_legal = False,
> + * out_int = True)
> + *
> + * Test cases for conversion between YUV BT601 full range and RGB
> + * using the ITU-R BT.601 weights.
> + */
What are the input and output formats?
Ditto for all the other tests.
Maxime
On 26/01/25 - 18:06, Maxime Ripard wrote:
> On Tue, Jan 21, 2025 at 11:48:06AM +0100, Louis Chauvet wrote:
> > +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
> > + /*
> > + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> > + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
> > + * in_bits = 16,
> > + * in_legal = False,
> > + * in_int = True,
> > + * out_bits = 8,
> > + * out_legal = False,
> > + * out_int = True)
> > + *
> > + * Test cases for conversion between YUV BT601 full range and RGB
> > + * using the ITU-R BT.601 weights.
> > + */
>
> What are the input and output formats?
>
> Ditto for all the other tests.
There is no really "input" and "output" format, they are reference values
for conversion, you should be able to use it in both direction. They are
generated by RGB_to_YCbCr (RGB input, YUV output) just because it was
easier to create the colors from RGB values.
If you think we should specify what is was used as input and output to
generate those values, I can modify the comment to:
Tests cases for color conversion generated by converting RGB
values to YUV BT601 full range using the ITU-R BT.601 weights.
Beside that modification, did you notice anything else on the series that
require more work before adding your Ack-by/Reviewed-by on the other
patches?
Thanks,
Louis Chauvet
> Maxime
On Mon, Jan 27, 2025 at 11:48:23AM +0100, Louis Chauvet wrote:
> On 26/01/25 - 18:06, Maxime Ripard wrote:
> > On Tue, Jan 21, 2025 at 11:48:06AM +0100, Louis Chauvet wrote:
> > > +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
> > > + /*
> > > + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> > > + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
> > > + * in_bits = 16,
> > > + * in_legal = False,
> > > + * in_int = True,
> > > + * out_bits = 8,
> > > + * out_legal = False,
> > > + * out_int = True)
> > > + *
> > > + * Test cases for conversion between YUV BT601 full range and RGB
> > > + * using the ITU-R BT.601 weights.
> > > + */
> >
> > What are the input and output formats?
> >
> > Ditto for all the other tests.
>
> There is no really "input" and "output" format, they are reference values
> for conversion, you should be able to use it in both direction. They are
> generated by RGB_to_YCbCr (RGB input, YUV output) just because it was
> easier to create the colors from RGB values.
RGB and YUV aren't formats, they are color models. XRGB8888 is a format.
NV12 is a format.
> If you think we should specify what is was used as input and output to
> generate those values, I can modify the comment to:
>
> Tests cases for color conversion generated by converting RGB
> values to YUV BT601 full range using the ITU-R BT.601 weights.
My point is that those comments should provide a way to reimplement the
test from scratch, and compare to the actual implementation. It's useful
when you have a test failure and start to wonder if the implementation
or the test is at fault.
By saying only RGB and YUV, you can't possibly do that.
> Beside that modification, did you notice anything else on the series that
> require more work before adding your Ack-by/Reviewed-by on the other
> patches?
The rest looked good to me the last time I looked.
Maxime
On 05/02/25 - 09:55, Maxime Ripard wrote:
> On Mon, Jan 27, 2025 at 11:48:23AM +0100, Louis Chauvet wrote:
> > On 26/01/25 - 18:06, Maxime Ripard wrote:
> > > On Tue, Jan 21, 2025 at 11:48:06AM +0100, Louis Chauvet wrote:
> > > > +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
> > > > + /*
> > > > + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> > > > + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
> > > > + * in_bits = 16,
> > > > + * in_legal = False,
> > > > + * in_int = True,
> > > > + * out_bits = 8,
> > > > + * out_legal = False,
> > > > + * out_int = True)
> > > > + *
> > > > + * Test cases for conversion between YUV BT601 full range and RGB
> > > > + * using the ITU-R BT.601 weights.
> > > > + */
> > >
> > > What are the input and output formats?
> > >
> > > Ditto for all the other tests.
> >
> > There is no really "input" and "output" format, they are reference values
> > for conversion, you should be able to use it in both direction. They are
> > generated by RGB_to_YCbCr (RGB input, YUV output) just because it was
> > easier to create the colors from RGB values.
>
> RGB and YUV aren't formats, they are color models. XRGB8888 is a format.
> NV12 is a format.
>
> > If you think we should specify what is was used as input and output to
> > generate those values, I can modify the comment to:
> >
> > Tests cases for color conversion generated by converting RGB
> > values to YUV BT601 full range using the ITU-R BT.601 weights.
>
> My point is that those comments should provide a way to reimplement the
> test from scratch, and compare to the actual implementation. It's useful
> when you have a test failure and start to wonder if the implementation
> or the test is at fault.
>
> By saying only RGB and YUV, you can't possibly do that.
I understand your concern, but I believe there might be a slight
misunderstanding. The table in question stores reference values for
specific color models, not formats. Therefore, it doesn't specify any
particular format like XRGB8888 or NV12.
To clarify this, I can rename the format_pair struct to value_pair. This
should make it clearer that we are dealing with color model values rather
than formats.
If you want to test a specific format conversion, such as
YUV420_to_argbu16, you would need to follow a process like this:
// Recreate a YUV420 data
plane_1[0] = test_case.yuv.y
plane_2[0] = test_case.yuv.u
plane_2[1] = test_case.yuv.v
// convertion to test from YUV420 format to argb_u16
rgb_u16 = convert_YUV420_to_argbu16(plane_1, plane_2)
// ensure the conversion is valid
assert_eq(rgb_u16, test_case.rgb)
The current test is not performing this kind of format conversion.
Instead, it verifies that for given (y, u, v) values, the correct (r, g,
b, a) values are obtained. In other words, it tests color model
conversion, not format conversion.
Do you think I need to change something in this test? If so, can you
explain what kind of unit test you are expecting.
Thanks,
Louis Chauvet
> > Beside that modification, did you notice anything else on the series that
> > require more work before adding your Ack-by/Reviewed-by on the other
> > patches?
>
> The rest looked good to me the last time I looked.
>
> Maxime
On Wed, Feb 05, 2025 at 04:32:07PM +0100, Louis Chauvet wrote:
> On 05/02/25 - 09:55, Maxime Ripard wrote:
> > On Mon, Jan 27, 2025 at 11:48:23AM +0100, Louis Chauvet wrote:
> > > On 26/01/25 - 18:06, Maxime Ripard wrote:
> > > > On Tue, Jan 21, 2025 at 11:48:06AM +0100, Louis Chauvet wrote:
> > > > > +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
> > > > > + /*
> > > > > + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> > > > > + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
> > > > > + * in_bits = 16,
> > > > > + * in_legal = False,
> > > > > + * in_int = True,
> > > > > + * out_bits = 8,
> > > > > + * out_legal = False,
> > > > > + * out_int = True)
> > > > > + *
> > > > > + * Test cases for conversion between YUV BT601 full range and RGB
> > > > > + * using the ITU-R BT.601 weights.
> > > > > + */
> > > >
> > > > What are the input and output formats?
> > > >
> > > > Ditto for all the other tests.
> > >
> > > There is no really "input" and "output" format, they are reference values
> > > for conversion, you should be able to use it in both direction. They are
> > > generated by RGB_to_YCbCr (RGB input, YUV output) just because it was
> > > easier to create the colors from RGB values.
> >
> > RGB and YUV aren't formats, they are color models. XRGB8888 is a format.
> > NV12 is a format.
> >
> > > If you think we should specify what is was used as input and output to
> > > generate those values, I can modify the comment to:
> > >
> > > Tests cases for color conversion generated by converting RGB
> > > values to YUV BT601 full range using the ITU-R BT.601 weights.
> >
> > My point is that those comments should provide a way to reimplement the
> > test from scratch, and compare to the actual implementation. It's useful
> > when you have a test failure and start to wonder if the implementation
> > or the test is at fault.
> >
> > By saying only RGB and YUV, you can't possibly do that.
>
> I understand your concern, but I believe there might be a slight
> misunderstanding. The table in question stores reference values for
> specific color models, not formats. Therefore, it doesn't specify any
> particular format like XRGB8888 or NV12.
>
> To clarify this, I can rename the format_pair struct to value_pair. This
> should make it clearer that we are dealing with color model values rather
> than formats.
>
> If you want to test a specific format conversion, such as
> YUV420_to_argbu16, you would need to follow a process like this:
>
> // Recreate a YUV420 data
> plane_1[0] = test_case.yuv.y
> plane_2[0] = test_case.yuv.u
> plane_2[1] = test_case.yuv.v
>
> // convertion to test from YUV420 format to argb_u16
> rgb_u16 = convert_YUV420_to_argbu16(plane_1, plane_2)
>
> // ensure the conversion is valid
> assert_eq(rgb_u16, test_case.rgb)
>
> The current test is not performing this kind of format conversion.
> Instead, it verifies that for given (y, u, v) values, the correct (r, g,
> b, a) values are obtained.
You already stated that you check for the A, R, G, and B components. On
how many bits are the values you are comparing stored? The YUV values
you are comparing are stored on how many bits for each channel? With
subsampling?
If you want to compare values, you need to encode a given color into
bits, and the way that encoding is done is what the format is about.
You might not compare the memory layout but each component individually,
but it's still a format.
And then, you have the extra fun on top, like are you comparing
full-range or limited-range colors?
> In other words, it tests color model conversion, not format conversion.
No, you are testing color encoding, format and model conversions, all at
once.
Maxime
Le 19/02/2025 à 11:15, Maxime Ripard a écrit :
> On Wed, Feb 05, 2025 at 04:32:07PM +0100, Louis Chauvet wrote:
>> On 05/02/25 - 09:55, Maxime Ripard wrote:
>>> On Mon, Jan 27, 2025 at 11:48:23AM +0100, Louis Chauvet wrote:
>>>> On 26/01/25 - 18:06, Maxime Ripard wrote:
>>>>> On Tue, Jan 21, 2025 at 11:48:06AM +0100, Louis Chauvet wrote:
>>>>>> +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
>>>>>> + /*
>>>>>> + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
>>>>>> + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
>>>>>> + * in_bits = 16,
>>>>>> + * in_legal = False,
>>>>>> + * in_int = True,
>>>>>> + * out_bits = 8,
>>>>>> + * out_legal = False,
>>>>>> + * out_int = True)
>>>>>> + *
>>>>>> + * Test cases for conversion between YUV BT601 full range and RGB
>>>>>> + * using the ITU-R BT.601 weights.
>>>>>> + */
>>>>>
>>>>> What are the input and output formats?
>>>>>
>>>>> Ditto for all the other tests.
>>>>
>>>> There is no really "input" and "output" format, they are reference values
>>>> for conversion, you should be able to use it in both direction. They are
>>>> generated by RGB_to_YCbCr (RGB input, YUV output) just because it was
>>>> easier to create the colors from RGB values.
>>>
>>> RGB and YUV aren't formats, they are color models. XRGB8888 is a format.
>>> NV12 is a format.
>>>
>>>> If you think we should specify what is was used as input and output to
>>>> generate those values, I can modify the comment to:
>>>>
>>>> Tests cases for color conversion generated by converting RGB
>>>> values to YUV BT601 full range using the ITU-R BT.601 weights.
>>>
>>> My point is that those comments should provide a way to reimplement the
>>> test from scratch, and compare to the actual implementation. It's useful
>>> when you have a test failure and start to wonder if the implementation
>>> or the test is at fault.
>>>
>>> By saying only RGB and YUV, you can't possibly do that.
>>
>> I understand your concern, but I believe there might be a slight
>> misunderstanding. The table in question stores reference values for
>> specific color models, not formats. Therefore, it doesn't specify any
>> particular format like XRGB8888 or NV12.
>>
>> To clarify this, I can rename the format_pair struct to value_pair. This
>> should make it clearer that we are dealing with color model values rather
>> than formats.
>>
>> If you want to test a specific format conversion, such as
>> YUV420_to_argbu16, you would need to follow a process like this:
>>
>> // Recreate a YUV420 data
>> plane_1[0] = test_case.yuv.y
>> plane_2[0] = test_case.yuv.u
>> plane_2[1] = test_case.yuv.v
>>
>> // convertion to test from YUV420 format to argb_u16
>> rgb_u16 = convert_YUV420_to_argbu16(plane_1, plane_2)
>>
>> // ensure the conversion is valid
>> assert_eq(rgb_u16, test_case.rgb)
>>
>> The current test is not performing this kind of format conversion.
>> Instead, it verifies that for given (y, u, v) values, the correct (r, g,
>> b, a) values are obtained.
>
> You already stated that you check for the A, R, G, and B components. On
> how many bits are the values you are comparing stored? The YUV values
> you are comparing are stored on how many bits for each channel? With
> subsampling?
>
> If you want to compare values, you need to encode a given color into
> bits, and the way that encoding is done is what the format is about.
>
> You might not compare the memory layout but each component individually,
> but it's still a format.
Sorry, I think I misunderstood what a format really is. But even with
this explanation, I don't understand well what you ask me to change. Is
this better:
The values are computed by converting RGB values, with each component
stored as u16, to YUV values, with each component stored as u8. The
conversion is done from RGB full range to YUV BT601 full range using the
ITU-R BT.601 weights.
TBH, I do not understand what you are asking for exactly. Can you please
give the sentence you expect directly?
Thanks,
Louis Chauvet
> And then, you have the extra fun on top, like are you comparing
> full-range or limited-range colors?
>
>> In other words, it tests color model conversion, not format conversion.
>
> No, you are testing color encoding, format and model conversions, all at
> once.
>
> Maxime
--
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On Wed, Feb 19, 2025 at 02:35:14PM +0100, Louis Chauvet wrote:
>
>
> Le 19/02/2025 à 11:15, Maxime Ripard a écrit :
> > On Wed, Feb 05, 2025 at 04:32:07PM +0100, Louis Chauvet wrote:
> > > On 05/02/25 - 09:55, Maxime Ripard wrote:
> > > > On Mon, Jan 27, 2025 at 11:48:23AM +0100, Louis Chauvet wrote:
> > > > > On 26/01/25 - 18:06, Maxime Ripard wrote:
> > > > > > On Tue, Jan 21, 2025 at 11:48:06AM +0100, Louis Chauvet wrote:
> > > > > > > +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
> > > > > > > + /*
> > > > > > > + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> > > > > > > + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
> > > > > > > + * in_bits = 16,
> > > > > > > + * in_legal = False,
> > > > > > > + * in_int = True,
> > > > > > > + * out_bits = 8,
> > > > > > > + * out_legal = False,
> > > > > > > + * out_int = True)
> > > > > > > + *
> > > > > > > + * Test cases for conversion between YUV BT601 full range and RGB
> > > > > > > + * using the ITU-R BT.601 weights.
> > > > > > > + */
> > > > > >
> > > > > > What are the input and output formats?
> > > > > >
> > > > > > Ditto for all the other tests.
> > > > >
> > > > > There is no really "input" and "output" format, they are reference values
> > > > > for conversion, you should be able to use it in both direction. They are
> > > > > generated by RGB_to_YCbCr (RGB input, YUV output) just because it was
> > > > > easier to create the colors from RGB values.
> > > >
> > > > RGB and YUV aren't formats, they are color models. XRGB8888 is a format.
> > > > NV12 is a format.
> > > >
> > > > > If you think we should specify what is was used as input and output to
> > > > > generate those values, I can modify the comment to:
> > > > >
> > > > > Tests cases for color conversion generated by converting RGB
> > > > > values to YUV BT601 full range using the ITU-R BT.601 weights.
> > > >
> > > > My point is that those comments should provide a way to reimplement the
> > > > test from scratch, and compare to the actual implementation. It's useful
> > > > when you have a test failure and start to wonder if the implementation
> > > > or the test is at fault.
> > > >
> > > > By saying only RGB and YUV, you can't possibly do that.
> > >
> > > I understand your concern, but I believe there might be a slight
> > > misunderstanding. The table in question stores reference values for
> > > specific color models, not formats. Therefore, it doesn't specify any
> > > particular format like XRGB8888 or NV12.
> > >
> > > To clarify this, I can rename the format_pair struct to value_pair. This
> > > should make it clearer that we are dealing with color model values rather
> > > than formats.
> > >
> > > If you want to test a specific format conversion, such as
> > > YUV420_to_argbu16, you would need to follow a process like this:
> > >
> > > // Recreate a YUV420 data
> > > plane_1[0] = test_case.yuv.y
> > > plane_2[0] = test_case.yuv.u
> > > plane_2[1] = test_case.yuv.v
> > >
> > > // convertion to test from YUV420 format to argb_u16
> > > rgb_u16 = convert_YUV420_to_argbu16(plane_1, plane_2)
> > >
> > > // ensure the conversion is valid
> > > assert_eq(rgb_u16, test_case.rgb)
> > >
> > > The current test is not performing this kind of format conversion.
> > > Instead, it verifies that for given (y, u, v) values, the correct (r, g,
> > > b, a) values are obtained.
> >
> > You already stated that you check for the A, R, G, and B components. On
> > how many bits are the values you are comparing stored? The YUV values
> > you are comparing are stored on how many bits for each channel? With
> > subsampling?
> >
> > If you want to compare values, you need to encode a given color into
> > bits, and the way that encoding is done is what the format is about.
> >
> > You might not compare the memory layout but each component individually,
> > but it's still a format.
>
> Sorry, I think I misunderstood what a format really is.
Ultimately, a format is how a given "color value" is stored. How many
bits will you use? If you have an unaligned number of bits, how many
bits of padding you'll use, where the padding is? If there's multiple
bytes, what's the endianness?
The answer to all these questions is "the format", and that's why
there's so many of them.
> But even with this explanation, I don't understand well what you ask
> me to change. Is this better:
>
> The values are computed by converting RGB values, with each component stored
> as u16, to YUV values, with each component stored as u8. The conversion is
> done from RGB full range to YUV BT601 full range using the ITU-R BT.601
> weights.
>
> TBH, I do not understand what you are asking for exactly. Can you please
> give the sentence you expect directly?
The fourcc[1] code for the input and output format would be nice. And if
you can't, an ad-hoc definition of the format, answering the questions I
mentionned earlier (and in the previous mail for YUV). I'm really
surprised about the RGB component values being stored on 16 bits though.
It's super unusual, to the point where it's almost useless for us to
test, and we should probably use 8 bits values.
Maxime
1: https://elixir.bootlin.com/linux/v6.13.5/source/include/uapi/drm/drm_fourcc.h#L486
Le 07/03/2025 à 11:20, Maxime Ripard a écrit :
> On Wed, Feb 19, 2025 at 02:35:14PM +0100, Louis Chauvet wrote:
>>
>>
>> Le 19/02/2025 à 11:15, Maxime Ripard a écrit :
>>> On Wed, Feb 05, 2025 at 04:32:07PM +0100, Louis Chauvet wrote:
>>>> On 05/02/25 - 09:55, Maxime Ripard wrote:
>>>>> On Mon, Jan 27, 2025 at 11:48:23AM +0100, Louis Chauvet wrote:
>>>>>> On 26/01/25 - 18:06, Maxime Ripard wrote:
>>>>>>> On Tue, Jan 21, 2025 at 11:48:06AM +0100, Louis Chauvet wrote:
>>>>>>>> +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
>>>>>>>> + /*
>>>>>>>> + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
>>>>>>>> + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
>>>>>>>> + * in_bits = 16,
>>>>>>>> + * in_legal = False,
>>>>>>>> + * in_int = True,
>>>>>>>> + * out_bits = 8,
>>>>>>>> + * out_legal = False,
>>>>>>>> + * out_int = True)
>>>>>>>> + *
>>>>>>>> + * Test cases for conversion between YUV BT601 full range and RGB
>>>>>>>> + * using the ITU-R BT.601 weights.
>>>>>>>> + */
>>>>>>>
>>>>>>> What are the input and output formats?
>>>>>>>
>>>>>>> Ditto for all the other tests.
>>>>>>
>>>>>> There is no really "input" and "output" format, they are reference values
>>>>>> for conversion, you should be able to use it in both direction. They are
>>>>>> generated by RGB_to_YCbCr (RGB input, YUV output) just because it was
>>>>>> easier to create the colors from RGB values.
>>>>>
>>>>> RGB and YUV aren't formats, they are color models. XRGB8888 is a format.
>>>>> NV12 is a format.
>>>>>
>>>>>> If you think we should specify what is was used as input and output to
>>>>>> generate those values, I can modify the comment to:
>>>>>>
>>>>>> Tests cases for color conversion generated by converting RGB
>>>>>> values to YUV BT601 full range using the ITU-R BT.601 weights.
>>>>>
>>>>> My point is that those comments should provide a way to reimplement the
>>>>> test from scratch, and compare to the actual implementation. It's useful
>>>>> when you have a test failure and start to wonder if the implementation
>>>>> or the test is at fault.
>>>>>
>>>>> By saying only RGB and YUV, you can't possibly do that.
>>>>
>>>> I understand your concern, but I believe there might be a slight
>>>> misunderstanding. The table in question stores reference values for
>>>> specific color models, not formats. Therefore, it doesn't specify any
>>>> particular format like XRGB8888 or NV12.
>>>>
>>>> To clarify this, I can rename the format_pair struct to value_pair. This
>>>> should make it clearer that we are dealing with color model values rather
>>>> than formats.
>>>>
>>>> If you want to test a specific format conversion, such as
>>>> YUV420_to_argbu16, you would need to follow a process like this:
>>>>
>>>> // Recreate a YUV420 data
>>>> plane_1[0] = test_case.yuv.y
>>>> plane_2[0] = test_case.yuv.u
>>>> plane_2[1] = test_case.yuv.v
>>>>
>>>> // convertion to test from YUV420 format to argb_u16
>>>> rgb_u16 = convert_YUV420_to_argbu16(plane_1, plane_2)
>>>>
>>>> // ensure the conversion is valid
>>>> assert_eq(rgb_u16, test_case.rgb)
>>>>
>>>> The current test is not performing this kind of format conversion.
>>>> Instead, it verifies that for given (y, u, v) values, the correct (r, g,
>>>> b, a) values are obtained.
>>>
>>> You already stated that you check for the A, R, G, and B components. On
>>> how many bits are the values you are comparing stored? The YUV values
>>> you are comparing are stored on how many bits for each channel? With
>>> subsampling?
>>>
>>> If you want to compare values, you need to encode a given color into
>>> bits, and the way that encoding is done is what the format is about.
>>>
>>> You might not compare the memory layout but each component individually,
>>> but it's still a format.
>>
>> Sorry, I think I misunderstood what a format really is.
>
> Ultimately, a format is how a given "color value" is stored. How many
> bits will you use? If you have an unaligned number of bits, how many
> bits of padding you'll use, where the padding is? If there's multiple
> bytes, what's the endianness?
>
> The answer to all these questions is "the format", and that's why
> there's so many of them.
Thanks!
>> But even with this explanation, I don't understand well what you ask
>> me to change. Is this better:
>>
>> The values are computed by converting RGB values, with each component stored
>> as u16, to YUV values, with each component stored as u8. The conversion is
>> done from RGB full range to YUV BT601 full range using the ITU-R BT.601
>> weights.
>>
>> TBH, I do not understand what you are asking for exactly. Can you please
>> give the sentence you expect directly?
>
> The fourcc[1] code for the input and output format would be nice. And if
> you can't, an ad-hoc definition of the format, answering the questions I
> mentionned earlier (and in the previous mail for YUV).
I don't think any fourcc code will apply in this case, the tests use
internal VKMS structures pixel_argb_16 and pixel_yuv_u8. How do I
describe them better? If I add this comment for the structures, is it
enough?
/**
* struct pixel_argb_u16 - Internal representation of a pixel color.
* @r: Red component value, stored in 16 bits, without padding, using
* machine endianness
* @b: [...]
*
* The goal of this structure is to keep enough precision to ensure
* correct composition results in VKMS and simplifying color
* manipulation by splitting each component into its own field.
* Caution: the byte ordering of this structure is machine-dependent,
* you can't cast it directly to AR48 or xR48.
*/
struct pixel_argb_u16 {
u16 a, r, g, b;
};
(ditto for pixel_yuv_u8)
> I'm really
> surprised about the RGB component values being stored on 16 bits though.
> It's super unusual, to the point where it's almost useless for us to
> test, and we should probably use 8 bits values.
We need to have 16 bits because some of the writeback formats are 16 bits.
Louis Chauvet
> Maxime
>
> 1: https://elixir.bootlin.com/linux/v6.13.5/source/include/uapi/drm/drm_fourcc.h#L486
--
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On Fri, 7 Mar 2025 15:50:41 +0100
Louis Chauvet <louis.chauvet@bootlin.com> wrote:
> Le 07/03/2025 à 11:20, Maxime Ripard a écrit :
> > On Wed, Feb 19, 2025 at 02:35:14PM +0100, Louis Chauvet wrote:
> >>
> >>
> >> Le 19/02/2025 à 11:15, Maxime Ripard a écrit :
> >>> On Wed, Feb 05, 2025 at 04:32:07PM +0100, Louis Chauvet wrote:
> >>>> On 05/02/25 - 09:55, Maxime Ripard wrote:
> >>>>> On Mon, Jan 27, 2025 at 11:48:23AM +0100, Louis Chauvet wrote:
> >>>>>> On 26/01/25 - 18:06, Maxime Ripard wrote:
> >>>>>>> On Tue, Jan 21, 2025 at 11:48:06AM +0100, Louis Chauvet wrote:
> >>>>>>>> +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
> >>>>>>>> + /*
> >>>>>>>> + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> >>>>>>>> + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
> >>>>>>>> + * in_bits = 16,
> >>>>>>>> + * in_legal = False,
> >>>>>>>> + * in_int = True,
> >>>>>>>> + * out_bits = 8,
> >>>>>>>> + * out_legal = False,
> >>>>>>>> + * out_int = True)
> >>>>>>>> + *
> >>>>>>>> + * Test cases for conversion between YUV BT601 full range and RGB
> >>>>>>>> + * using the ITU-R BT.601 weights.
> >>>>>>>> + */
> >>>>>>>
> >>>>>>> What are the input and output formats?
> >>>>>>>
> >>>>>>> Ditto for all the other tests.
> >>>>>>
> >>>>>> There is no really "input" and "output" format, they are reference values
> >>>>>> for conversion, you should be able to use it in both direction. They are
> >>>>>> generated by RGB_to_YCbCr (RGB input, YUV output) just because it was
> >>>>>> easier to create the colors from RGB values.
> >>>>>
> >>>>> RGB and YUV aren't formats, they are color models. XRGB8888 is a format.
> >>>>> NV12 is a format.
> >>>>>
> >>>>>> If you think we should specify what is was used as input and output to
> >>>>>> generate those values, I can modify the comment to:
> >>>>>>
> >>>>>> Tests cases for color conversion generated by converting RGB
> >>>>>> values to YUV BT601 full range using the ITU-R BT.601 weights.
> >>>>>
> >>>>> My point is that those comments should provide a way to reimplement the
> >>>>> test from scratch, and compare to the actual implementation. It's useful
> >>>>> when you have a test failure and start to wonder if the implementation
> >>>>> or the test is at fault.
> >>>>>
> >>>>> By saying only RGB and YUV, you can't possibly do that.
> >>>>
> >>>> I understand your concern, but I believe there might be a slight
> >>>> misunderstanding. The table in question stores reference values for
> >>>> specific color models, not formats. Therefore, it doesn't specify any
> >>>> particular format like XRGB8888 or NV12.
> >>>>
> >>>> To clarify this, I can rename the format_pair struct to value_pair. This
> >>>> should make it clearer that we are dealing with color model values rather
> >>>> than formats.
> >>>>
> >>>> If you want to test a specific format conversion, such as
> >>>> YUV420_to_argbu16, you would need to follow a process like this:
> >>>>
> >>>> // Recreate a YUV420 data
> >>>> plane_1[0] = test_case.yuv.y
> >>>> plane_2[0] = test_case.yuv.u
> >>>> plane_2[1] = test_case.yuv.v
> >>>>
> >>>> // convertion to test from YUV420 format to argb_u16
> >>>> rgb_u16 = convert_YUV420_to_argbu16(plane_1, plane_2)
> >>>>
> >>>> // ensure the conversion is valid
> >>>> assert_eq(rgb_u16, test_case.rgb)
> >>>>
> >>>> The current test is not performing this kind of format conversion.
> >>>> Instead, it verifies that for given (y, u, v) values, the correct (r, g,
> >>>> b, a) values are obtained.
> >>>
> >>> You already stated that you check for the A, R, G, and B components. On
> >>> how many bits are the values you are comparing stored? The YUV values
> >>> you are comparing are stored on how many bits for each channel? With
> >>> subsampling?
> >>>
> >>> If you want to compare values, you need to encode a given color into
> >>> bits, and the way that encoding is done is what the format is about.
> >>>
> >>> You might not compare the memory layout but each component individually,
> >>> but it's still a format.
> >>
> >> Sorry, I think I misunderstood what a format really is.
> >
> > Ultimately, a format is how a given "color value" is stored. How many
> > bits will you use? If you have an unaligned number of bits, how many
> > bits of padding you'll use, where the padding is? If there's multiple
> > bytes, what's the endianness?
> >
> > The answer to all these questions is "the format", and that's why
> > there's so many of them.
>
> Thanks!
>
> >> But even with this explanation, I don't understand well what you ask
> >> me to change. Is this better:
> >>
> >> The values are computed by converting RGB values, with each component stored
> >> as u16, to YUV values, with each component stored as u8. The conversion is
> >> done from RGB full range to YUV BT601 full range using the ITU-R BT.601
> >> weights.
> >>
> >> TBH, I do not understand what you are asking for exactly. Can you please
> >> give the sentence you expect directly?
> >
> > The fourcc[1] code for the input and output format would be nice. And if
> > you can't, an ad-hoc definition of the format, answering the questions I
> > mentionned earlier (and in the previous mail for YUV).
>
> I don't think any fourcc code will apply in this case, the tests use
> internal VKMS structures pixel_argb_16 and pixel_yuv_u8. How do I
> describe them better? If I add this comment for the structures, is it
> enough?
>
> /**
> * struct pixel_argb_u16 - Internal representation of a pixel color.
> * @r: Red component value, stored in 16 bits, without padding, using
> * machine endianness
> * @b: [...]
> *
> * The goal of this structure is to keep enough precision to ensure
> * correct composition results in VKMS and simplifying color
> * manipulation by splitting each component into its own field.
> * Caution: the byte ordering of this structure is machine-dependent,
> * you can't cast it directly to AR48 or xR48.
> */
> struct pixel_argb_u16 {
> u16 a, r, g, b;
> };
>
> (ditto for pixel_yuv_u8)
>
> > I'm really
> > surprised about the RGB component values being stored on 16 bits though.
> > It's super unusual, to the point where it's almost useless for us to
> > test, and we should probably use 8 bits values.
>
> We need to have 16 bits because some of the writeback formats are 16 bits.
Hi Maxime,
Louis' proposed comment is good and accurate. I can elaborate further on
it.
pixel_argb_u16 is an internal structure used only for temporary pixel
storage: the intermediate format. It's aim is to make computations on
pixel values easy: every input format is converted to it before
computations, and after computations it is converted to each output
format. This allows VKMS to implement computations, e.g. a matrix
operation, in simple code for only one cpu-endian "pixel format", the
intermediate format. (drm_fourcc.h has no cpu-endian formats at all,
and that is good.)
That VKMS never stores complete images in the intermediate format. To
strike a balance between temporary memory requirements and
computational overhead, VKMS processes images line-by-line. Only one
(or two) line's worth of pixels is needed to be kept in memory per
source or destination framebuffer at a time.
16-bit precision is required not just because some writeback and
framebuffer formats are 16-bit. We also need extra precision due to the
color value encoding. Transfer functions can convert pixel data between
the optical and electrical domains. Framebuffers usually contain
electrical domain data, because it takes less bits per pixel in order
to achieve a specific level of visual image quality (think of color
gradient banding). However, some computations, like color space
conversion with a matrix, must be done in the optical domain, which
requires more bits per pixel in order to not degrade the image quality.
In the future I would even expect needing 32-bit or even 64-bit per
channel precision in the intermediate format once higher-than-16 bits
per channel framebuffer formats require testing.
YUV can work with 8 bits per pixel for now, because in practice YUV is
always stored in electrical domain due its definition. YUV in optical
domain is simply never used. However, there are framebuffer formats
with more than 8 bits of YUV channels, so this may need extending too.
Thanks,
pq
Hi,
On Mon, Mar 10, 2025 at 11:12:59AM +0200, Pekka Paalanen wrote:
> On Fri, 7 Mar 2025 15:50:41 +0100
> Louis Chauvet <louis.chauvet@bootlin.com> wrote:
>
> > Le 07/03/2025 à 11:20, Maxime Ripard a écrit :
> > > On Wed, Feb 19, 2025 at 02:35:14PM +0100, Louis Chauvet wrote:
> > >>
> > >>
> > >> Le 19/02/2025 à 11:15, Maxime Ripard a écrit :
> > >>> On Wed, Feb 05, 2025 at 04:32:07PM +0100, Louis Chauvet wrote:
> > >>>> On 05/02/25 - 09:55, Maxime Ripard wrote:
> > >>>>> On Mon, Jan 27, 2025 at 11:48:23AM +0100, Louis Chauvet wrote:
> > >>>>>> On 26/01/25 - 18:06, Maxime Ripard wrote:
> > >>>>>>> On Tue, Jan 21, 2025 at 11:48:06AM +0100, Louis Chauvet wrote:
> > >>>>>>>> +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
> > >>>>>>>> + /*
> > >>>>>>>> + * colour.RGB_to_YCbCr(<rgb color in 16 bit form>,
> > >>>>>>>> + * K=colour.WEIGHTS_YCBCR["ITU-R BT.601"],
> > >>>>>>>> + * in_bits = 16,
> > >>>>>>>> + * in_legal = False,
> > >>>>>>>> + * in_int = True,
> > >>>>>>>> + * out_bits = 8,
> > >>>>>>>> + * out_legal = False,
> > >>>>>>>> + * out_int = True)
> > >>>>>>>> + *
> > >>>>>>>> + * Test cases for conversion between YUV BT601 full range and RGB
> > >>>>>>>> + * using the ITU-R BT.601 weights.
> > >>>>>>>> + */
> > >>>>>>>
> > >>>>>>> What are the input and output formats?
> > >>>>>>>
> > >>>>>>> Ditto for all the other tests.
> > >>>>>>
> > >>>>>> There is no really "input" and "output" format, they are reference values
> > >>>>>> for conversion, you should be able to use it in both direction. They are
> > >>>>>> generated by RGB_to_YCbCr (RGB input, YUV output) just because it was
> > >>>>>> easier to create the colors from RGB values.
> > >>>>>
> > >>>>> RGB and YUV aren't formats, they are color models. XRGB8888 is a format.
> > >>>>> NV12 is a format.
> > >>>>>
> > >>>>>> If you think we should specify what is was used as input and output to
> > >>>>>> generate those values, I can modify the comment to:
> > >>>>>>
> > >>>>>> Tests cases for color conversion generated by converting RGB
> > >>>>>> values to YUV BT601 full range using the ITU-R BT.601 weights.
> > >>>>>
> > >>>>> My point is that those comments should provide a way to reimplement the
> > >>>>> test from scratch, and compare to the actual implementation. It's useful
> > >>>>> when you have a test failure and start to wonder if the implementation
> > >>>>> or the test is at fault.
> > >>>>>
> > >>>>> By saying only RGB and YUV, you can't possibly do that.
> > >>>>
> > >>>> I understand your concern, but I believe there might be a slight
> > >>>> misunderstanding. The table in question stores reference values for
> > >>>> specific color models, not formats. Therefore, it doesn't specify any
> > >>>> particular format like XRGB8888 or NV12.
> > >>>>
> > >>>> To clarify this, I can rename the format_pair struct to value_pair. This
> > >>>> should make it clearer that we are dealing with color model values rather
> > >>>> than formats.
> > >>>>
> > >>>> If you want to test a specific format conversion, such as
> > >>>> YUV420_to_argbu16, you would need to follow a process like this:
> > >>>>
> > >>>> // Recreate a YUV420 data
> > >>>> plane_1[0] = test_case.yuv.y
> > >>>> plane_2[0] = test_case.yuv.u
> > >>>> plane_2[1] = test_case.yuv.v
> > >>>>
> > >>>> // convertion to test from YUV420 format to argb_u16
> > >>>> rgb_u16 = convert_YUV420_to_argbu16(plane_1, plane_2)
> > >>>>
> > >>>> // ensure the conversion is valid
> > >>>> assert_eq(rgb_u16, test_case.rgb)
> > >>>>
> > >>>> The current test is not performing this kind of format conversion.
> > >>>> Instead, it verifies that for given (y, u, v) values, the correct (r, g,
> > >>>> b, a) values are obtained.
> > >>>
> > >>> You already stated that you check for the A, R, G, and B components. On
> > >>> how many bits are the values you are comparing stored? The YUV values
> > >>> you are comparing are stored on how many bits for each channel? With
> > >>> subsampling?
> > >>>
> > >>> If you want to compare values, you need to encode a given color into
> > >>> bits, and the way that encoding is done is what the format is about.
> > >>>
> > >>> You might not compare the memory layout but each component individually,
> > >>> but it's still a format.
> > >>
> > >> Sorry, I think I misunderstood what a format really is.
> > >
> > > Ultimately, a format is how a given "color value" is stored. How many
> > > bits will you use? If you have an unaligned number of bits, how many
> > > bits of padding you'll use, where the padding is? If there's multiple
> > > bytes, what's the endianness?
> > >
> > > The answer to all these questions is "the format", and that's why
> > > there's so many of them.
> >
> > Thanks!
> >
> > >> But even with this explanation, I don't understand well what you ask
> > >> me to change. Is this better:
> > >>
> > >> The values are computed by converting RGB values, with each component stored
> > >> as u16, to YUV values, with each component stored as u8. The conversion is
> > >> done from RGB full range to YUV BT601 full range using the ITU-R BT.601
> > >> weights.
> > >>
> > >> TBH, I do not understand what you are asking for exactly. Can you please
> > >> give the sentence you expect directly?
> > >
> > > The fourcc[1] code for the input and output format would be nice. And if
> > > you can't, an ad-hoc definition of the format, answering the questions I
> > > mentionned earlier (and in the previous mail for YUV).
> >
> > I don't think any fourcc code will apply in this case, the tests use
> > internal VKMS structures pixel_argb_16 and pixel_yuv_u8. How do I
> > describe them better? If I add this comment for the structures, is it
> > enough?
> >
> > /**
> > * struct pixel_argb_u16 - Internal representation of a pixel color.
> > * @r: Red component value, stored in 16 bits, without padding, using
> > * machine endianness
> > * @b: [...]
> > *
> > * The goal of this structure is to keep enough precision to ensure
> > * correct composition results in VKMS and simplifying color
> > * manipulation by splitting each component into its own field.
> > * Caution: the byte ordering of this structure is machine-dependent,
> > * you can't cast it directly to AR48 or xR48.
> > */
> > struct pixel_argb_u16 {
> > u16 a, r, g, b;
> > };
> >
> > (ditto for pixel_yuv_u8)
> >
> > > I'm really
> > > surprised about the RGB component values being stored on 16 bits though.
> > > It's super unusual, to the point where it's almost useless for us to
> > > test, and we should probably use 8 bits values.
> >
> > We need to have 16 bits because some of the writeback formats are 16 bits.
>
> Hi Maxime,
>
> Louis' proposed comment is good and accurate. I can elaborate further on
> it.
>
> pixel_argb_u16 is an internal structure used only for temporary pixel
> storage: the intermediate format. It's aim is to make computations on
> pixel values easy: every input format is converted to it before
> computations, and after computations it is converted to each output
> format. This allows VKMS to implement computations, e.g. a matrix
> operation, in simple code for only one cpu-endian "pixel format", the
> intermediate format. (drm_fourcc.h has no cpu-endian formats at all,
> and that is good.)
>
> That VKMS never stores complete images in the intermediate format. To
> strike a balance between temporary memory requirements and
> computational overhead, VKMS processes images line-by-line. Only one
> (or two) line's worth of pixels is needed to be kept in memory per
> source or destination framebuffer at a time.
>
> 16-bit precision is required not just because some writeback and
> framebuffer formats are 16-bit. We also need extra precision due to the
> color value encoding. Transfer functions can convert pixel data between
> the optical and electrical domains. Framebuffers usually contain
> electrical domain data, because it takes less bits per pixel in order
> to achieve a specific level of visual image quality (think of color
> gradient banding). However, some computations, like color space
> conversion with a matrix, must be done in the optical domain, which
> requires more bits per pixel in order to not degrade the image quality.
>
> In the future I would even expect needing 32-bit or even 64-bit per
> channel precision in the intermediate format once higher-than-16 bits
> per channel framebuffer formats require testing.
>
> YUV can work with 8 bits per pixel for now, because in practice YUV is
> always stored in electrical domain due its definition. YUV in optical
> domain is simply never used. However, there are framebuffer formats
> with more than 8 bits of YUV channels, so this may need extending too.
Thanks for your explanations, and yes Louis, I think it's in a much
better shape with your suggestion.
We'd still some additional info like whether you're testing limited vs
full range, but it's most likely going to be on a per-test basis.
Maxime
© 2016 - 2025 Red Hat, Inc.