Module parameters to override color management/dithering.

[Jani Nikula]

On Fri, 15 Sep 2017, Mario Kleiner <mario.kleiner.de at gmail.com> wrote:
> Hi,
>
> so these two patches add i915 module parameters to globally override
> how the driver handles dithering and gamma/csc conversion.
>
> They serve two purposes: First as debug aid and "airbag" for working
> around potential precision problems in getting pixels from rendering
> to the display outputs. This mostly for applications that critically
> depend on getting pixels untampered from the fb to the outputs, e.g.,
> scientific neuro-science/vision research/medical applications. Having
> the ability to bypass parts of the pipeline can help a lot in debugging
> such problems on remote user machines, and to allow such users to
> work around the problems until proper fixes are made. I expect this
> to become especially useful when dealing with all the Wayland compositor
> implementations, which so far don't have a standardized application/user
> controllable equivalent to RandR protocol / xrandr tools.
>
> The second, short-term purpose is to enable true 10 bit output from
> rendering, so people with urgent 10 bit precision needs can benefit
> from the Mesa patches i started working on for i965 (rev 1 on the
> mailing-list, rev 2 to come soon).
>
> I realize the merge window for Linux 4.14 is almost over, but wanted
> to ask if it would be possible to slip these patches into 4.14 if
> they aren't considered too intrusive?

For future reference, drm features for an upcoming merge window need to
be merged upstream by about -rc5, i.e. several weeks before the merge
window even opens.

As to the patches, we're wondering about ways to axe existing module
parameters, so we'd prefer not adding new ones. You mention connector
properties; common properties across drivers sounds like the way to go.

BR,
Jani.



>
> These are tested on Ironlake, Ivybridge, Haswell and Skylake, also
> with a photometer to see what actually comes out of the display for
> different settings.
>
> The bigger plan is to enhance the gamma table support, so we could
> also use > 8 bit precision gamma tables on Ironlake and later, both
> for the legacy gamma ioctl and the new color mgmt. method. I do have
> proof of concept patches for using the 1024->10 precision luts on
> Ironlake and later. Tweaking the gamma tables i upload via RandR and
> measuring with photometer showed my poc patches work. However, as
> described in the 2nd patch, at least the tested legacy luts and
> 1024->10 precision luts seem to get mostly ignored/bypassed in the hw
> when a XR30 fb is attached to the primary plane. Not sure if some setup
> is missing, or if this is some hardware quirk? Couldn't find anything
> in the PRM's so far.
>
> What i'd actually like to implement for Ironlake+ instead of the
> 1024->10 bit luts is this:
>
> If in dual-gamma lut mode, or if the input gamma table is not
> monotonically increasing, do what is done now (legacy luts for legacy
> gamma ioctl, split 512->10 big luts for new path).
>
> If only a single gamma lut is requested (DEGAMMA_LUT == 0), and the
> provided input lut is monotonically increasing, switch to the linearly
> interpolated 512->12 bit lut instead, which exists on Ironlake+. Also
> for the legacy gamma ioctl, so existing apps can benefit from the
> higher precision. This would enable > 8 bit framebuffers to be output
> properly and with high quality gamma correction.
>
> Thanks,
> -mario
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center