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)Reply[reply]

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 ~~~~!

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)Reply[reply]

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)Reply[reply]

I have an 11th Gen CPU (i7-1165G7), and the integrated GPU is Intel TigerLake-LP GT2 [Iris Xe Graphics] according to neofetch. I was experiencing mouse flickering and lots of screen tearing with the modesetting driver, and this was only able to be resolved by installing x86-video-intel. The wiki page should be updated to mention this, but I'm not sure the best way to go about it. Makeworld (talk) 02:35, 15 July 2022 (UTC)Reply[reply]
That's pretty bad. Perhaps there could be a bulleted list within the Note, of issues with the modesetting driver. For those new items, we would prefer to have some sort of bug report to link to (rather than "original reports" without external recognition). -- CodingKoopa (talk) 04:16, 15 July 2022 (UTC)Reply[reply]
Additionally I noticed a large reduction in CPU frequency when video conferencing (Google Meet in Chromium), which means better powersaving and no fans spinning up. And yeah, my concern was that I have nowhere to link to to back up my claim of issues. Not sure where to file a bug report, but I'm also not sure how appropriate it would even be. Obviously this is buggy behaviour from modesetting, but it feels a bit unfair to complain about modesetting when there are Intel drivers right there that work and solve the problem. Makeworld (talk) 16:16, 15 July 2022 (UTC)Reply[reply]
I think it's totally fair, actually. modesetting represents a modern take on Xorg drivers: When it comes to hardware acceleration, rather than implementing the Xorg primitives for each GPU, modesetting uses the GLAMOR backend, which implements the Xorg primitives as OpenGL calls, and then defers to the vendor-specific GPU driver (generally just Mesa). This is considered a better architecture, and is the reason why it's encouraged. Rather than considering it a "fallback" (as the page currently implies), see it as an alternative which leverages your better-maintained 3D stack.
In other words, modesetting is intended to be well-supported, and the people behind it actually would care to hear about problems that occur with it. With all of that said, I'm not really sure how the bug report process for it goes. It might be on the FreeDesktop GitLab instance that issues are opened. -- CodingKoopa (talk) 21:29, 15 July 2022 (UTC)Reply[reply]
Ah, I didn't realize that's how modesetting worked, thanks. I've filed this issue on the xserver repo as that seems to be the appropriate place. I'm not sure exactly how the wiki Note should be edited to take all these different reports and views into account, are you able to do it now that there's a bug report? If not maybe I can come back to this in a day or two. Thanks. Makeworld (talk) 00:16, 17 July 2022 (UTC)Reply[reply]
Yeah, I think that's enough. Let's keep this section open though, and see how the issue progresses.
For the source link in that issue, you should change it to so that it will continue to work once this section has been closed and deleted. Thanks, CodingKoopa (talk) 02:31, 17 July 2022 (UTC)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

TGL/RKL GuC Submission

Hi, I think the table should be called into question for GuC submission being only supported from ADL forward. I have an i5 11400 and it will enable the GuC submission with SLPC and RC.

After trying to set 3, it actually worked. Full GuC submission and HuC auth.

—This unsigned comment is by Gmazzo (talk) 09:48, 24 July 2022. Please sign your posts with ~~~~!

Hi, I made that table. Firstly, are you sure that your CPU is an i5-11400 and not an i5-11400H? Your logs indicate that the Tiger Lake firmware is being loaded, whose microarchitecture the i5-11400H corresponds with (specifically Tiger Lake-H). This is as opposed as opposed to the Rocket Lake firmwares, which I would expect the i5-11400 to load. Both are 11th generation CPUs which use Gen12 GPUs, so it shouldn't matter anyways, but I want to make sure I understand, as there are RKL firmware binaries in linux-firmware.
Tiger Lake and Rocket Lake are both in the area where they ship Gen12 GPUs, but they are not supposed to support GUC submission and power management according to Intel's own chart. This is still supported by the source code handling the defaults, too. Yet, what you are experiencing seems to be GuC submission without HuC firmware loading (equivalent to i915.enable_guc=1) by default, which I didn't think is ever the case. Fortunately, at least TGL/RKL supporting HuC authentication is not a revelation, as that is supported by the Intel docs.
So, yeah, it does sound like the table is wrong about your CPU's default behavior. From what I understand about what the kernel is doing:
  • GuC and HuC are uninitialized. [2]
  • The defaults laid out in the table are set, if enable_guc is unset.
  • Regardless of the settings, intel_uc_init_early in intel_uc.c calls intel_guc_init_early() and intel_huc_init_early(), each of which does minimal initialization to determine if the hardware is supported.
  • Throughout intel_uc.c, intel_uc_supports_guc() is called to see if GuC is supported.
    • The definition for intel_uc_supports_guc() is generated by a macro in intel_uc.h (annoying when I can't just grep for it :p). This defers to intel_guc_is_supported().
    • intel_uc_fw_is_supported() in intel_guc_fw.h checks the result of the minimal initialization to see if it was successful (and therefore possible to do further initialization if desired).
  • Also in intel_uc.c, intel_uc_supports_guc_submission() is called to see if GuC submission is supported.
    • The definition for intel_uc_supports_guc_submission() is also generated by a macro which defers to intel_guc_submission_is_supported().
    • intel_guc_submission_is_supported() in intel_guc_submission.h checks an internal variable set by __guc_submission_supported(). The requirements are that GuC is supported, and that the GPU must be Gen11 or newer (not Gen12 or newer!)
  • Only now is the firmware actually loaded. From intel_guc.c:
* Enabling the GuC is not mandatory and therefore the firmware is only loaded
* if at least one of the operations is selected.
That __guc_submission_supported implementation conflicts with Intel's documentation: GuC submission is seemingly available on some Gen11 GPUs.
Now, GuC submission being possible is one story, but it being enabled by default is another. At the moment, I do not see why this would be the case. I would be curious to see what is logged on an affected TGL/RKL system with the drm_dbg messages enabled (recompiling the kernel with different settings is probably necessary.
-- Thanks, CodingKoopa (talk) 19:27, 24 July 2022 (UTC)Reply[reply]
Hi, Guc submission seems to be possible on my system as well by setting options i915 enable_guc=3:
$ uname -r
$ cat /proc/cpuinfo
model name	: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
$ lspci -k
00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)
	DeviceName: Onboard - Video
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 12e1
$ sudo dmesg | grep i915
[    1.009923] i915 0000:00:02.0: [drm] VT-d active for gfx access
[    1.010006] i915 0000:00:02.0: vgaarb: deactivate vga console
[    1.010043] i915 0000:00:02.0: [drm] Transparent Hugepage mode 'huge=within_size'
[    1.018442] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    1.020342] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12)
[    1.157918] i915 0000:00:02.0: [drm] GuC firmware i915/tgl_guc_70.1.1.bin version 70.1
[    1.157921] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
[    1.161434] i915 0000:00:02.0: [drm] HuC authenticated
[    1.161777] i915 0000:00:02.0: [drm] GuC submission enabled
[    1.161778] i915 0000:00:02.0: [drm] GuC SLPC enabled
[    1.162428] i915 0000:00:02.0: [drm] GuC RC: enabled
[    1.165574] i915 0000:00:02.0: [drm] Protected Xe Path (PXP) protected content support initialized
[    1.167372] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[    1.170411] fbcon: i915drmfb (fb0) is primary device
[    1.170414] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[    3.670049] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[    3.684363] mei_pxp 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: bound 0000:00:02.0 (ops i915_pxp_tee_component_ops [i915])
[    4.070745] sof-audio-pci-intel-tgl 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
-- Cvlc (talk) 20:18, 30 September 2022 (UTC)Reply[reply]
Thanks for sharing! There are a few more things I am curious about:
  • What kernel version is this (e.g. pacman -Qi linux)? It might be necessary for me to know if I take it up with the Intel Linux folk.
  • What CPU is this? I can see that the Tiger Lake blob is getting loaded, but I am still curious to know the exact model.
  • What is the behavior if you boot without the enable_guc kernel parameter?
Finally, if you are able to do so, to get more messages from i915 you can try booting with the dyndbg="module i915 +p" kernel parameter. This will enable dynamic debugging for the Intel kernel module. -- CodingKoopa (talk) 21:36, 1 October 2022 (UTC)Reply[reply]
I updated my previous post above with kernel / cpu details for clarity. If I boot without the enable_guc kernel parameter, there is no huc/guc reference at all in either dmesg or journalctl, so default seems to be "all off". I don't see any difference in logs when booting with dyndbg="module i915 +p", but maybe I'm not reading from the right place..! Apparently some changes are being made, so the behavior might be different in the next kernel versions. By the way, is there any way to verify or see guc/huc in action (something like intel_gpu_top but specific) ?
-- Cvlc (talk) 21:12, 2 October 2022 (UTC)Reply[reply]
With 6.1.2-arch1-1, the behaviour is still the same, i.e. GUC/HUC enabled with options i915 enable_guc=3, otherwise not. -- Cvlc (talk) 15:12, 4 January 2023 (UTC)Reply[reply]

I have Coffee Lake (i5-8400H and Intel UHD 630), and i915.enable_guc=3 seemingly loads both GuC and HuC firmware. If I recall right dmesg straight up says the load failed and that GuC submissions are disabled with enable_guc=3, but i915_gpu_info guc_info and huc_info say both GuC and HuC are loaded and active (I put the full text on my site here). I also wonder does GuC and/or HuC firmware loading by i915 like this need Intel Management Engine/ME for the firmware validation? I have ME disabled via HAP bit and this caused snd_sof to fail expectedly with firmware loading once I enabled the audio DSP, but apparently GuC/HuC firmware loading don't use the ME for validation, or perhaps only do it on some platforms? I don't have a HECI device. --Espionage724 (talk) 03:37, 19 July 2023 (UTC)Reply[reply]

Incorrect statements regarding power usage penalty of enable_dc=0

It's been recommended to set enable_dc=0 for certain Intel CPUs to prevent catasrophic crashes. However, the statements about the power usage penalty are misleading.

That parameter only controls the power management for the Display Controller and NOT the GPU core power, so the power usage is penalty is not that high. In fact, the penalty for doing so is likely to be miniscule (in the order of a few hundred milliwatts at worst).

—This unsigned comment is by Tensa zangetsu (talk) 2023-08-06T07:12:10. Please sign your posts with ~~~~!

Alder Lake-P freeze from wake issues happen for Raptor Lake too

I'm using an Intel i5-13500H and after weeks of searching I realized that I have the same problem here and when I compile and comment out that line it actually worked. Yes i just wanted to say.

—This unsigned comment is by Venomguard (talk) 09:02, 28 August 2023. Please sign your posts with ~~~~!


i915.fastboot had been removed in 6.7 kernel


which makes fastboot section redundant

btw, any thoughts how this could be worked around?

i've used it on haswell without any problem, and can't imagine why they did it since it is an option

--Bvr (talk) 16:31, 28 January 2024 (UTC)Reply[reply]

Freeze after wake from sleep/suspend with Alder Lake-P

As the note mentions, the listed intel_display.c patch is no longer functional.

I've written an updated one a few weeks back for intel_bios.c that achieves the same result:

--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -3632,6 +3624,14 @@
       struct intel_bios_encoder_data *devdata;

+       int nnn = 0;
        list_for_each_entry(devdata, &i915->display.vbt.display_devices, node)
-               func(i915, devdata);
+       {
+               if (nnn != 1)
+               {
+                       func(i915, devdata);
+                       nnn++;
+               }
+       }

I've never done anything with wikis in my life -> Please advise: edit the wiki or wait for someone else to actually try this patch?

Algernop (talk) 10:35, 5 March 2024 (UTC)Reply[reply]

People are reporting the patch also works for them. My intention is to update the article with this info. Algernop (talk) 11:32, 10 March 2024 (UTC)Reply[reply]