On 2024-09-10 16:37, Alex Goins wrote: > Hi Harry, > > Thanks for this. I just want to remind about a few things that would be required > for NVIDIA hardware, as discussed at the Display Next Hackfest -- fully > understand that they aren't currently included in this series because they > aren't required on AMD hardware. Allowing color ops to be non-bypassable is a > big improvement in this direction. > Thanks for your feedback. > In each of these cases, it should be possible to represent NVIDIA's color > pipeline using the existing color ops, but it would rely on rejecting invalid > configurations in atomic check, with no way to communicate the limitations to > clients. > > - Tag IN_FORMATS for a color pipeline (as you have mentioned). > + Required to communicate that the first NVIDIA pre-blending LUT is > incompatible with FP16 inputs. > I have a sketch in a branch [1] but the work was a bit larger than I anticipated so I parked it for now. > - Introduce a single-channel 1DLUT color op, or add the ability to flag > individual channels of an ordinary 1DLUT as read-only. > + Required to handle NVIDIA's 1D tone-mapping LUT designed to operate only > on the intensity component of ICtCp. > I'm reluctant to add a new single-channel colorop type without having the ability to test it. Though I guess VKMS could serve as a stand-in but that would mean an implementation for it in VKMS. > - Allow marking color ops as read-only and non-bypassable (halfway there) > and/or allow marking a color op as requiring a modeset to update. > + Required to handle specific LUTs that can't have their entries changed > while in use without visible glitches/tearing, yet must be enabled to > support tone-mapping and pre-blend scaling. > + In lieu of the first option, it may be suitable to just use the existing > 1D curve colorop 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. > Flags should be easy to add to a colorop because a colorop is just a DRM object, so we can extend it with new properties. I envision this to be a FLAGS bitmask property, so the implementation can probably look similar to the rotation property [2]. And the flags can be REQUIRES_MODESET and SINGLE_CHANNEL, or something like that. [1] https://gitlab.freedesktop.org/hwentland/linux/-/tree/amd-color-pipeline-v6-in-formats [2] https://drmdb.emersion.fr/properties/3435973836/rotation Harry > Thanks, > Alex Goins > NVIDIA
