From: Alex Hung
Expose a 2nd curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF and program HW to
perform the sRGB Inverse EOTF on the shaper block
when the colorop is not in bypass.
With this change the follow IGT tests pass:
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf
kms_co
From: Alex Hung
We've previously introduced DRM_COLOROP_1D_CURVE for
pre-defined 1D curves. But we also have HW that supports
custom curves and userspace needs the ability to pass
custom curves, aka LUTs.
This patch introduces a new colorop type, called
DRM_COLOROP_1D_LUT that provides a SIZE pr
v4:
- Drop IOCTL docs since we dropped the IOCTLs (Pekka)
- Clarify reading and setting of COLOR_PIPELINE prop (Pekka)
- Add blurb about not requiring to reject a pipeline due to
incompatible ops, as long as op can be bypassed (Pekka)
- Dropped informational strings (such as input CSC) as th
From: Alex Hung
This adds support for a 3x4 color transformation matrix.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-ctm_3x4_50_desat
kms_colorop --run plane-XR30-XR30-ctm_3x4_overdrive
kms_colorop --run plane-XR30-XR30-ctm_3x4_oversaturate
kms_colorop --run
From: Alex Hung
This adds support for a multiplier. This multiplier is
programmed via the HDR Multiplier in DCN.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-multiply_125
kms_colorop --run plane-XR30-XR30-multiply_inv_125
The color pipeline now consists of th
From: Alex Hung
This introduces a new drm_colorop_type: DRM_COLOROP_MULTIPLIER.
It's a simple multiplier to all pixel values. The value is
specified via a S31.32 fixed point provided via the
"MULTIPLIER" property.
Signed-off-by: Alex Hung
---
drivers/gpu/drm/drm_atomic.c | 3 +++
driver
The BT.709 and BT.2020 OETFs are the same, the only difference
being that the BT.2020 variant is defined with more precision
for 10 and 12-bit per color encodings.
Both are used as encoding functions for video content, and are
therefore defined as OETF (opto-electronic transfer function)
instead o
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
This patchset enables support for the PQ_125 EOTF and its inverse
on all existing plane 1D curve colorops, i.e., on DEGAM, SHAPER,
and BLND blocks.
With this patchset the following IGT subtests are passing:
kms_colorop --run plane-XR30-XR30-pq_125_eotf
kms_colorop --run plane-XR30-XR30-pq_125_inv_
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
From: Alex Hung
Expose a 3rd 1D curve colorop, with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program the BLND block
to perform the sRGB transform when the colorop is not in
bypass
With this change the following IGT test passes:
kms_colorop --run plane-XR30-XR30-srgb_eotf-srgb_inv_eotf-srgb
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 11| | B |
From: Alex Hung
Expose one 1D curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
the sRGB transform when the colorop is not in bypass.
With this change the following IGT test passes:
kms_colorop --run plane-XR30-XR30-srgb_eotf
The color pipeline now consists
From: Alex Hung
This patch adds colorops for custom 1D LUTs in the SHAPER and
BLND HW blocks.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut-srgb_eotf_lut
The color pipeline now consists of t
The PQ function defines a mapping of code values to nits (cd/m^2).
The max code value maps to 10,000 nits.
Windows DWM's canonical composition color space (CCCS) defaults
to composing SDR contents to 80 nits and uses a float value of
1.0 to represent this. For this reason AMD HW hard-codes a PQ
f
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 adds support for the BT.709/BT.2020 transfer functions
on all current 1D curve plane colorops, i.e., on DEGAM, SHAPER,
and BLND blocks.
With this change the following IGT subtests pass:
kms_colorop --run plane-XR30-XR30-bt2020_inv_oetf
kms_colorop --run plane-XR30-XR30-bt2020_oetf
Signed-off
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
From: Alex Hung
Signed-off-by: Alex Hung
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index c5c07b4cd6c9..d3f6
Drivers will need to know whether an atomic check/commit
originated from a client with DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
so they can ignore deprecated properties, like COLOR_ENCODING
and COLOR_RANGE.
Pass the plane_color_pipeline bit to drm_atomic_state.
Signed-off-by: Harry Wentland
---
driv
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.
v4:
- Comment on origin of bt709_enc matrix (Pekka)
- Use full opaque alpha (Pekka
Add the default Bypass pipeline and ensure it passes the
kms_colorop test plane-XR30-XR30-bypass.
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_
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.
v4:
- Allow setting of NEXT property to NULL (Chaitanya Kumar Borah)
v3:
- Add next pointer to colorop
From: Alex Hung
Create a new macro for_each_new_colorop_in_state to access new
drm_colorop_state updated from uapi.
Signed-off-by: Alex Hung
---
include/drm/drm_atomic.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.
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
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
Drivers are expected to ignore these
v4:
- Use drm_colorop_curve_1d_type_enum_list to get name (Pekka)
- Create separate init function for 1D curve
- Pass supported TFs into 1D curve init function
Signed-off-by: Harry Wentland
Signed-off-by: Alex Hung
Co-developed-by: Alex Hung
---
drivers/gpu/drm/drm_atomic_uapi.c | 18 +-
When the plane_color_pipeline bit is set we should ignore
deprecated properties, such as COLOR_RANGE and COLOR_ENCODING.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_
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,
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
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 27a8805c5fa1..d82858dabf
Add a read-only TYPE property. The TYPE specifies the colorop
type, such as enumerated curve, 1D LUT, CTM, 3D LUT, PWL LUT,
etc.
v4:
- Use enum property for TYPE (Pekka)
v3:
- Make TYPE a range property
- Move enum drm_colorop_type to uapi header
- Fix drm_get_colorop_type_name description
F
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 25 -
include/drm/drm_colorop.h| 5 +
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b400e32c9d39..3645c36d63b3 10064
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 fc73e48aa57c..e6ac01dee830 1
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 | 16
include/drm/drm_colorop.h | 20 +
fixp2int always rounds down, fixp2int_ceil rounds up. We need
the new fixp2int_round.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/vkms_composer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_compo
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.
v4:
- Drop IOCTL definitions (Pekka)
- add missing dec
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
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
v4:
- Test the critical points of the lerp function (Pekka)
v3:
- Use include way of testing static functions (Arthur)
Signed-off-by: Harry Wentland
Cc: A
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 +--
A value of 0x8000 and higher should round up, and
below should round down. VKMS Kunit tests for lerp_u16
showed that this is not the case. Fix it.
1 << (DRM_FIXED_POINT_HALF - 1) =
1 << 15 = 0x8000
This is not 0.5, but 0.0762939453125.
Instead of some smart math use a simple if/else to
r
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
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.
Fixes: 64566b5e767f9 ("drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil")
Signed-off-by: Harry Wentland
Reviewed-by:
On Mon, 26 Feb 2024 15:12:23 +0200
Pekka Paalanen wrote:
...
> > What is the advantage to having the impacted clients grow their send
> > buffers while waiting? They wait either way.
>
> They are not waiting if they are growing their send buffers.
I meant that they must wait for the UI to up
Hi Michel,
Oh wow yes can confirm: /usr/bin/gnome-calculator works thank you! Indeed it
displays calculator on my Windows 10 (Version 22H2 build 19045.4046) PC with
Ubuntu-22.04 WSL2:
PS C:\WINDOWS\system32> wsl -l -v
NAMESTATE VERSION
* Ubuntu-22.04Running 2
On 2024-02-26 16:36, Colin Rudakiewicz wrote:
>
> 1. From centos91 running: waypipe ssh owner@centos92 gnome-terminal, a
> terminal is launched on centos92 but was expecting to see it on centos91?
This is likely because the gnome-terminal executable itself doesn't create the
terminal window,
On Mon, 26 Feb 2024 15:18:27 +
Terry Barnaby wrote:
> Hi Pekka,
>
> Thanks for the response. Notes below:
>
> Terry
>
> On 26/02/2024 13:28, Pekka Paalanen wrote:
> > On Sun, 25 Feb 2024 08:04:30 +
> > Terry Barnaby wrote:
> >
> >> Hi,
> >>
> >> I have investigated a bit further. I
Hallo,
Have two Centos 9 hosts centos91 (172.28.0.178) and centos92 (172.28.0.179);
VMWare cloned. Using owner account can ssh (using gnome-terminal) between
the two using private/public key (password-less/no ssh passphrase set).
Firwalled service is stopped and iptables flushed.
1. Fr
Hi Pekka,
Thanks for the response. Notes below:
Terry
On 26/02/2024 13:28, Pekka Paalanen wrote:
On Sun, 25 Feb 2024 08:04:30 +
Terry Barnaby wrote:
Hi,
I have investigated a bit further. I have built my own Weston server to
run under X11 on Fedora37 so I can add printf's and debug mor
On Sun, 25 Feb 2024 08:04:30 +
Terry Barnaby wrote:
> Hi,
>
> I have investigated a bit further. I have built my own Weston server to
> run under X11 on Fedora37 so I can add printf's and debug more easily
> than using a cross compiled iMX8mp target system etc. I added a new
> dsmc-shell
On Sat, 24 Feb 2024 15:35:27 -0500
jleivent wrote:
> On Fri, 23 Feb 2024 12:12:38 +0200
> Pekka Paalanen wrote:
>
>
> > I would think it to be quite difficult for a compositor to dedicate a
> > whole thread for each client.
>
> But that means it is possible that the server cannot catch up f
51 matches
Mail list logo
