On Tue, 7 Nov 2023 11:58:26 -0500
Harry Wentland wrote:
> On 2023-11-07 04:55, Pekka Paalanen wrote:
> > On Mon, 6 Nov 2023 11:19:27 -0500
> > Harry Wentland wrote:
> >
> >> On 2023-10-20 06:36, Pekka Paalanen wrote:
> >>> On Thu, 19 Oct 2023 10:56:40 -0400
> >>> Harry Wentland wrote:
> >>
On Wed, Nov 8, 2023 at 11:16 AM Pekka Paalanen wrote:
>
> On Tue, 7 Nov 2023 11:58:26 -0500
> Harry Wentland wrote:
>
> > On 2023-11-07 04:55, Pekka Paalanen wrote:
> > > On Mon, 6 Nov 2023 11:19:27 -0500
> > > Harry Wentland wrote:
> > >
> > >> On 2023-10-20 06:36, Pekka Paalanen 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 ; Shashan
> -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 ; Shashan
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
On 2023-11-08 06:40, Sebastian Wick wrote:
> On Wed, Nov 8, 2023 at 11:16 AM Pekka Paalanen wrote:
>>
>> On Tue, 7 Nov 2023 11:58:26 -0500
>> Harry Wentland wrote:
>>
>>> On 2023-11-07 04:55, Pekka Paalanen wrote:
On Mon, 6 Nov 2023 11:19:27 -0500
Harry Wentland wrote:
> On
On 2023-11-08 06:54, 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
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
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:
> >
> >>
> >> On Tue, 7 Nov 2023 11:58:26 -0500
> >> Harry Wentland wrote:
> >>
> >>> On 2023-11-07 04:55, Pekka Paalanen 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:
>>>
On Tue, 7 Nov 2023 11:58:26 -0500
Harry Wentland wrote:
This is an RFC set for a color pipeline API, along with a sample
implementation in VKMS. All the key API bits are here. VKMS now
supports two named transfer function colorops and two matrix
colorops. We have IGT tests that check all four of these colorops
with a pixel-by-pixel comparison that check
When the floor LUT index (drm_fixp2int(lut_index) is the last
index of the array the ceil LUT index will point to an entry
beyond the array. Make sure we guard against it and use the
value of the floor LUT index.
v3:
- Drop bits from commit description that didn't contribute
anything of value
Unit testing this in VKMS shows that passing 0 into
this function returns -1, which is highly counter-
intuitive. Fix it by checking whether the input is
>= 0 instead of > 0.
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
---
include/drm/drm_fixed.h | 2 +-
1 file changed, 1 insertion(+),
We want to be able to bypass each colorop at all times.
Introduce a new BYPASS boolean property for this.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic_uapi.c | 6 +-
drivers/gpu/drm/drm_colorop.c | 15 +++
include/drm/drm_colorop.h | 20 ++
CTM values are defined as signed-magnitude values. Add
a helper that converts from CTM signed-magnitude fixed
point value to the twos-complement value used by
drm_fixed.
Signed-off-by: Harry Wentland
---
include/drm/drm_fixed.h | 18 ++
1 file changed, 18 insertions(+)
diff --gi
v3:
- Describe DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE (Sebastian)
- Ask for clear documentation of colorop behavior (Sebastian)
v2:
- Update colorop visualizations to match reality (Sebastian, Alex Hung)
- Updated wording (Pekka)
- Change BYPASS wording to make it non-mandatory (Sebastian)
- Dr
This aligns with most other DRM drivers and will allow
us to add new VKMS config options without polluting
the DRM Kconfig.
v3:
- Change SPDX to GPL-2.0-only to match DRM KConfig
SPDX (Simon)
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
---
drivers/gpu/drm/Kconfig | 14 +--
We'll construct color pipelines out of drm_colorop by
chaining them via the NEXT pointer. NEXT will point to
the next drm_colorop in the pipeline, or by 0 if we're
at the end of the pipeline.
v3:
- Add next pointer to colorop to be used by drivers
and in DRM core
Signed-off-by: Harry Wentland
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
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 29 +
include/drm/drm_colorop.h| 5 +
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 59e1797d1ca8..ccf26b034433 100644
--- a/dri
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic_uapi.c | 18 ++
drivers/gpu/drm/drm_colorop.c | 39 +++
include/drm/drm_colorop.h | 20
3 files changed, 72 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
v3:
- Read NEXT ID from drm_colorop's next pointer
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 1 +
include/drm/drm_colorop.h| 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index cf3cb6d1239f..02bb071f73
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 37 ++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
index b995114cf6b8..ad4c2f72fd1e 1
The if/switch statement is bound to grow with more types and
subtypes. Pull this out into its own funcion to make things more
manageable and readable.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/vkms_composer.c | 48
1 file changed, 28 insertions(+), 20 de
This patches introduces a new drm_colorop mode object. This
object represents color transformations and can be used to
define color pipelines.
We also introduce the drm_colorop_state here, as well as
various helpers and state tracking bits.
v3:
- Drop TODO for lock (it's handled in drm_modeset_d
With the introduction of the pre-blending color pipeline we
can no longer have color operations that don't have a clear
position in the color pipeline. We deprecate all existing
plane properties. For upstream drivers those are:
- COLOR_ENCODING
- COLOR_RANGE
Userspace that registers with the
DRM
Add a read-only TYPE property. The TYPE specifies the colorop
type, such as enumerated curve, 1D LUT, CTM, 3D LUT, PWL LUT,
etc.
v3:
- Make TYPE a range property
- Move enum drm_colorop_type to uapi header
- Fix drm_get_colorop_type_name description
For now we're only introducing an enumerated
We're adding a new enum COLOR PIPELINE property. This
property will have entries for each COLOR PIPELINE by
referencing the DRM object ID of the first drm_colorop
of the pipeline. 0 disables the entire COLOR PIPELINE.
Userspace can use this to discover the available color
pipelines, as well as set
This type is used to support a 3x4 matrix in colorops. A 3x4
matrix uses the last column as a "bias" column. Some HW exposes
support for 3x4. The calculation looks like:
out matrixin
|R| |0 1 2 3 | | R |
|G| = |4 5 6 7 | x | G |
|B| |8 9 10 12| | B |
This patch introduces a VKMS color pipeline that includes two
drm_colorops for named transfer functions. For now the only ones
supported are sRGB EOTF, sRGB Inverse EOTF, and a Linear TF.
We will expand this in the future but I don't want to do so
without accompanying IGT tests.
We introduce a new
While working on the CTM implementation of VKMS I had to ascertain
myself of a few assumptions. One of those is whether drm_fixed.h
treats its numbers using signed-magnitude or twos-complement. It is
twos-complement.
In order to make someone else's day easier I am adding the
drm_test_int2fixp test
Certain operations require us to preserve values below 0.0 and
above 1.0 (0x0 and 0x respectively in 16 bpc unorm). One
such operation is a BT709 encoding operation followed by its
decoding operation, or the reverse.
We'll use s32 values as intermediate in and outputs of our
color operations,
We add two 3x4 matrices into the VKMS color pipeline. The reason
we're adding matrices is so that we can test that application
of a matrix and its inverse yields an output equal to the input
image.
One complication with the matrix implementation has to do with
the fact that the matrix entries are
A whole slew of tests for CTM handling that greatly helped in
debugging the CTM code. The extent of tests might seem a bit
silly but they're fast and might someday help save someone
else's day when debugging this.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/tests/vkms_color_tests.c |
34 matches
Mail list logo
