How do I tell Fedora to use the i915g driver instead of i915?

Dear hivemind, forgive the fact that I’ve been spoiled by 10+ years of graphics “just working” automatically on Fedora… but how do I actually tell a Fedora machine to “use the i915g driver” instead of the classic i915 driver?

The reason is that I’m trying to check if this Mesa bug (that causes any GTK4 application to instant-crash on systems from the Core2 era, with GMA 3100 graphics for example) is solved by using a different driver, if Fedora is not already using i915g by default. I’ve looked everywhere on the interwebs and could not find any trace of someone asking this question, or documentation on how to do that. If it does make it work, then I would suggest Fedora uses it by default, but I’m not sure where to formally request that.

I’m using Arch Xorg, btw.

Is there no way at all to achieve this from a user’s standpoint? Is it entirely in the hands of what the packagers have compiled?

Really not sure. Is the other driver packaged and available? Usually loading drivers with modprobe does the job? I guess you could blacklist the one you don’t want to use similar to how folks blacklist nouveau when they use the nvidia proprietary driver?

In mesa 22.0 the classic i915 driver has been removed, so newer releases are using i915g. For now you can test it at your own risk by using some copr repo with fresh mesa. In koji there’s only one build for fc37.

Before that, it was a build-time choice and mesa-21.3.8-2.fc35 was built with a classic i915 (DRI) driver:
https://kojipkgs.fedoraproject.org//packages/mesa/21.3.8/2.fc35/data/logs/x86_64/build.log

Message: Configuration summary:

    prefix:          /usr
    libdir:          lib64
    includedir:      include
    
    OpenGL:          yes (ES1: no ES2: yes)
    
    OSMesa:          libOSMesa
    
    DRI platform:    drm
    DRI drivers:     nouveau r100 r200 i915 i965
    DRI driver dir:  /usr/lib64/dri
    
    GLX:             DRI-based
    
    EGL:             yes
    EGL drivers:     builtin:egl_dri2 builtin:egl_dri3
    EGL/Vulkan/VL platforms:   x11 wayland surfaceless drm
    GBM:             yes
    GBM backends path: /usr/lib64/gbm
    
    Vulkan drivers:  swrast amd intel
    Vulkan ICD dir:  share/vulkan/icd.d
    Vulkan layers:   device-select
    
    llvm:            yes
    llvm-version:    13.0.0
    
    Gallium drivers: swrast virgl nouveau r300 crocus iris svga radeonsi r600 zink
    Gallium st:      mesa xa vdpau omxbellagio va nine clover
    HUD lmsensors:   no
    
    Shared-glapi:    yes
    
    Perfetto:        no
    Perfetto ds:     auto
5 Likes

Ah, so if I’m interpreting the situation correctly, it seems the upcoming Fedora 36 has mesa 21.3.8 like F35, and it likely still uses i915 instead of i915g? Oh boy, that doesn’t bode well for people using such chipsets as they will encounter those increasingly-numerous insta-crashing GTK4 apps in F36 :pensive:

I’ve no idea what COPR to be looking for though, xxmitsu/mesa-git Copr seems to be the first result that turns up in search engines and the warnings on that page are a bit scary; it seems to have mesa 22.1 in there however, so I presume this would pretty much guarantee that it’s using i915g :thinking:

Mesa 22.0 will hit F36 soon, probably after it’s release. F35 might not be that lucky.

This repo contains an in-development packages (mesa-git), it’s safer to use released stable versions.
Looking at build from https://copr.fedorainfracloud.org/coprs/calcastor/mesa/, this should be your best bet for now, it’s built from official fedora source:


Keep in mind that it’s the first major release with new features and there’ll be minor releases with bugfixes later.

To be sure, you’d have to check build log (available in copr) for configuration summary (like the one I posted before), if there’s i915 listed in Gallium drivers, you’re guaranteed it’s built. If it’s not built, system will fall-back to software rendering, slower but fully-featured and less buggy than i915.

2 Likes

In case this helps anyone reading this, I tested the F36 beta liveUSB today and it is indeed affected by this bug. I will have to wait some time during the summer, after the F36 release and its post-release updates, to try installing it to a spare test drive to test the machine again; my assumption is that until Mesa 22 is proven to solve the problem, all GTK4 apps will be broken for anyone running i915-based GPUs.

1 Like

Is there a Fedora bugzilla bug for this? If not, could you please file one? This seems like a release blocker.

5 Likes

I unfortunately hadn’t gotten around to filing it on Fedora’s Bugzilla yet; I originally filed it in gnome-shell/gnome-shell-extensions-prefs, then was bounced to report the issue in GTK, then was bounced to freedesktop/mesa to file a ticket there that ended up a dead-end (for now), then eventually made it here in a last-ditch attempt at investigating/testing this, to maybe get back to the mesa ticket if the i915g driver happens to be similarly affected… and only recently with the beta live image was I able to check if the issue was still occurring (and I was not able to do much except check there, except run lsmod where it seems the “i915” module is loaded, so I’ll presume it’s not using i915g even with mesa 21). I’m unsure if the final release will be affected. What component should this be filed on in Bugzilla, “mesa” I presume?

I see that there is https://bodhi.fedoraproject.org/updates/FEDORA-2022-4120f31977 in the pipeline now though, so maybe this could solve it (fingers crossed). However, I am unable to test it because that would require a fully upgraded install of F36 beta + test updates, and… you’re going to either laugh or cry at this @mattdm, but Anaconda refuses to start on that machine with the F36 beta liveUSB :person_facepalming: It launches but then shows up only as a black screen and sits there. Same thing if launched with sudo anaconda from a terminal, and the terminal gives no errors (only atk-bridge warnings). If launched as root (after su in a terminal), then it crashes on startup. And yet, as far as I know, that application is not even GTK4, so maybe I found a wholly different issue now. I guess I’ll try grabbing the resulting 800 MB core dump file that was created in /tmp when run as root, and attach the resulting 15 MB compressed version to a Bugzilla ticket on Anaconda.

So, to recap, GTK4 apps crash on startup in the F36 beta liveUSB, it seems Mesa updates are coming that might (or might not) solve the issue, but I can’t test them in the current state of things… and I may have found an issue that makes the installer unusable on those machines, unless it’s somehow related.

Now we have two problems :crazy_face:

2 Likes

I have now reported the two potential blocker bugs I’ve encountered:

3 Likes

Hmmm. Is this only Core 2 systems? I don’t think I have anything from that era to test with.

Looks like my Broadwell HD Graphics 5500 is using the i915 driver. I can’t reproduce any of the reported crashes. Might be isolated to older systems?

lspci -v
00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
        Subsystem: Lenovo Device 5034
        Flags: bus master, fast devsel, latency 0
        Capabilities: [e0] Vendor Specific Information: Len=0c <?>
        Kernel driver in use: bdw_uncore

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Lenovo Device 5036
        Flags: bus master, fast devsel, latency 0, IRQ 47
        Memory at e0000000 (64-bit, non-prefetchable) [size=16M]
        Memory at c0000000 (64-bit, prefetchable) [size=512M]
        I/O ports at 3000 [size=64]
        Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [a4] PCI Advanced Features
        Kernel driver in use: i915
        Kernel modules: i915
1 Like

I have a spare Core 2 era Intel box. I’ll see if I can reproduce it on f36 tomorrow.

2 Likes

I have an HD Graphics 4000 (IVB GT2) that’s using i915. It currently has Fedora 34 on it. I’m going to upgrade it to 36 and see what happens.

I have three other boxes from that era, but I’m not sure if any of them have an older Intel GPU, but two of them are in storage somewhere, so this is the easiest for me to conveniently get to, atm.

I did have an older box at work with an Intel GPU that failed to worked graphically on CentOS Stream 9 until I installed the Fedora Mesa drivers on it, but that one worked just fine on Fedora.

Maybe we need to go even older than this February 2013 machine, but the i915 driver is working fine so far on this machine in Fedora 36 with Mesa 22.

gtk4-demo (from the link in the OP) works, too:

I believe my post right here should give some evidence of Mesa 22 working just fine for i915 on Fedora 36. Are you able to upgrade to Fedora 36 and try it out on your hardware? I have some older hardware here I can possibly bring out, but this looks like a viable test AFAICT for the original post and the mesa issue link.

I think my GPU here is likely close enough to be a useful test for this, but I almost certainly have access to this specific GPU at work. If it’s urgent for Fedora 36, I can try to locate some hardware to test it out early next week.

3 Likes

i915 in your screenshot is the kernel module, not mesa driver (Gen 3 Core CPU has Gen 7 Intel GPU - currently supported by crocus driver that replaced i965 classic driver).
i915 mesa driver supports Gen 2 and Gen 3 Intel GPUs (in early Core CPUs, Pentium 4 and some earlier): intel - Gentoo Wiki

From what I see, with mesa 22 i915 classic has been dropped and i915g isn’t built by default, so building it might fix the anaconda issue.

Configuration summary from https://kojipkgs.fedoraproject.org//packages/mesa/22.0.1/1.fc36/data/logs/x86_64/build.log

    prefix:          /usr
    libdir:          lib64
    includedir:      include
    
    OpenGL:          yes (ES1: no ES2: yes)
    
    OSMesa:          libOSMesa
    
    DRI platform:    drm
    DRI drivers:     no
    DRI driver dir:  /usr/lib64/dri
    
    GLX:             DRI-based
    
    EGL:             yes
    EGL drivers:     builtin:egl_dri2 builtin:egl_dri3
    EGL/Vulkan/VL platforms:   x11 wayland surfaceless drm xcb
    GBM:             yes
    GBM backends path: /usr/lib64/gbm
    
    Vulkan drivers:  swrast amd intel
    Vulkan ICD dir:  share/vulkan/icd.d
    Vulkan layers:   device-select
    
    llvm:            yes
    llvm-version:    13.0.1
    
    Gallium drivers: swrast virgl nouveau r300 crocus iris svga radeonsi r600 zink
    Gallium st:      mesa xa vdpau omxbellagio va nine clover
    HUD lmsensors:   no
    
    Shared-glapi:    yes
    
    Perfetto:        no
    Perfetto ds:     auto
1 Like

Hi folks, I looked at @vwbusguy’s screenshots above (and thought “Huh? Is it really using the Intel GPU, or the nvidia/nouveau one?”) but if I understand @ozeszty’s reply correctly that is indeed not the case, as the i915g driver is not built/available to users at all in Fedora 36?

In any case today I had some time to do a quick test (for the first time in months) alongside my AMD GPU/radeon troubleshooting question, so I simply flashed the final release of Fedora 36 Workstation onto a USB key and booted it onto the affected Core2 Quad Q9300 computer with its GMA 3100 graphics (that machine was not in my office for months, and only recently was I able to bring it back).

Result: while I was initially pleased to see that it was able to boot up and run GTK4 applications on the liveUSB (such as GNOME Control Center, GNOME Calendar, and gnome-extensions-app), I realized what was truly going on: GNOME Control Center, under About → Graphics, says “Software rendering”. So it’s not using the GPU at all, which leads to pretty bad performance. This is a bit disappointing because I recall that Intel GPU chip being plenty smooth enough for composited desktop usage a while back, so I’m not sure why it wouldn’t be able to still work reasonably fast today.

I’ve opened a bugzilla report to suggest the idea that Fedora 36’s mesa package should build/provide the i915g driver for users by default, in case there is some hope for this to work.

1 Like

Recently I installed xubuntu 22.04 on similarly old computer. It comes with separate package containing classic (DRI) drivers (so working out of the box like before i915 removal): libgl1-amber-dri.
I removed it (software/CPU rendering by LLVMpipe took over), used ppa:ernstp/mesarc that builds i915 Gallium and it works fine.

Good idea with that bug report, I can do some testing for it.

As for checking whether your system is using i915 or i915g, both drivers are built to the same driver i915, but use different names:

Gallium driver - Device: i915 (chipset: 945G) (0x2772)

$ glxinfo -B
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Mesa Project (0x8086)
    Device: i915 (chipset: 945G) (0x2772)
    Version: 22.1.3
    Accelerated: yes
    Video memory: 192MB
    Unified memory: yes
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 2.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0
OpenGL vendor string: Mesa Project
OpenGL renderer string: i915 (chipset: 945G)
OpenGL version string: 2.1 Mesa 22.1.3
OpenGL shading language version string: 1.20

OpenGL ES profile version string: OpenGL ES 2.0 Mesa 22.1.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

Classic driver - Device: Mesa DRI Intel(R) 945G (0x2772)

$ glxinfo -B
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) 945G  (0x2772)
    Version: 21.3.7
    Accelerated: yes
    Video memory: 192MB
    Unified memory: yes
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 1.4
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 945G 
OpenGL version string: 1.4 Mesa 21.3.7 Amber

OpenGL ES profile version string: OpenGL ES 2.0 Mesa 21.3.7 Amber
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

i915g is now built in fedora, have you tested it?
https://bodhi.fedoraproject.org/updates/FEDORA-2022-3c2f8b2a0d

I have (finally) tested it now with the Fedora 37 liveUSB image, and functionally it works. I’m just not sure if it’s actually using the i915g driver or if it’s all going through software rendering via LLVMpipe, as GTK4 apps successfully launch and work in a fluid way, but information seems to be a bit contradictory…

In GNOME Control Center’s “About” panel, for “Graphics” it says: i915 (chipset: G33)

However, glxinfo -B seems to tell a different story, it mentions LLVM:

[liveuser@localhost-live ~]$ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Mesa/X.org (0xffffffff)
    Device: llvmpipe (LLVM 15.0.0, 128 bits) (0xffffffff)
    Version: 22.2.2
    Accelerated: no
    Video memory: 4908MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 4.5
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 15.0.0, 128 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 22.2.2
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.5 (Compatibility Profile) Mesa 22.2.2
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

When launching GTK4 apps, I see some warnings in the terminal:

[liveuser@localhost-live ~]$ gnome-calculator 
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps
MESA: error: Exceeded 16 max TGSI temps

(gnome-calculator:3990): Gsk-WARNING **: 13:10:03.013: Linking failure in shader:
error: looping not supported i915 fragment shaders, all loops must be statically unrollable.
Gsk-Message: 13:10:03.014: Failed to realize renderer of type 'GskGLRenderer' for surface 'GdkWaylandToplevel': Linking failure in shader: error: looping not supported i915 fragment shaders, all loops must be statically unrollable.

…but the apps work smoothly and normally, so eh, I guess that warning isn’t a problem. And the thing works, in practice. I’m just curious whether it’s actually using the gallium i915g GPU drivers or not, because it seems “too smooth” to be LLVMpipe.