Re: [RFC PATCH 01/10] drm/doc/rfc: Describe why prescriptive color pipeline is needed

2023-11-09 Thread Pekka Paalanen 
On Wed, 8 Nov 2023 11:27:35 -0500
Harry Wentland  wrote:

> On 2023-11-08 11:19, Pekka Paalanen wrote:
> > On Wed, 8 Nov 2023 09:31:17 -0500
> > Harry Wentland  wrote:
> >   
> >> On 2023-11-08 06:40, Sebastian Wick wrote:  
> >>> On Wed, Nov 8, 2023 at 11:16 AM Pekka Paalanen  
> >>> wrote:

...

>  An incremental UAPI development approach is fine by me, meaning that
>  pipelines might not be complete at first, but I believe that requires
>  telling userspace whether the driver developers consider the pipeline
>  complete (no undescribed operations that would significantly change
>  results from the expected results given the UAPI exposed pipeline).
> 
>  The prime example of what I would like to know is that if a FB
>  contains PQ-encoded image and I use a color pipeline to scale that
>  image up, will the interpolation happen before or after the non-linear
>  colorop that decodes PQ. That is a significant difference as pointed
>  out by Joshua.
> 
> >>
> >> That's fair and I want to give that to you. My concern stems from
> >> the sentiment that I hear that any pipeline that doesn't explicitly
> >> advertise this is useless. I don't agree there. Let's not let perfect
> >> be the enemy of good.  
> > 
> > It's up to the use case. The policy of what is sufficient should reside
> > in userspace.
> > 
> > What about matching compositor shader composition with KMS?
> > 
> > Can we use that as a rough precision threshold? If userspace implements
> > the exact same color pipeline as the KMS UAPI describes, then that and
> > the KMS composited result should be indistinguishable in side-by-side
> > or alternating visual inspection on any monitor in isolation.
> > 
> > Did this whole effort not start from wanting to off-load things to
> > display hardware but still maintain visual equivalence to software/GPU
> > composition?
> >   
> 
> I agree with you and I want all that as well.
> 
> All I'm saying is that every userspace won't have the same policy of
> what is sufficient. Just because Weston has a very high threshold
> doesn't mean we can't move forward with a workable solution for other
> userspace, as long as we don't do something that prevents us from
> doing the perfect solution eventually.
> 
> And yes, I do want a solution that works for Weston and hear your
> comments on what that requires.

I totally agree.

How will that be reflected in the UAPI? If some pipelines are different
from others in correctness/strictness perspective, how will userspace
tell them apart?

Is the current proposal along the lines of: userspace creates a
software pipeline first, and if it cannot map all operations on it to
KMS color pipeline colorops, then the KMS pipeline is not sufficient?

The gist being, if the software pipeline is scaling the image for
example, then it must find a scaling colorop in the KMS pipeline if it
cares about the scaling correctness.

Another example is YUV pixel format on an FB that magically turns into
some kind of RGB when sampled, but there is no colorop to tell what
happens. I suppose userspace cannot assume that the lack of colorop
there means an identity YUV->RGB matrix either? How to model
that? I guess the already mentioned pixel format requirements on a
pipeline would help, making it impossible to use a pipeline without a
YUV->RGB colorop on a YUV FB unless the lack of colorop does indeed
mean an identity matrix.

The same with sub-sampled YUV which probably needs to always(?) be
expanded into fully sampled at the beginning of a pipeline? Chroma
siting.

This is in addition to the previously discussed userspace policy that
if a KMS color pipeline contains colorops the userspace does not
recognise, userspace probably should not pick that pipeline under any
conditions, because it might do something completely unexpected.

I think the above could work, but I feel it requires documenting several
examples like scaling that might not exist in the colorop definitions
at first. Otherwise particularly userspace developers might not come to
think of them, whether they care about those operations. I haven't read
the latest doc yet, so I'm not sure if it's already there.

There is still a gap though: what if the hardware does something
significant that is not modelled in the KMS pipeline with colorops? For
example, always using a hard-wired sRGB curve to decode before blending
and encode after blending. Or that cursor plane always uses the color
pipeline set on the primary plane. How to stop userspace from being
surprised?

Your comments sounded to me like you are letting go of the original
design goals. I'm happy to hear that's not the case. Even if you were,
that is a decision you can make since you are doing the work, and if I
knew you're doing that intentionally I would stop complaining.


Thanks,
pq


pgptGM_pS94NJ.pgp
Description: OpenPGP digital signature

RE: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed

2023-11-09 Thread Shankar, Uma 


> -Original Message-
> From: Joshua Ashton 
> Sent: Wednesday, November 8, 2023 7:13 PM
> To: Shankar, Uma ; Harry Wentland
> ; dri-de...@lists.freedesktop.org
> Cc: wayland-devel@lists.freedesktop.org; Ville Syrjala
> ; Pekka Paalanen
> ; Simon Ser ; Melissa
> Wen ; Jonas Ådahl ; Sebastian Wick
> ; Shashank Sharma
> ; Alexander Goins ; Michel
> Dänzer ; Aleix Pol ; Xaver Hugl
> ; Victoria Brekenfeld ; Sima
> ; Naseer Ahmed ; Christopher
> Braga ; Abhinav Kumar
> ; Arthur Grillo ; Hector
> Martin ; Liviu Dudau ; Sasha
> McIntosh 
> Subject: Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color
> pipeline is needed
> 
> 
> 
> On 11/8/23 12:18, Shankar, Uma wrote:
> >
> >
> >> -Original Message-
> >> From: Harry Wentland 
> >> Sent: Friday, October 20, 2023 2:51 AM
> >> To: dri-de...@lists.freedesktop.org
> >> Cc: wayland-devel@lists.freedesktop.org; Harry Wentland
> >> ; Ville Syrjala
> >> ; Pekka Paalanen
> >> ; Simon Ser ;
> >> Melissa Wen ; Jonas Ådahl ;
> >> Sebastian Wick ; Shashank Sharma
> >> ; Alexander Goins ;
> >> Joshua Ashton ; Michel Dänzer
> >> ; Aleix Pol ; Xaver Hugl
> >> ; Victoria Brekenfeld ;
> >> Sima ; Shankar, Uma ; Naseer
> >> Ahmed ; Christopher Braga
> >> ; Abhinav Kumar ;
> >> Arthur Grillo ; Hector Martin
> >> ; Liviu Dudau ; Sasha McIntosh
> >> 
> >> Subject: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive
> >> color pipeline is needed
> >>
> >> v2:
> >>   - Update colorop visualizations to match reality (Sebastian, Alex Hung)
> >>   - Updated wording (Pekka)
> >>   - Change BYPASS wording to make it non-mandatory (Sebastian)
> >>   - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property
> >> section (Pekka)
> >>   - Use PQ EOTF instead of its inverse in Pipeline Programming example
> (Melissa)
> >>   - Add "Driver Implementer's Guide" section (Pekka)
> >>   - Add "Driver Forward/Backward Compatibility" section (Sebastian,
> >> Pekka)
> >>
> >> Signed-off-by: Harry Wentland 
> >> Cc: Ville Syrjala 
> >> Cc: Pekka Paalanen 
> >> Cc: Simon Ser 
> >> Cc: Harry Wentland 
> >> Cc: Melissa Wen 
> >> Cc: Jonas Ådahl 
> >> Cc: Sebastian Wick 
> >> Cc: Shashank Sharma 
> >> Cc: Alexander Goins 
> >> Cc: Joshua Ashton 
> >> Cc: Michel Dänzer 
> >> Cc: Aleix Pol 
> >> Cc: Xaver Hugl 
> >> Cc: Victoria Brekenfeld 
> >> Cc: Sima 
> >> Cc: Uma Shankar 
> >> Cc: Naseer Ahmed 
> >> Cc: Christopher Braga 
> >> Cc: Abhinav Kumar 
> >> Cc: Arthur Grillo 
> >> Cc: Hector Martin 
> >> Cc: Liviu Dudau 
> >> Cc: Sasha McIntosh 
> >> ---
> >>   Documentation/gpu/rfc/color_pipeline.rst | 347 +++
> >>   1 file changed, 347 insertions(+)
> >>   create mode 100644 Documentation/gpu/rfc/color_pipeline.rst
> >>
> >> diff --git a/Documentation/gpu/rfc/color_pipeline.rst
> >> b/Documentation/gpu/rfc/color_pipeline.rst
> >> new file mode 100644
> >> index ..af5f2ea29116
> >> --- /dev/null
> >> +++ b/Documentation/gpu/rfc/color_pipeline.rst
> >> @@ -0,0 +1,347 @@
> >> +
> >> +Linux Color Pipeline API
> >> +
> >> +
> >> +What problem are we solving?
> >> +
> >> +
> >> +We would like to support pre-, and post-blending complex color
> >> +transformations in display controller hardware in order to allow for
> >> +HW-supported HDR use-cases, as well as to provide support to
> >> +color-managed applications, such as video or image editors.
> >> +
> >> +It is possible to support an HDR output on HW supporting the
> >> +Colorspace and HDR Metadata drm_connector properties, but that
> >> +requires the compositor or application to render and compose the
> >> +content into one final buffer intended for display. Doing so is costly.
> >> +
> >> +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices,
> >> +and other operations to support color transformations. These
> >> +operations are often implemented in fixed-function HW and therefore
> >> +much more power efficient than performing similar operations via shaders 
> >> or
> CPU.
> >> +
> >> +We would like to make use of this HW functionality to support
> >> +complex color transformations with no, or minimal CPU or shader load.
> >> +
> >> +
> >> +How are other OSes solving this problem?
> >> +
> >> +
> >> +The most widely supported use-cases regard HDR content, whether
> >> +video or gaming.
> >> +
> >> +Most OSes will specify the source content format (color gamut,
> >> +encoding transfer function, and other metadata, such as max and
> >> +average light levels) to a
> >> driver.
> >> +Drivers will then program their fixed-function HW accordingly to map
> >> +from a source content buffer's space to a display's space.
> >> +
> >> +When fixed-function HW is not available the compositor will assemble
> >> +a shader to ask the GPU to perform the transformation from the
> >> +source content format to the display's format.
> >> +
> >> +A compositor's mapping fu

RE: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed

2023-11-09 Thread Shankar, Uma 


> -Original Message-
> From: Harry Wentland 
> Sent: Wednesday, November 8, 2023 8:08 PM
> To: Shankar, Uma ; dri-de...@lists.freedesktop.org
> Cc: wayland-devel@lists.freedesktop.org; Ville Syrjala
> ; Pekka Paalanen
> ; Simon Ser ; Melissa
> Wen ; Jonas Ådahl ; Sebastian Wick
> ; Shashank Sharma
> ; Alexander Goins ; Joshua
> Ashton ; Michel Dänzer ; Aleix Pol
> ; Xaver Hugl ; Victoria Brekenfeld
> ; Sima ; Naseer Ahmed
> ; Christopher Braga ;
> Abhinav Kumar ; Arthur Grillo
> ; Hector Martin ; Liviu Dudau
> ; Sasha McIntosh 
> Subject: Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color
> pipeline is needed
> 
> 
> 
> On 2023-11-08 07:18, Shankar, Uma wrote:
> >
> >
> >> -Original Message-
> >> From: Harry Wentland 
> >> Sent: Friday, October 20, 2023 2:51 AM
> >> To: dri-de...@lists.freedesktop.org
> >> Cc: wayland-devel@lists.freedesktop.org; Harry Wentland
> >> ; Ville Syrjala
> >> ; Pekka Paalanen
> >> ; Simon Ser ;
> >> Melissa Wen ; Jonas Ådahl ;
> >> Sebastian Wick ; Shashank Sharma
> >> ; Alexander Goins ;
> >> Joshua Ashton ; Michel Dänzer
> >> ; Aleix Pol ; Xaver Hugl
> >> ; Victoria Brekenfeld ;
> >> Sima ; Shankar, Uma ; Naseer
> >> Ahmed ; Christopher Braga
> >> ; Abhinav Kumar ;
> >> Arthur Grillo ; Hector Martin
> >> ; Liviu Dudau ; Sasha McIntosh
> >> 
> >> Subject: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive
> >> color pipeline is needed
> >>
> >> v2:
> >>  - Update colorop visualizations to match reality (Sebastian, Alex
> >> Hung)
> >>  - Updated wording (Pekka)
> >>  - Change BYPASS wording to make it non-mandatory (Sebastian)
> >>  - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property
> >>section (Pekka)
> >>  - Use PQ EOTF instead of its inverse in Pipeline Programming example
> >> (Melissa)
> >>  - Add "Driver Implementer's Guide" section (Pekka)
> >>  - Add "Driver Forward/Backward Compatibility" section (Sebastian,
> >> Pekka)
> >>
> >> Signed-off-by: Harry Wentland 
> >> Cc: Ville Syrjala 
> >> Cc: Pekka Paalanen 
> >> Cc: Simon Ser 
> >> Cc: Harry Wentland 
> >> Cc: Melissa Wen 
> >> Cc: Jonas Ådahl 
> >> Cc: Sebastian Wick 
> >> Cc: Shashank Sharma 
> >> Cc: Alexander Goins 
> >> Cc: Joshua Ashton 
> >> Cc: Michel Dänzer 
> >> Cc: Aleix Pol 
> >> Cc: Xaver Hugl 
> >> Cc: Victoria Brekenfeld 
> >> Cc: Sima 
> >> Cc: Uma Shankar 
> >> Cc: Naseer Ahmed 
> >> Cc: Christopher Braga 
> >> Cc: Abhinav Kumar 
> >> Cc: Arthur Grillo 
> >> Cc: Hector Martin 
> >> Cc: Liviu Dudau 
> >> Cc: Sasha McIntosh 
> >> ---
> >>  Documentation/gpu/rfc/color_pipeline.rst | 347
> >> +++
> >>  1 file changed, 347 insertions(+)
> >>  create mode 100644 Documentation/gpu/rfc/color_pipeline.rst
> >>
> >> diff --git a/Documentation/gpu/rfc/color_pipeline.rst
> >> b/Documentation/gpu/rfc/color_pipeline.rst
> >> new file mode 100644
> >> index ..af5f2ea29116
> >> --- /dev/null
> >> +++ b/Documentation/gpu/rfc/color_pipeline.rst
> >> @@ -0,0 +1,347 @@
> >> +
> >> +Linux Color Pipeline API
> >> +
> >> +
> >> +What problem are we solving?
> >> +
> >> +
> >> +We would like to support pre-, and post-blending complex color
> >> +transformations in display controller hardware in order to allow for
> >> +HW-supported HDR use-cases, as well as to provide support to
> >> +color-managed applications, such as video or image editors.
> >> +
> >> +It is possible to support an HDR output on HW supporting the
> >> +Colorspace and HDR Metadata drm_connector properties, but that
> >> +requires the compositor or application to render and compose the
> >> +content into one final buffer intended for display. Doing so is costly.
> >> +
> >> +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices,
> >> +and other operations to support color transformations. These
> >> +operations are often implemented in fixed-function HW and therefore
> >> +much more power efficient than performing similar operations via shaders 
> >> or
> CPU.
> >> +
> >> +We would like to make use of this HW functionality to support
> >> +complex color transformations with no, or minimal CPU or shader load.
> >> +
> >> +
> >> +How are other OSes solving this problem?
> >> +
> >> +
> >> +The most widely supported use-cases regard HDR content, whether
> >> +video or gaming.
> >> +
> >> +Most OSes will specify the source content format (color gamut,
> >> +encoding transfer function, and other metadata, such as max and
> >> +average light levels) to a
> >> driver.
> >> +Drivers will then program their fixed-function HW accordingly to map
> >> +from a source content buffer's space to a display's space.
> >> +
> >> +When fixed-function HW is not available the compositor will assemble
> >> +a shader to ask the GPU to perform the transformation from the
> >> +source content format to the display's format.
> >> +
> >> +A compositor's mapping

Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed

2023-11-09 Thread Pekka Paalanen 
On Thu, 9 Nov 2023 10:17:11 +
"Shankar, Uma"  wrote:

> > -Original Message-
> > From: Joshua Ashton 
> > Sent: Wednesday, November 8, 2023 7:13 PM
> > To: Shankar, Uma ; Harry Wentland
> > ; dri-de...@lists.freedesktop.org

...

> > Subject: Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive 
> > color
> > pipeline is needed
> > 
> > 
> > 
> > On 11/8/23 12:18, Shankar, Uma wrote:  
> > >
> > >  
> > >> -Original Message-
> > >> From: Harry Wentland 
> > >> Sent: Friday, October 20, 2023 2:51 AM
> > >> To: dri-de...@lists.freedesktop.org

...

> > >> Subject: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive
> > >> color pipeline is needed

...

> > >> +An example of a drm_colorop object might look like one of these::
> > >> +
> > >> +/* 1D enumerated curve */
> > >> +Color operation 42
> > >> +├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3
> > >> + matrix, 3x4
> > >> matrix, 3D LUT, etc.} = 1D enumerated curve
> > >> +├─ "BYPASS": bool {true, false}
> > >> +├─ "CURVE_1D_TYPE": enum {sRGB EOTF, sRGB inverse EOTF, PQ EOTF,
> > >> + PQ
> > >> inverse EOTF, …}  
> > >
> > > Having the fixed function enum for some targeted input/output may not
> > > be scalable for all usecases. There are multiple colorspaces and
> > > transfer functions possible, so it will not be possible to cover all
> > > these by any enum definitions. Also, this will depend on the capabilities 
> > > of  
> > respective hardware from various vendors.
> > 
> > The reason this exists is such that certain HW vendors such as AMD have 
> > transfer
> > functions implemented in HW. It is important to take advantage of these for 
> > both
> > precision and power reasons.  
> 
> Issue we see here is that, it will be too usecase and vendor specific.
> There will be BT601, BT709, BT2020, SRGB, HDR EOTF and many more. Not to 
> forget
> we will need linearization and non-linearization enums for each of these.

I don't see that as a problem at all. It's not a combinatorial
explosion like input/output combinations in a single enum would be.
It's always a curve and its inverse at most.

It's KMS properties, not every driver needs to implement every
defined enum value but only those values it can and wants to support.
Userspace also sees the supported list, it does not need trial and
error.

This is the only way to actually use hard-wired curves. The
alternative would be for userspace to submit a LUT of some type, and
the driver needs to start guessing if it matches one of the hard-wired
curves the hardware supports, which is just not feasible.

Hard-wired curves are an addition, not a replacement, to custom
curves defined by parameters or various different LUT representations.
Many of these hard-wired curves will emerge as is from common use cases.

> Also 
> a CTM indication to convert colospace.

Did someone propose to enumerate matrices? I would not do that, unless
you literally have hard-wired matrices in hardware and cannot do custom
matrices.

> Also, if the underlying hardware block is 
> programmable, its not limited to be used only for the colorspace management 
> but
> can be used for other color enhancements as well by a capable client.

Yes, that's why we have other types for curves, the programmable ones.

> Hence, we feel that it is bordering on being descriptive with too many 
> possible
> combinations (not easy to generalize). So, if hardware is programmable, lets
> expose its capability through a blob and be generic.

It's not descriptive though. It's a prescription of a mathematical
function the hardware implements as fixed-function hardware. The
function is a curve. There is no implication that the curve must be
used with specific input or output color spaces.

> For any fixed function hardware where Lut etc is stored in ROM and just a 
> control/enable
> bit is provided to driver, we can define a pipeline with a vendor specific 
> color block. This
> can be identified with a flag (better ways can be discussed). 

No, there is no need for that. A curve type will do well.

A vendor specific colorop needs vendor specific userspace code to
program *at all*. A generic curve colorop might list some curve types
the userspace does not understand, but also curve types userspace does
understand. The understood curve types can still be used by userspace.

> For example, on some of the Intel platform, we had a fixed function to 
> convert colorspaces
> directly with a bit setting. These kinds of things should be vendor specific 
> and not be part
> of generic userspace implementation.

Why would you forbid generic userspace from making use of them?

> For reference:
> 001b  YUV601 to RGB601 YUV BT.601 to RGB BT.601 conversion.
> 010b  YUV709 to RGB709 YUV BT.709 to RGB BT.709 conversion.
> 011b  YUV2020 to RGB2020 YUV BT.2020 to RGB BT.2020 conversion.
> 100b  RGB709 to RGB2020 RGB BT.709 to RGB BT.2020 conversion.

This is nothing like the curves we talked about above

Re: [RFC PATCH v3 04/23] drm/vkms: Add kunit tests for VKMS LUT handling

2023-11-09 Thread Arthur Grillo 



On 08/11/23 13:36, Harry Wentland wrote:
> Debugging LUT math is much easier when we can unit test
> it. Add kunit functionality to VKMS and add tests for
>  - get_lut_index
>  - lerp_u16
> 
> v3:
>  - Use include way of testing static functions (Arthur)
> 
> Signed-off-by: Harry Wentland 
> Cc: Arthur Grillo 
> ---
>  drivers/gpu/drm/vkms/Kconfig  |  5 ++
>  drivers/gpu/drm/vkms/tests/.kunitconfig   |  4 ++
>  drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 62 +++
>  drivers/gpu/drm/vkms/vkms_composer.c  |  8 ++-
>  4 files changed, 77 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
>  create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_tests.c
> 
> diff --git a/drivers/gpu/drm/vkms/Kconfig b/drivers/gpu/drm/vkms/Kconfig
> index b9ecdebecb0b..c1f8b343ff0e 100644
> --- a/drivers/gpu/drm/vkms/Kconfig
> +++ b/drivers/gpu/drm/vkms/Kconfig
> @@ -13,3 +13,8 @@ config DRM_VKMS
> a VKMS.
>  
> If M is selected the module will be called vkms.
> +
> +config DRM_VKMS_KUNIT_TESTS
> + tristate "Tests for VKMS" if !KUNIT_ALL_TESTS
> + depends on DRM_VKMS && KUNIT
> + default KUNIT_ALL_TESTS
> diff --git a/drivers/gpu/drm/vkms/tests/.kunitconfig 
> b/drivers/gpu/drm/vkms/tests/.kunitconfig
> new file mode 100644
> index ..70e378228cbd
> --- /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/vkms_color_tests.c 
> b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
> new file mode 100644
> index ..b995114cf6b8
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +
> +#include 
> +
> +#include 
> +
> +#define TEST_LUT_SIZE 16
> +
> +static struct drm_color_lut test_linear_array[TEST_LUT_SIZE] = {
> + { 0x0, 0x0, 0x0, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> +};
> +
> +const struct vkms_color_lut test_linear_lut = {
> + .base = test_linear_array,
> + .lut_length = TEST_LUT_SIZE,
> + .channel_value2index_ratio = 0xf000fll
> +};
> +
> +
> +static void vkms_color_test_get_lut_index(struct kunit *test)
> +{
> + int i;
> +
> + KUNIT_EXPECT_EQ(test, drm_fixp2int(get_lut_index(&test_linear_lut, 
> test_linear_array[0].red)), 0);
> +
> + for (i = 0; i < TEST_LUT_SIZE; i++)
> + KUNIT_EXPECT_EQ(test, 
> drm_fixp2int_ceil(get_lut_index(&test_linear_lut, test_linear_array[i].red)), 
> i);
> +}
> +
> +static void vkms_color_test_lerp(struct kunit *test)
> +{
> + KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, 0x8000), 0x8);
> +}
> +
> +static struct kunit_case vkms_color_test_cases[] = {
> + KUNIT_CASE(vkms_color_test_get_lut_index),
> + KUNIT_CASE(vkms_color_test_lerp),
> + {}
> +};
> +
> +static struct kunit_suite vkms_color_test_suite = {
> + .name = "vkms-color",
> + .test_cases = vkms_color_test_cases,
> +};
> +kunit_test_suite(vkms_color_test_suite);
> +
> +MODULE_LICENSE("GPL");
> \ No newline at end of file
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 3c99fb8b54e2..6f942896036e 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -91,7 +91,7 @@ static void fill_background(const struct pixel_argb_u16 
> *background_color,
>  }
>  
>  // lerp(a, b, t) = a + (b - a) * t
> -static u16 lerp_u16(u16 a, u16 b, s64 t)
> +u16 lerp_u16(u16 a, u16 b, s64 t)

Now you don't need to remove the static keyword.

>  {
>   s64 a_fp = drm_int2fixp(a);
>   s64 b_fp = drm_int2fixp(b);
> @@ -101,7 +101,7 @@ static u16 lerp_u16(u16 a, u16 b, s64 t)
>   return drm_fixp2int(a_fp + delta);
>  }
>  
> -static s64 get_lut_index(const struct vkms_color_lut *lut, u16 channel_value)
> +s64 get_lut_index(const struct vkms_color_lut *lut, u16 channel_value)

DITTO

Best Regards,
~Arthur Grillo

>  {
>   s64 color_channel_fp = drm_int2fixp(channel_value);
>  
> @@ -429,3 +429,7 @@ int vkms_set_crc_source(struct drm_crtc *crtc, const char 
> *src_name)
>  
>   return ret;
>  }
> +
> +#ifdef CONFIG_DRM_VKMS_KUNIT_TESTS
> +#include "tests/vkms_color_tests.c"
> +#endif