Re: [Intel-gfx] Module parameters to override color management/dithering.

[Jani Nikula]

On Fri, 15 Sep 2017, Mario Kleiner  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-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Module parameters to override color management/dithering.

[Mario Kleiner]

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?

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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx