On Tue, 8 Apr 2025 13:30:46 -0400 Harry Wentland <harry.wentl...@amd.com> wrote:
> On 2025-04-08 12:40, Daniel Stone wrote: > > Hi there, > > > > On Tue, 1 Apr 2025 at 20:53, Simon Ser <cont...@emersion.fr> wrote: > >> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone <dan...@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
pgp33skZnU3Td.pgp
Description: OpenPGP digital signature
