Querying your 3D stack
Intel’s numbering systems make no sense, but whatever your card there’s plenty of demos to play with…
For a long time, users of middle-aged Intel hardware were stuck using the venerable i965 Mesa driver. This caters to a range of hardware, from Broadwater (2006) to the HD and Iris graphics found in some Skylake chips (2015). For older hardware there’s the i915 Mesa driver, not that such hardware had much in the way of 3D capability. Newer, so-called Gen8 graphics and above (from Broadwell through to the latest Xe graphics) is supported by the Iris Gallium3D driver.
The i965 (and i915) driver dates back to before the Gallium framework was developed, and throughout last year there were calls to retire it. However, Mesa aren’t in the habit of mass-scale hardware abandonment, so until a replacement was finalised, i965, and other ‘classic’ Mesa drivers were granted a reprieve. That replacement driver goes by the name of Crocus and it’s ready for prime time. So the classic Mesa drivers were deprecated (more precisely demoted to ‘amber’ status, like the preserved bugs in Jurassic Park) in December 2021. If you’re running the latest Fedora, Ubuntu or a rolling release distro (on appropriate hardware) then you will already be using Crocus.
What’s in a name?
First though, let’s clear up Intel’s slightly awkward generational naming. Intel’s seventh-generation processors (codename Kaby Lake, part of the Sky Lake microarchitecture) include the four-core 7700HQ desktop CPU and the mobile 7500U. That all seems consistent, everything begins with 7. However, some Kaby Lake processors sport Iris Plus 630 or 640 graphics, and some feature the lesser HD 6x0 technology. So not only is there a numerical discrepancy, but at first glance it would seem that the Mesa Iris driver (explicitly described as for Gen8 and later) shouldn’t be used in (some) Kaby Lake systems. Except that’s not right – the Iris driver caters to this generation of Intel graphics, too. In fact, it caters to one generation before that. So the iris driver actually caters to some non-Iris chips, and Gen9 graphics are actually found in processors marketed as 7th Gen. Even Intel aren’t immune from off-by-one errors, it would seem.
We can check which kernel driver and Mesa driver is in use by running
$ LIBGL_DEBUG=verbose glxgears
Almost all Intel graphics use the i915 kernel driver (named for the first Pentium 4 chipset), and the Mesa driver will be shown immediately below, for example:
libGL: using driver i915 for 4 libGL: pci id for fd 4: 8086:5916, driver iris libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linuxgnu/dri/iris_dri.so)
If you want something a bit more interesting than spinning cubes to test your OpenGL stack then the
GLMark2 benchmark is a fun diversion. Instead of spinning cubes, this will display spinning horses, boxes, rabbits and cats in a variety of filters and shadings. And it’ll give you a score at the end (which is a little useless without some comparison). You can get GLMark2 with
$ sudo apt install glmark2
In order to get information from it, or indeed any OpenGL application, you can use the GALLIUM_HUD
environment variable, which will overlay a neat heads-up display. This has a huge number of options, but the popular ones include frames per second (FPS), load and temperature (GPU and CPU), VRAM usage as well as memory and shader frequencies. Here’s a example:
GALLIUM_HUD=“.c70fps,cpu” glxgears
You may need to resize the window to see the effect here. The .c70 part ‘clamps’ the graph to 70fps here. The comma separates the two panes vertically. Use a semicolon to do so horizontally, or use a plus sign to have two items share a pane. It’s possible to specify co-ordinates for each entry, which can makes the syntax a little hard to parse.
Different Gallium drivers have different options. For example, the iris driver has no VRAM options. You can see a list with GALLIUM_HUD=“help” .
Enter the Vulkan
Vulkan is the latest, greatest graphics API on the scene. And it’s very unlikely there’ll be a Vulkan-DirectX 12 conflict in the same way that OpenGL had to face down DirectX in the past. Sure, Microsoft might rather developers use Direct3D 12, but even if they don’t Vulkan is equally well supported on Windows, Mac, mobile and embedded. Basically the whole industry is behind it. Officially launched in 2016, it’s designed to be low-overhead and to better allow developers to take advantage of multicore CPUs (as with OpenGL, it doesn’t make sense for all types of work to get done on the GPU). It’s predecessors all appeared when CPUs had but one core, and later versions of OpenGL and DX11 could only accommodate the most basic of support for more.
Vulkan is also unifying in the sense that there’s no need for separate APIs, for example, for mobile and desktop, or for compute and graphics. Being a shiny, modern invention, it supports the latest GPU features such as ray tracing. Support is provided through Mesa, except for proprietary drivers. The Nvidia driver has had Vulkan support for some time.
Analogous to glxgears Vulkan has its own vkcube test application. Perhaps even more plain than the former, vkcube displays a only a single spinning cube with the LunarG logo. Don’t worry, there’s plenty of more interesting demonstrations, including vkmark which you might be interested in building from source yourself (see https://github.com/vkmark/vkmark for details). Many games now include a Vulkan backend, one of the first to be supported on Linux was Croteam’s The Talos Principle.
We can get some measurements out of a Vulkan application with by prefixing a delightfully awkward environment variable:
VK_INSTANCE_LAYERS=VK_LAYER_MESA_overlay vkcube
This does nothing on non-Vulkan applications. Like the OpenGL overlay, the Vulkan one can be configured with lengthy syntax too. See https://gitlab.freedesktop. org/mesa/mesa/-/tree/main/src/vulkan/overlay-layer
for details. The Vulkan overlay has been forked to create MangoHUD, a more fully featured dashboard, which you should certainly check out.
One of the most exciting applications of Vulkan appeared in 2018, when lone developer Philip Rebohle started the DXVK project. Initially, that project had one mission: leverage Vulkan to translate the DirectX 11 calls of the popular game NieR:Automata, so that it could be played at near-native speed via Wine on Linux. It sounded crazy, but soon the mission was accomplished. Soon DXVK’s remit expanded, and it became a general layer for translating DirectX 9, 10 and 11 calls into Vulkan ones, with the side-effect that suddenly a huge number of Windows titles could suddenly be played. The reason for this rapid development soon became clear: Rebohle had been sponsored by Valve, which was about to announce its DXVK-powered fork of Wine, now called Proton. Thanks to Proton, Linux (and in particular Valve’s Steam Deck) can play over 5,000 titles that used to be strictly Windows-only.
But the adventures don’t stop there. A second project, VKD3D appeared soon after DXVK with the goal of targeting DirectX 12 titles. This was started by Wine
developer Józef Kucia who sadly passed away before being able to complete it. VKD3D was then picked up by Valve and integrated into Proton. So there’s less reason than ever to be running Windows.