On 2026-03-24 13:01, Borah, Chaitanya Kumar wrote:
> Hello Harry,
>
> Few thoughts on the series from Intel perspective.
>
> On 3/17/2026 9:33 PM, Harry Wentland wrote:
>> When we merged the drm_plane color pipeline API the major gap
>> that existed was the lack of a color-space conversion colorop.
>> We deprecated any legacy drm_plane color properties, which
>> means that the COLOR_RANGE and COLOR_ENCODING properties can't
>> be used with the COLOR_PIPELINE property on a drm_plane. In
>> practice this means that we can't use a COLOR_PIPELINE on
>> YCbCr encoded framebuffers.
>>
>> This patchset adds a CSC colorop with the COLOR_RANGE and
>> COLOR_ENCODING properties and implements support in VKMS and
>> amdgpu.
>>
>
> AFAIU, while COLOR_RANGE and COLOR_ENCODING were plane properties, they were
> more representative of how the framebuffer provided to the plane should be
> interpreted, rather than selecting a transformation. So using them to define
> CSC behavior is bit of a semantic drift.
>
I guess CSC is misleading for this colorop. YUV conversion would
describe it better.
> From, Intel's HW perspective we could re-use this CSC colorop but it would be
> preferable to introduce new enums like "YCbCr709 to RGB", "YCbCr601 to RGB"
> as discussed in [1]. That way we can still represent the "RGB709 to RGB2020"
> conversion that Intel's fixed matrix CSC supports (instead of inventing a new
> colorop). We might need to change the name of colorop to something like Fixed
> Matrix to be inclusive of both YCbCr to RGB conversion and Primary conversion.
>
At the core your CSC FF colorop and the one I'm trying to introduce are
both backed by a fixed matrix. We could even express the range via the
CSC FF colorop by introducing full and limited matrix variants for
YCbCr to RGB conversion, like "YCbCr709 limited to RGB" (which is
probably the norm for SDR/sRGB) and "YCbCr709 full to RGB" for full
range YCbCr content.
For BT.601, BT.709, BT.2020 and full and limited range that would give
us 6 enum entries, which is quite manageable.
Intel would then only advertise the full-range enums, plus the RGB-to-RGB
CSC enums (like RGB709 to RGB2020) while AMD would advertise full and
limited range YCbCr to RGB enums only, no RGB-to-RGB variants.
If this makes sense to you I'll be happy to rework my YUV conversion
patches based on that. I think that'll work fine.
> Regarding the range property, we could re-use the COLOR_RANGE property as you
> have done. In the case of Intel, we would only expose
> DRM_COLOR_YCBCR_FULL_RANGE as supported for this CSC, and use a separate
> colorop to perform YUV range correction. This allows userspace to still pass
> limited-range framebuffers. I am assuming here that it matters for user-space
> if the conversion was done in limited or full range.
>
It sounds like you'd need another colorop for range conversion. I wonder if
it makes sense to also use the CSC FF block for that and introduce a
"YUV limited to YUV full" range conversion enum. In that case naming the
op named_matrix, might work better, as it can express range conversion,
YUV conversion, and color space conversions.
Harry
> [1]
> https://lore.kernel.org/dri-devel/[email protected]/
>
> ==
> Chaitanya
>
>> An alternate way of possibly representing this has been proposed
>> here:
>> https://patchwork.freedesktop.org/patch/709860
>>
>> This code has been tested with IGT and an experimental KWin branch.
>>
>> IGT branch:
>> https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/tree/csc-colorop
>>
>> KWin branch:
>> https://invent.kde.org/hwentlan/kwin/-/tree/csc-3dlut
>>
>> The kernel branch containing these changes, based on drm-misc-next
>> can be found at:
>> https://gitlab.freedesktop.org/hwentland/linux/-/tree/csc-colorop
>>
>> In order to successfully use this branch you might need a few
>> bugfixes. The kernel tree containing those fixes plus these patches
>> can be found at:
>> https://gitlab.freedesktop.org/hwentland/linux/-/tree/csc-colorop-all
>>
>> Further background on this work can be found at:
>> https://hwentland.github.io/2026/03/10/plane-color-pipeline-csc-3d-lut-kwin.html
>>
>> Cc: Alex Hung <[email protected]>
>> Cc: Daniel Stone <[email protected]>
>> Cc: Chaitanya Kumar Borah <[email protected]>
>> Cc: Uma Shankar <[email protected]>
>> Cc: Louis Chauvet <[email protected]>
>> Cc: Melissa Wen <[email protected]>
>> Cc: Simon Ser <[email protected]>
>>
>> Harry Wentland (10):
>> drm/colorop: Add CSC colorop type
>> drm/colorop: Add CSC colorop initialization helper
>> drm/atomic: Add CSC colorop state handling
>> drm/vkms: Add CSC colorop support
>> drm/vkms: Add atomic check and matrix handling for CSC colorop
>> drm/amd/display: Implement CSC colorop support
>> drm/amd/display: Use GAMCOR for first TF if CSC is used
>> drm/amd/display: Check CSC colorop bypass before programming
>> drm/amd/display: Check actual state during commit_tail
>> drm/amd/display: Set color_space to plane_infos
>>
>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 ++-
>> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 115 +++++++++++++++++-
>> .../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 25 +++-
>> drivers/gpu/drm/drm_atomic.c | 6 +
>> drivers/gpu/drm/drm_atomic_uapi.c | 8 ++
>> drivers/gpu/drm/drm_colorop.c | 91 ++++++++++++++
>> drivers/gpu/drm/vkms/vkms_colorop.c | 64 +++++++---
>> drivers/gpu/drm/vkms/vkms_composer.c | 5 +
>> drivers/gpu/drm/vkms/vkms_plane.c | 50 +++++++-
>> include/drm/drm_colorop.h | 39 ++++++
>> include/uapi/drm/drm_mode.h | 1 +
>> 11 files changed, 388 insertions(+), 30 deletions(-)
>>
>> --
>> 2.53.0
>>
>
