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: 2407 bytes --]

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?

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.

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.

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


Thanks,
pq

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