with only a single curve supported, marked as
non-bypassable. Allowing modesets as in the second option would allow for
the possibility of selecting different curves, however.
Thanks,
Alex Goins
NVIDIA
On Mon, 9 Sep 2024, Harry Wentland wrote:
> External email: Use caution opening lin
On Thu, 26 Oct 2023, Sebastian Wick wrote:
> On Thu, Oct 26, 2023 at 11:57:47AM +0300, Pekka Paalanen wrote:
> > On Wed, 25 Oct 2023 15:16:08 -0500 (CDT)
> > Alex Goins wrote:
> >
> > > Thank you Harry and all other contributors for your work on this.
. Again do not want to do this with
> > > PQ-encoded values.
> > >
> >
> > Wouldn't this only happen during a scaling op?
>
> There is certainly some overlap between examples 2 and 3. IIRC SRC_X/Y
> coordinates can be fractional, which makes nearest vs. bilinear
> sampling have a difference even if there is no scaling.
>
> There is also the question of chroma siting with sub-sampled YUV. I
> don't know how that actually works, or how it theoretically should work.
We have some operations in our pipeline that are intended to be static, i.e. a
static matrix that converts from RGB to LMS, and later another that converts
from LMS to ICtCp. There are even LUTs that are intended to be static,
converting from linear to PQ and vice versa. All of this is because the
pre-blending scaler and tone mapping operator are intended to operate in ICtCp
PQ space. Although the stated LUTs and matrices are intended to be static, they
are actually programmable. In offline discussions, it was indicated that it
would be helpful to actually expose the programmability, as opposed to exposing
them as non-bypassable blocks, as some compositors may have novel uses for them.
Despite being programmable, the LUTs are updated in a manner that is less
efficient as compared to e.g. the non-static "degamma" LUT. Would it be helpful
if there was some way to tag operations according to their performance,
for example so that clients can prefer a high performance one when they
intend to do an animated transition? I recall from the XDC HDR workshop
that this is also an issue with AMD's 3DLUT, where updates can be too
slow to animate.
Thanks,
Alex Goins
NVIDIA Linux Driver Team
> Thanks,
> pq
>
