[PATCH V9 00/43] Color Pipeline API w/ VKMS

[Harry Wentland]

On 2025-05-17 07:51, Xaver Hugl wrote:
> Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro
> <leandro.ribeiro at collabora.com>:
>>
>>
>>
>> On 5/15/25 15:39, Daniel Stone wrote:
>>> Hi,
>>>
>>> On Thu, 15 May 2025 at 19:02, Harry Wentland <harry.wentland at amd.com> wrote:
>>>> On 2025-05-15 13:19, Daniel Stone wrote:
>>>>> Yeah, the Weston patches are marching on. We've still been doing a
>>>>> little bit of cleanup and prep work in the background to land them,
>>>>> but we also can't land them until the kernel lands. None of that work
>>>>> is material to the uAPI though: as said previously, the uAPI looks
>>>>> completely solid and it's something we can definitely beneficially use
>>>>> in Weston. (Even if we do need the obvious follow-ons for
>>>>> post-blending as well ...)
>>>>
>>>> We can't merge kernel uAPI without canonical userspace that uses it.
>>>> To move forward we'll need a userspace to at least publish a branch
>>>> that shows the use of this new uAPI.
>>>>
>>>> Do you have a public branch for the Weston work for this?
>>>
>>> Yeah, https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1702
>>> has been around for a little while now. There are some driver bugs
>>> that Leandro commented on, but they don't seem material to the uAPI as
>>> such?
>>
>> Hello,
>>
>> Yes, there's nothing related to the API that is blocking us. It seemed
>> very flexible and easy to use. The bugs that I've spotted are probably
>> internal to AMD driver.
>>
>> I'd say that the Weston patches are converging nicely, we just need time
>> to get them fully reviewed. We had a few preparation MR's to land
>> before !1702, and now there's only one left (!1617).
> 
> I also updated the KWin MR
> (https://invent.kde.org/plasma/kwin/-/merge_requests/6600), it can now
> use all the available properties and I think it's ready. I found two
> issues with the kernel patches though:
> - while attempting to set COLOR_ENCODING and COLOR_RANGE results in
> the atomic commit being rejected, the existing values still get
> applied if you use YCbCr-type buffers. I would've expected the color
> pipeline to operate on the YUV values in that case - and leave
> conversion to RGB up to the compositor adding the relevant matrix to
> the pipeline

AMD HW always operates on RGB values, so there'll always be an
implicit conversion of YCbCr-type buffers to RGB. What we should
do is reject YCbCr-type buffers with the color pipeline until we
implement support for COLOR_ENCODING and COLOR_RANGE as a new
CSC colorop.

> - the interpolation mode drm properties for 1D and 3D LUTs are
> immutable, I think they shouldn't be - to make it less annoying if in
> the future we decide to add modes that userspace can set
> 

Makes sense to me.

Harry

> Other than that, I agree that it's ready to go.
> 
>> Thanks,
>> Leandro
>>>
>>> Cheers,
>>> Daniel
>>