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.
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.
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
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
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.
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.
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 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.
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.
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.
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.
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.
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:
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.