Wandering Thoughts archives

My uncertainties around X drivers for modern Intel integrated graphics

When I switched from my old office hardware to my new office machine, I got surprised by how well the X server coped with not actually having a hardware driver for my graphics card. That experience left me jumpy about making sure that any new hardware I used was actually being driven properly by X, instead of X falling back to something that was just good enough that I didn't know I should be getting better. All of which is the lead up to me switching my home machine over to new modern Intel-based hardware, using Intel's generally well regarded onboard graphics. Everything looked good, but then I decided to find out if it actually was good, and now I'm confused.

(The specific hardware is only slightly different from my original plans.)

Let's start with the first issue, which is how to determine what X modules you're actually using. People who are expert in reading the X log files can probably work this out from the logs but it left me confused and puzzled, so I've now resorted to brute force. X server modules are shared libraries (well, shared objects), so the X server has to map them into its address space in order to use them. If we assume that it unmaps modules it's not using, we can use lsof to determine what current modules it has. On my machine, this reports that the driver it has loaded is the modesetting driver, along with libfb.so and libglamoregl.so (and various Mesa things). Staring at the X logs led me to see:

modeset(0): [DRI2] Setup complete
modeset(0): [DRI2]   DRI driver: i965
modeset(0): [DRI2]   VDPAU driver: va_gl
[...]
AIGLX: Loaded and initialized i965

That seems pretty definite; I'm using the modesetting driver, not the Intel driver. This raises another question, which is whether or not this is a good thing. Although I initially thought there might be problems, a bunch of research in the process of writing this entry suggests that using the modesetting driver is the right answer (eg the Arch wiki entry on Intel graphics, which led me to the announcement that Fedora was switching over to modesetting). In fact now that I look back at my earlier entry, a commentator even talked about this switch.

(Before I found this information, I tried forcing X to use the Intel driver. This sort of worked (with complaints about an unrecognized chipset), but Chrome didn't like life so I gave up pretty much immediately. This might be fixed in the latest git tree of the driver, but if modesetting X works and is preferred, my motivation for building the driver from source is low.)

Unfortunately this leaves me with questions and concerns that I don't have answers to. The first issue is that I don't know how much GPU accelerated OpenGL I have active in this configuration. Since I can run some OpenGL stress tests without seeing the CPU load go up very much, I'm probably not using much software rendering and it's mostly hardware. Certainly xdriinfo reports that I have DRI through an i965 driver and glxinfo seems to know about the hardware.

(Specifically, glxinfo reports in several sections that it's using 'Mesa DRI Intel(R) HD Graphics (Coffeelake 3x8 GT2) (0x3e92)'. The 0x3e92 matches the PCI ID of the integrated graphics controller.)

The second issue is video playback, which for reasons beyond the scope of this entry is one of my interests. One of the ways that I noticed problems the first time around was that vdpauinfo was completely unhappy. This time around it's partially unhappy, but it says its using the 'OpenGL/VAAPI backend for VDPAU'. VAAPI (also) is an Intel project, and it has its own information command, vainfo. Unfortunately vainfo is not happy with my system; if I can read its messages correctly, it's unable to initialize the hardware driver it wants to use. Of course I don't know whether this even matters for basic video playback, even of 1080p content, or if common Linux video players use VAAPI (or VDPAU).

(Part of the issue may be that I have a bit of a Frankenstein mess of packages, with some VAAPI related packages coming from RPM Fusion, including the libva Intel driver package itself. Possibly I should trim down those packages somewhat.)