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