Pipeline vs. no pipeline (Re: [PATCH V8 06/43] drm/colorop: Add 1D Curve subtype)

[Harry Wentland]

On 2025-04-10 03:53, Pekka Paalanen wrote:
> On Tue, 8 Apr 2025 13:30:46 -0400
> Harry Wentland <harry.wentland at amd.com> wrote:
> 
>> On 2025-04-08 12:40, Daniel Stone wrote:
>>> Hi there,
>>>
>>> On Tue, 1 Apr 2025 at 20:53, Simon Ser <contact at emersion.fr> wrote:  
>>>> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone <daniel at fooishbar.org> wrote:  
> 
> ...
> 
>>>>> 1. Is it guaranteed that, if any plane on a device supports the
>>>>> COLOR_PIPELINE property, all planes will support COLOR_PIPELINE?
>>>>> (Given the amdgpu cursor-plane discussion, it looks like no, which is
>>>>> unfortunate but oh well.)  
>>>>
>>>> I don't think so. (They could all expose a COLOR_PIPELINE with the only
>>>> choice as the zero bypass pipeline, but that sounds silly.)  
>>>
>>> Works for me: so any planes could not have colour pipelines, and the
>>> result would be undefined (well, less defined) colour.  
>>
>> Yes, basically it would be what we have now (without color pipelines).
> 
> Hi,
> 
> I see Alex wrote:
> 
>> In order to support YUV we'll need to add COLOR_ENCODING and COLOR_RANGE
>> support to the color pipeline. I have sketched these out already but
>> don't have it all hooked up yet. This should not hinder adoption of this
>> API for gaming use-cases.
> 
> Was it considered to be able to lift the full-range RGB restriction
> from the color pipelines, eventually leading to the possibility of
> scanning out limited-range YCbCr bit-identical, giving userspace access
> to the sub-black and super-white ranges for e.g. BT.814 purposes?
> 

For AMD HW design and validation assumes that the pipeline is
dealing with our internal floating point format and RGB values.
Anything beyond that is somewhat undefined. Things might work
as one expects but the product was definitely not designed and
validated for that usage.

I assume other HW design makes similar assumptions.

> These questions are pointing in the direction of a bypass
> COLOR_PIPELINE being different from no COLOR_PIPELINE. I assume a
> bypass pipeline needs to shovel values through unchanged, while
> "without color pipelines" would need the old COLOR_ENCODING and
> COLOR_RANGE properties.
> 

What I take it to mean is that this iteration of COLOR_PIPELINE
only allows for RGB pipelines as YCbCr ones are underspecified
without COLOR_RANGE and COLOR_ENCODING. For RGB a bypass pipeline
should be the same as no COLOR_PIPELINE.

> That reminds me of yet another question: if the framebuffer is limited
> range, and it's not converted to full-range at the start of a color
> pipeline, how will the sub-black and super-white ranges be represented?
> Will they be negative and greater than 1.0 values, respectively? This
> would be meaningful for the colorops being defined now, as I assume
> people might implicitly limit their thinking to the [0.0, 1.0] range,
> or at least exclude negative values.
> 

Without COLOR_RANGE there is no way to know whether the input is limited
or full.

Is your question about when we have COLOR_RANGE specified? If that is
set to LIMITED then I expect the values to get expanded at the beginning
of the pipeline. In that case it's probably a HW or driver implementation
detail whether the sub-blacks or super-whites will still be represented
(as negative or >1.0 values) or clipped.

> The 3x4 CTM colorop is not yet explicit on whether it clamps its inputs
> or outputs. Should all colorops be explicit about it?
> 

Do we expect all HW/drivers to be able to support the same behavior?
Is this critical to using the colorop?

Harry

> 
> Thanks,
> pq