Intel confirmed no dithering on Intel arc a770

Ivan_P

This is an Intel-specific fix. I'm making this switch in Windows 11 by slightly modifying the source code of the ditherig application in Visual Studio. I write a specific value to the hardware register of the video chip, thereby switching it to 6-bit mode. This works in Windows 11 only with my Intel UHD 48EUs, but it doesn't work with Intel UHD630, Intel UHD730, and Intel ARC A770. If you need technical details, I can provide them.

P.S. I don't know yet why it doesn't work on the UHD 730 (i5-12400), since the i5-12400 also has the Xe video chip architecture, similar to the Intel UHD 48EUs. It might be an issue with the installed version of the driver or something else.

simplex

Link to the guide: https://cdrdv2-public.intel.com/703047/intel-gfx-prm-osrc-tgl-vol-02-c-command-reference-registers-part-2.pdf

On page 692 of the guide, it is stated that bits 5-7 of the register are the Dithering BPC bits, and the 4th bit is the Dithering Enable bit. This means that bits 5-7 set the color depth for dithering. According to my experiments, no matter what values I set for bits 5-7, there is no effect on the i5-12400 (UHD 730) as long as the 4th bit is zero, meaning dithering is off. However, if the 4th bit is set to one, enabling dithering, then bits 5-7 can be used to adjust dithering depth. But this is not what we need, as we actually want to get rid of dithering.

However, when attempting to change bits 5-7 for the Intel UHD 48EUs (i5-12450H), the color depth of the output signal changes, while the Dithering Enable bit (the 4th bit) remains set to zero. This behavior is different from the desktop i5-12400 iGPU.

However, I was led to these experiments after reading a comment in the Linux kernel in the i915 module. It stated:

For Display < 13, Bits 5-7 of PIPE MISC represent DITHER BPC with valid values of: 6, 8, 10 BPC.

ADLP+, the bits 5-7 represent PORT OUTPUT BPC with valid values of: 6, 8, 10, 12 BPC.

I know that there is a way to switch to true 6-bit on the Alder Lake i5-12400, as the i915 module in Linux does this. However, in Linux, this is done through the convenient xrandr tool, and I'm not ready to say which other registers are involved in this process.

WhisperingWind ADLP+, the bits 5-7 represent PORT OUTPUT BPC

Perhabs, this mean Alder Lake and later (12gen+), use another registers for dithering, when 5-7 used for port output bit depth:

Till DISPLAY12 the PIPE_MISC bits 5-7 are used to set the
Dithering BPC, with valid values of 6, 8, 10 BPC.
For ADLP+ these bits are used to set the PORT OUTPUT BPC, with valid
values of: 6, 8, 10, 12 BPC, and need to be programmed whether
dithering is enabled or not.

simplex 8 bit = 1 (truncate data)

In this case, the code will be like this

New &= 0xFFFFFE0F;
// Comment out the line below to switch to 8-bit output mode.
// Uncomment to switch to 6-bit output mode.
New |= (1 << 6);
// set Pixel Rounding to Truncate
New |= (1 << 8);

,,,,,,,,,,

whystrainwhy

Make sure your monitor is safe. Try installing Linux and check for dithering as moonpie suggests. Evaluate how comfortable it is for you to work with your monitor in this case.

We already know how to determine the presence of spatial dithering by reading the state of the Intel iGPU/GPU controller register. But I became curious whether it is possible to visually see the presence of spatial dithering on Intel graphics cards. And at the same time, check if it is possible to enable temporal dithering. There will be nothing new in this post, only a visual confirmation of the facts we have known for a long time.

The test was conducted on Windows 10 22H2 using an Intel ASRock ARC A770. To enable or disable dithering, the application ditherig was used.

Screenshots were taken using a Blackmagic UltraStudio Recorder 3G. Since it doesn't always work correctly with the HDMI port on the ARC GPU, I connected it via DP.

Link to the archive with screenshots and resulting comparison files.

The comparison was performed using this python script.

The archive contains pairs of screenshots with dithering (spatial dithering) enabled and completely disabled, as well as the result of their pixel-by-pixel comparison. There is one unpaired screenshot, without_ditherig_app.tga, which was taken after unloading the ditherig application and restarting the PC to ensure that the GPU register states were reset to their default values.

In the resulting comparison images, the first image of the two being compared is used as a blurred background. Red dots indicate pixels that differ. As you can see, spatial dithering most often manifests as something resembling a "checkerboard" pattern.

Note that spatial dithering is predictably absent on white (255, 255, 255). However, on (254, 254, 254), it is present and appears as an alternation of pixels (255, 255, 255) and (254, 254, 254). This can be seen in spatial_dithering.tga (the photo with the girls). You need to check the "white" using any colorimeter application.

As I mentioned above, I also took a screenshot when the ditherig application was not being used. It matched pixel-for-pixel with the screenshot taken after enabling the dithering disable option in the ditherig application. It shows that, by default, dithering is completely absent.

What surprised me: the option to enable temporal dithering also works. This means temporal dithering can be enabled on some Intel iGPUs/GPUs. I suppose this will definitely include all iGPU/GPU based on the Xe architecture (ARC A, Intel iGPUs from the 11th to 14th CPU generations). I can't say about others. If needed, I can compress and upload video files (the original files are very large), which demonstrate the presence of temporal dithering when the corresponding option is enabled.

In the future, I plan to compare the ASRock ARC A770 with Intel UHD 48EUs (Tecno MEGA Mini M1 mini-PC), as I find the Intel UHD 48EUs slightly more comfortable for my eyes. I'm curious to understand why. My current hypothesis is that it could be due to differences in sharpness/softness of the image or differences in default gamma/contrast values.