Registers to control Intel graphics dithering on Linux located

ryans

I believe the registers are here and the bit calculation is here ... it seems like our calculation should be correct.

ryans

I've tried playing around with some grub configs (based on this Intel post), but I can't get rid of this gray square flickering (slow motion)

For reference:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_dithering=0 i915.enable_psr=0 i915.dpst=0 i915.enable_dc=0 i915.enable_rc6=0 i915.enable_fbc=0 i915.panel_use_ssc=0 i915.alpha_support=0 i915.enable_ips=0 i915.enable_dpcd_backlight=0 intel_idle.max_cstate=2"

I'd like to disable all these somehow too.

KM

ryans Where do we get the full list of all those i915 kernel parameters? It seems awfully hard to find. As if the list is not available for the general public but instead hidden in some source code.

ryans

caboy I have tried setting it to 0xc0000040 with no effect. The number value can change, but the string still says (enabled, active, pf-fd).

I have also for fun tried oxc0000000. No luck.

I wonder if secure boot could be "protecting" these registers somehow.

JTL

ryans Nah. I would guess it might be driver related? Because if it was something more internal there's a good chance ditherig wouldn't work either.

KM

I think I found it: https://github.com/torvalds/linux/blob/v6.1/drivers/gpu/drm/i915/i915_params.h
You need to select the tag in the upper left corner according to your Linux kernel version (the link is for Linux 6.1.).

Some parameters that you currently use are missing. They probably never existed or don't exist anymore.

Donux

Sunspark Is it really safe to use these on all models? Ditherig.exe on windows as far as I recall first detected the GPU family then applied codes accordingly?

KM

I found freely available official Intel reference manuals that describe the hardware specs of Intel processors in detail, including graphics registers. The documents about the registers are named "Volume 2x: Command Reference-Registers". They contain register addresses and descriptions for "Dithering BPC", "Dithering enable", "Dithering type" (spacial, temporal etc.), which may be what we are looking for. I'm looking at this right now for the first time, so there's a chance I'm mistaken. If not, I think we should all download the manual that's specific to our CPU and try changing the registers.

https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/hardware-specs.html

simplex

btw this is what kawamoto released in his Ditherig app

KM

Using the address for the 2015-2016 Skylake processors, which is slightly different (70030 instead of 70008), I tried to turn off dithering using intel_reg on a Thinkpad T460. However, as others have already observed, the value doesn't change. It is 0x50 by default, which would translate to "6bpc, enabled, spatial".

simplex

have you modify and rebuild kawamoto's sources?

KM

simplex No, but now that you mentioned it, I looked it up and I saw that the registers it uses (https://github.com/skawamoto0/ditherig/blob/master/ditherig/database.csv) seem to match the ones from the Intel documents, though the addresses he labelled as "Intel Gen 6" as far as I can tell are not for Gen 6 (2015-2016 Skylake).

Knowing that ditherig uses the same addresses, I think the only task that's left is to find out why intel_reg does not change the register values.

jordan

KM maybe that's why some people say it doesn't seem to work. Maybe that tool has some screw ups?

I did message Mario who worked on the Linux Intel driver and he told me that Dithering is only enabled on 6bpc/18bpc. I guess he was the one who implemented it in the Linux drivers. He said that if it's dithering it's spatial and not temporal dithering/frc/fm.

simplex

KM I looked it up

Yep, he used GC database with addresses, so you can add new equipment according to Intel/AMD whitepapers

What interesting is 1st and 3rd image below, such things also could affect dithering on the screen. Especially "1st order dithering", maybe its time to add such options to Kawa app?

KM

The value the tool read on my machine (0x50) seems to confirm the dithering is spatial. It may not contribute to eye strain.
What is interesting is that when I use the option --verbose while writing a value, the tool displays different values for "before" and "after", as if the value had been successfully written:

$ sudo intel_reg write --verbose 70030 0x00000040
Before:
                                    (0x00070030): 0x00000050
After:
                                    (0x00070030): 0x00000040
$ sudo intel_reg read 70030
                                    (0x00070030): 0x00000050

Does the driver intervene and restore the default value immediately?

This seems to be the current source code for the tool: https://gitlab.freedesktop.org/drm/igt-gpu-tools
The code resides in tools/intel_reg.c. It seems the tool really reads and outputs the current value after a write (function write_register()).

KM

I was able to confirm that something resets the register after a successful write. You can test it with this command:

while true; do sudo intel_reg write 70030 0x40; done

Open the gradient at http://www.lagom.nl/lcd-test/gradient.php and run the command (stop the command with Ctrl-c) to witness banding (and some flicker, beware), indicating the tool works but something else keeps resetting the dithering.

Make sure to adjust the register number with the one found in the Intel documents specific to your CPU.

jordan

KM just curious are you seeing a change with banding even on a 8bit display? Would it be easy to figure out what is changing it back? Would like to try this on my Intel arc a770 if there's a way to keep it set to disabled

KM

jordan It turned out the thing that keeps resetting the register is the compositor or some piece of code the compositor depends on. I use Xfce. After disabling its compositor (Settings - Window Manager Tweaks), the register doesn't change anymore. Perhaps this works for other desktop environments, too. I think we need a Linux graphics expert to find out what exactly is causing the resets when compositing is enabled. I also found out that closing the laptop lid causes a register reset, too. There may be more events that do this.

Currently I don't know the color depth of this laptop's display, so I can't say for sure if you would see a change on an 8 bit display.

jordan

KM Gotcha. Would compositing basically disable all os strain? I am wanting to try Linux but I'm just unsure which distro to start with and if I have to manually load a different WM, DE, etc.

I'm assuming your screen might be 6bit since one of the Intel Linux driver devs told me it's spatial dithering on 6bit. Just was wondering if it defaults disabled with 8.

KM

jordan I don't think so, as I have experienced on different setups that using a compositor can introduce additional eye strain.

KM I have found a way to detect the creation of new X11 windows. This script uses intel_reg to disable dithering each time a new window gets created:

#!/bin/bash

xev -root | grep --line-buffered "CreateNotify" |
  while read line; do
    intel_reg write 70030 0x40
  done

whystrainwhy

KM Does this help reduce strain? Which Linux distro you running?

DisplaysShouldNotBeTVs

KM BTW, on older Intel hardware (e.g. HD Graphics 4000) the command is slightly different:

sudo intel_reg write 70008 0xC0000040

The register is 70008 instead of 70030 (70030 was used starting with 8th gen)
The C at the beginning is needed to ensure the pipe stays enabled, as per the Intel documentation (otherwise you would get a black screen)

Also, two other discoveries:

On HD 4000 + MATE desktop environment, in order to also get Firefox to stop doing its own spatial dithering (after you already disabled Intel's) you need to disable the MATE compositor and then restart Firefox.
Even if you disable Intel dithering, all "native" apps in MATE and the wallpaper will continue to use their own spatial dithering. I'm pretty sure that the GTK UI framework itself is responsible for this. However, all Firefox with the above fix and Chrome/Electron-powered windows will stop dithering entirely! -- except for gradients in Chrome This might mean that a desktop environment that doesn't use GTK (e.g. KDE which uses Qt) may be better to avoid dithering

« Previous Page Next Page »