My uncertainties around X drivers for modern Intel integrated graphics

March 27, 2018

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


Comments on this page:

From 193.219.181.219 at 2018-03-27 03:11:14:

The first issue is that I don't know how much GPU accelerated OpenGL I have active in this configuration.

I'm not sure if my knowledge is accurate, but AFAIK you have the exact same amount of 3D acceleration regardless of DDX, because it is only involved in displaying the final output buffers, via DRI2/DRI3/Present. So you're bypassing most of it anyway.

Your 3D programs use Mesa through libGL (and /usr/lib/dri/i965_dri.so), and that's where all 3D acceleration code lives. Mesa then talks to the kernel driver directly, not via Xorg.

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.

Is it trying to use the Intel driver in the first place? If not, LIBVA_DRIVER_NAME=i965 might help things.

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

Many of them do, though not always by default (since e.g. seeking can be troublesome, and sometimes decoding is outright buggy).

mpv, mplayer, VLC have it as an option. Totem and other GStreamer-based players will automatically use it as long as the libgstvaapi.so or libgstvdpau.so modules are installed.

There's a number of signs of people pushing to get away from the intel-specific Xorg driver, like the Debian package describing itself as deprecated. People have pointed out it wasn't making formal releases with any frequency.

If modesetting seems to work "well enough", then I wouldn't want to deliberately switch to the old way.

Gnome on Debian Buster (testing) has followed Fedora by switching to Wayland by default, and so has Ubuntu 17.10. At this point I think your user base for testing is just gone, and it will succumb to bitrot.

(No insight into AMD/NVidia; just talking about the Intel one).

Apparently a bunch of DRM kernel drivers (i.e. supporting modesetting) have been merged for diverse hardware over the past couple of years.

https://www.collabora.com/news-and-blog/blog/2018/03/20/a-new-era-for-linux-low-level-graphics-part-1/

Written on 27 March 2018.
« xprt: data for NFS mounts in /proc/self/mountstats is per-fileserver, not per-mount
The correlation between Spamhaus Zen listings and attachment types (March 2018 edition) »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Mar 27 02:05:16 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.