• Other
  • Registers to control Intel graphics dithering on Linux located

5 months later

I'm trying Ubuntu 22.04 (vanilla/GNOME) again 🙂. @Sunspark Is there a way to tell if xf86-video-intel is loaded or not? I'm not sure I did it right.

$ sudo inxi -G
Graphics:
  Device-1: Intel UHD Graphics 620 driver: i915 v: kernel
  Device-2: Cheng Uei Precision Industry (Foxlink) Webcam type: USB
    driver: uvcvideo
  Display: server: X.Org v: 1.21.1.4 driver: X: loaded: intel gpu: i915
    resolution: 1920x1080~60Hz
  OpenGL: renderer: Mesa Intel UHD Graphics 620 (KBL GT2)
    v: 4.6 Mesa 23.0.4-0ubuntu1~22.04.1

Trying the intel_gpu commands sadly have no impact:

$ sudo intel_reg write 0x7f008 0xc0000040 --verbose
Before:
                     TRANS_CONF_EDP (0x0007f008): 0xc0000000 (enabled, active, pf-pd)
After:
                     TRANS_CONF_EDP (0x0007f008): 0xc0000000 (enabled, active, pf-pd)

And the conf file:

$ cat /etc/X11/xorg.conf.d/20-intel.conf 
Section "Device"
Identifier      "Intel Graphics"
Driver          "intel"
Option          "DRI"           "3"
Option          "AccelMethod"   "UXA"   # SNA is normal default
#Option         "TearFree"      "true"
EndSection

Another idea I had was trying to disable Intel power-saving, doing a fake EDID and other settings here like Dac6bit, or on xrandr

I can't quickly check because stupid Valve left out inxi on theirs (along with other stuff). But, I think it is correct because it says "Loaded: intel" so now you need to rename the file to .bak or something, and compare the modesetting driver next..

I'm going to suggest to you not to use Gnome. Use KDE instead, so that means Kubuntu http://cdimage.ubuntu.com/kubuntu/releases/22.04/release/. KDE does have better fractional scaling than Gnome, which makes a difference if you're not using 100% or 200% scaling. If you are, then it doesn't matter. I prefer KDE. Lots of flippy switches and customizability.

Forget about the gpu registers.. too much time has passed. What I will suggest instead for external monitors is a custom modeline.. you can dial in the refresh rate you want pretty precisely w/ different blanking intervals, etc. On my monitor the default EDID sets it to 59.876 (not even 59.94!), but I did spend awhile on the deck comparing various modelines to get it to 60.000 and seeing which one I thought seemed ok and found one that seems ok to use.. xrandr is what you use to set and switch refresh rates in x.org. To calculate the numbers they can come from various sources, the one I ended up on was "Exact" from CRU. To convert the numbers from CRU, it is easy.. you just add them one after the other.. so if it says 1920 48 32 80 as an example, then 1920 1968 2000 2080 for the Linux modeline version.

I don't use Linux as my desktop, I just play with it on the deck to see if I can customize it to the point of liking it. Windows 10 is still my main desktop.

    7 days later

    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 replied to this.

      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 replied to this.

        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.

        5 months later

        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.

        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?

        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

          KM

          btw this is what kawamoto released in his Ditherig app

          • KM likes this.

          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".

            KM

            have you modify and rebuild kawamoto's sources?

            • KM replied to this.

              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.

                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.

                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?

                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()).

                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.

                  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 replied to this.
                    dev