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

[Pekka Paalanen <pekka.paalanen@haloniitty.fi>]

[-- Attachment #1: Type: text/plain, Size: 4951 bytes --]

On Tue, 15 Apr 2025 11:29:10 -0400
Harry Wentland <harry.wentland@amd.com> wrote:

> On 2025-04-10 03:53, Pekka Paalanen wrote:
> > On Tue, 8 Apr 2025 13:30:46 -0400
> > Harry Wentland <harry.wentland@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@emersion.fr> wrote:    
> >>>> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone <daniel@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.

Hi Harry,

if that's just about minor rounding effects in conversion between
integer and internal formats, I wouldn't be too worried.

But if the internal format has severe limitations, like cannot
represent negative values, or smaller than -0.999 or bigger than 1.999
for example, then that is something userspace needs to know.

> > 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.

I'm thinking of the future extension of the color pipeline framework.
I'm concerned that not considering limited range YCbCr might make
adding support for it later much harder than it needs to be.

Xaver's point about scRGB is a really good one: we don't need YCbCr in
order to encounter nominal values outside of [0.0, 1.0]. We don't even
need scRGB, any conversion from a bigger to a small color space can
produce them and we should understand what to expect when that happens.

> > 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?

It is critical. It does not have to be the same for all hardware and
drivers, if there is a colorop property or type indicating it. But it
cannot be a hidden driver/hw implementation detail.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]