Re: [PATCH v3] drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

Robert Mader <[email protected]>
Newsgroups org.freedesktop.lists.amd-gfx,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx
Message-ID <[email protected]>
Hi Harry,

On 21.07.26 15:55, Harry Wentland wrote:
>>> ...
>> If I understand you correctly you suggest to map legacy COLOR_RANGE and COLOR_ENCODING to the new FIXED_MATRIX colorop in a generic way, instead of having drivers advertise them separately. Do I have that right?
>>
>> It's probably a good idea. It should be easy to make that change after merging the Fixed Matrix series with YUV support.
>>
> I sketched this out but both VKMS and amdgpu have HW generations
> or configs where no color pipeline is created. For that we still
> need the current way of COLOR_RANGE and COLOR_ENCODING handling.
> Because of this the code to create COLOR_RANGE and COLOR_ENCODING
> based on the color pipeline is not really simplifying things, but
> merely adding more code.
>
> At this point I am not convinced adding helpers to create COLOR_RANGE
> and COLOR_ENCODING based on the color pipeline is a net positive.
> Maybe in the future that equation changes.
>
> If anyone is interested I'm still happy to share the code. Just
> let me know.
>
> Harry

thanks for taking a look! I'd be very interested - mainly because in my 
understanding the "both VKMS and amdgpu have HW generations or configs 
where no color pipeline is created" should be fixable:

 1. For amdgpu every hardware generation supporting COLOR_RANGE and
    COLOR_ENCODING should be able to create a color pipeline *only*
    exposing the corresponding FIXED_MATRIX colorop, mapping to the
    exact same hardware block internally. I hope that shouldn't conflict
    too much with the current architecture?
 2. In case of VKMS the "enable_plane_pipeline" config could be adopted
    so that - if it is disabled - the plane pipeline is still
    initialized but only the FIXED_MATRIX colorop is added. Additionally
    we would need to disable DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE -
    possibly by a driver cap similar to v1 of this series - so that
    userspace can't enable/use the colop-op directly. As a result, VKMS
    with enable_plane_pipeline=0 should get the legacy properties via
    your helper, be able to drop explicit handling of them.

Does that make sense / do you think that could work?

Best regards,

Robert

-- 
Robert Mader
Consultant Software Developer

Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.