Talk:Intel graphics

From ArchWiki
(Redirected from Talk:Intel Graphics)

[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 'wiki.archlinux.org' 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)

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)
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)
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)
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)
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)
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 https://wiki.archlinux.org/index.php?title=Talk:Intel_graphics&oldid=737996 so that it will continue to work once this section has been closed and deleted. Thanks, CodingKoopa (talk) 02:31, 17 July 2022 (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)

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.

https://imgur.com/a/9DB1Xhf

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

https://imgur.com/a/WIgYqXI

—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)