• OS

  • who can use Linux but not windows? Share your Linux setup

KM

I previously tried debugging the module's code, and the main decision regarding dithering was applied at this location: https://github.com/torvalds/linux/blob/c2ee9f594da826bea183ed14f2cc029c719bf4da/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c#L237.

I also made some changes in a few other places, including the files you mentioned above. However, it seems I might have overlooked something. I initially got the RX6600 mainly for experimenting with Hackintosh, but those attempts were unsuccessful due to dithering issues. At that time, I didn't focus much on Linux, unlike now with Intel cards. Unfortunately, I've sold the RX6600, so I can't give it another try at the moment.

P.S. I think I'll build a new PC next year based on an AMD CPU. If it has an iGPU, I'll give it another try.

  • KM likes this.

    I can make changes in the amdgpu module. However, it won't be a 'clean' code, and I won't be able to test the results.

    aticonfig is old and isn't used anymore. The driver in use for pretty much everyone is amdgpu. Sometimes you can set an option in GRUB but generally it's still a work-in-progress, doesn't even easily have the ability to change the colour space away from RGB and colour depth changes seem mostly to be between 30 and 24 bits. So dithering is probably present.

    It'll probably get there someday, but not soon unless you're using Windows.

    Don't spend a lot of time on this, it's not ready for what you want.

      bluetail I think the bit depth as set in the driver still has relevance

        moonpie I want more context.

        I think dithering is enabled per display based on EDID traits https://en.wikipedia.org/wiki/Extended_Display_Identification_Data. It would be great if we could query the status.
        Might be wrong, but that would imply there are couple of assumptions made…

        I have BenQ XL2546K, XL2566K, and an old LG 24GM79G. On my now sold M1 Mac with the LG, I noticed a fine screen pattern. On my PC with a 6950XT, it's similar but only up close. I suspect it's dithering. The BenQ displays don't show this on the 6950XT but have poor colors on the M1 Mac. I think the LG might be 6-bit with 2-bit FRC. Specs show BenQ has this too, but it's less noticeable. I also see banding on the BenQ, likely due to a limited color gamut.

          WhisperingWind Thank you for that guide. Reading it I was able to compile a Linux Kernel on my Debian notebook that has Intel's dithering successfully disabled. The dithering was just spatial (not temporal) and didn't seem to cause obvious issues, at least not on static images, but who knows if it contributed to eye strain over time when watching scrolling/moving content. Time will tell.

          I wonder if there is a faster way to have the source code changes apply other than to compile a new Kernel though. My poor notebook compiled for hours with loud fan noise. Does anyone know if we could shorten the process? If we want to modifiy the distro's own Kernel, I think we would have to repeat the change every time a new Kernel shows up in the distro's package manager. Which could become annoying fast if compiling takes that long each time.

              KM

              In this case, a package with a pre-compiled kernel can be put together and shared for easy installation, so users won't have to go through the hassle of compiling it themselves. However, different Linux distributions may have different package managers, library sets, and system components, which could affect the compatibility of the package. This task might require quite a bit of time and effort, as I would need to build, test, and maintain multiple packages for various distributions and possibly different kernel versions.

              Currently, there don't seem to be other options besides manually building the kernel, since changes are needed in the source code of the i915 module. Distributing this module separately isn't feasible either, as it's closely linked to a specific kernel version.

                moonpie

                Compression (FBC) is present, but as I understand it, it should be lossless (?) and not strain the eyes.

                My hardware doesn't support DRRS, so I couldn't read the DRRS status report.

                  moonpie I don't think this is 100% the case, since I have 8th gen laptop (ThinkPad T480) where "Display Refresh Rate Switching" is an option in the 2017 drivers control panel. It pretty much has the same effect when enabled -- dynamically switching between 48/60hz with no obvious transition.

                  Also, multiple eDP panels I've connected to the laptop (including ones as old as 2014) have both 48 and 60hz modes reported in the EDID. So features that are pretty similar to this seem to have been around for a while

                    @WhisperingWind is there a chance to disable dithering in nvidia cards too? Besides the nvidia-x-server which can control dithering, I feel there is another layer of dithering that can't disabled.

                      3 months later

                      WhisperingWind You can set 8 bits with the command:

                      xrandr --output HDMI-1 --set "max bpc" 8

                      moonpie sudo cat /sys/kernel/debug/dri/1/i915_display_info

                      Run that command to find out if dithering is even on.

                      I thought I would migrate the latter discussion over here (out of the ditherig.exe topic). This is the MacBook Pro model with the "Intel Iris Pro 5200 Graphics " only. By default on Xubuntu, I get:

                      xubuntu@xubuntu:~$ sudo cat /sys/kernel/debug/dri/1/i915_display_info | grep -i dither
	pipe src=2880x1800+0+0, dither=no, bpp=24
	pipe src=0x0+0+0, dither=no, bpp=0
	pipe src=0x0+0+0, dither=no, bpp=0

                      After xrandr --output eDP-1 --set "max bpc" 6, now I get:

                      xubuntu@xubuntu:~$ sudo cat /sys/kernel/debug/dri/1/i915_display_info | grep -i dither
	pipe src=2880x1800+0+0, dither=yes, bpp=18
	pipe src=0x0+0+0, dither=no, bpp=0
	pipe src=0x0+0+0, dither=no, bpp=0

                      So maybe I wasn't crazy when I thought it felt worse after switching to 6-bit color. It seems bizarre to me that reducing the color depth would cause the driver to enable dithering. I must be missing some piece here.

                      Here are the full (original, 8bpc) details.

                            dev