Talk:Intel graphics

From ArchWiki

[drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update failure on pipe A

Maybe the solution to get rid of the above dmesg log spamming could be mentioned? You just add `options i915 enable_psr=0` to the file `/etc/modprobe.d/i915.conf`. Bjourne (talk) 17:04, 19 August 2016 (UTC)

Backlight is not adjustable after trying various acpi_osi values

Full details on Stack Exchange.

—This unsigned comment is by L0b0 (talk) 20:04, 8 October 2016‎. Please sign your posts with ~~~~!

DRI3 confusion

I've seen in the forum people ask from time to time how to enable DRI3 on their system.

As stated many times there, DRI3 should be on for most (if not all) of them. But people keep telling them to check

cat /var/log/Xorg.0.log | grep DRI

which shows up this message:

GLX: Initialized DRI2 GL provider for screen 0

which is *not accurate*.

If you run this command instead:

LC_ALL=C LIBGL_DEBUG=verbose glxinfo | grep DRI

you might stump with this other message:

libGL: Using DRI3 for screen 0

which proves you are using DRI3 even though X11 doesn't reply with the correct information.

The command was adapted from xorg mailing list.

So, it think adding this information in the page could be of major interest. What do you think?

Franzrogar (talk) 07:01, 4 November 2016 (UTC)

Guide for screen scaling with external displays via xrandr?

I tried to find instructions for scaling the display resolution without stretching on this wiki page, but the section only says that it's not implemented in the Intel drivers yet. However, this stackexchange thread has a workaround using an xrandr transform matrix. Should this be added to the wiki page?

Ibara (talk) 12:35, 22 May 2017 (UTC)

Screen flickering

Intel's power saving features might lead to flickering on some devices visible in the desktop, login manager and even in the konsole. Add the kernel parameter intel_idle.max_cstate=1 and reboot.

—This unsigned comment is by R41n3r (talk) 20:57, 3 November 2020‎. Please sign your posts with ~~~~!

Driver issues on 11th Gen CPU

I've just left a comment in Talk:Dell_XPS_13_(9310)#Video drivers about issues with modesetting drivers on the new XPS 13. The issue appears when using modesetting drivers and is resolved when installing the xf86-video-intel package, which seems to go against most of the advice in this Wiki and the internet at large. The issue is not simple to describe, so I will just copy-paste what I've written on the other page: "some weird jittery behaviour in the rendering of text. For example, when attempting to type '' in a browser address field the text rendering would suddenly jump back by 1/2 strokes (I'm typing 'ch', the 'c' appears shortly but the screen immediately refreshes to only show 'wiki.a') and refuse to update for maybe a second. It would then catch up if I kept typing." Is this a known issue with 11th Gen Intel CPUs? The model I have has an i7-1165G7, which includes the new Intel Iris Xe Graphics. Avernan (talk) 17:16, 30 December 2020 (UTC)

Washed colors on 7th gen CPU

I found out that my iGPU shows washed colors randomly, but I managed to fix it by adding intel_agp and i915 modules into mkinitcpio.conf and rebuilding the initramfs after that.

Paulo Marcos 11:37, 24 June 2021 (UTC)

Potential performance gains via Observation Architecture

This /r/linux thread claims the following:

Dynamic Tuning is not enabled in most distros due to late Intel KMS. Running "sudo sysctl dev.i915.pref_stream_paranoid=0" drastically improves game performance and clock management on relevant processors, specifically Tiger Lake.

dev.i915.perf_stream_paranoid was introduced in this Kernel commit, and its usage was introduced to Mesa in this commmit. It now lives in linux/drivers/gpu/drm/i915/i915_perf.c. This setting controls whether "non-root users [are allowed] to access system wide OA counter metrics". OA refers to Intel's Observation Architecture, and is used to provide performance info to applications.
As I understand, the perf_stream_paranoid family of options all may make a difference in whether applications are able to receive certain performance metrics. This is read-only information, and yet some users are reporting dramatic performance increases. What's more is that it's unclear whether early KMS fixes the issue; this Manjaro forum post says it does, but the Reddit OP says otherwise. Cheers, CodingKoopa (talk) 2022-04-21T02:38:34

I don't have the exact hardware to benchmark this, but on my (relatively old now) Skylake processor, I did not feel any difference. Neither from the perf_stream sysctl knob nor from early KMS. --Erus Iluvatar (talk) 06:55, 21 April 2022 (UTC)
Phoronix says that it's Haswell and newer, so your Skylake should just be fine. It's possible that the sysctl option makes no difference (that is, because of the permission to use the performance counter being present anyways), either because of your setup using Early KMS, or because of some Arch default. I think that a good test would be to disable Early KMS (e.g. take the i915 module out of the initrd), and run a program that triggers the Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0 codepath. I'm under the impression that affected applications are Vulkan programs which use the VK_KHR_performance_query extension [1]. That said, I'm not sure how to reliably pick out affected programs, seeing as people are reporting this with Wine games, but DXVK does not use this extension. Cheers, CodingKoopa (talk) 17:05, 21 April 2022 (UTC)
I'll try to find some time to benchmark this on the weekend, I probably have some random game on Steam that both uses Vulkan and runs through Wine. --Erus Iluvatar (talk) 18:35, 21 April 2022 (UTC)