A recent performance surprise with X on my Fedora Linux desktop

January 18, 2018

As I discussed yesterday, on Monday I 'upgraded' my office workstation by transplanted my system disks and data disks from my old office hardware to my new office hardware. When I turned the new hardware on, my Fedora install booted right up pretty much exactly as it had been (some advance planning made networking work out), I logged in on the text console, started up X, and didn't think twice about it. Modern X is basically configuration free and anyway, both the old and the new hardware had Radeon cards (and the same connectors for my monitors, so my dual-screen setup wouldn't get scrambled). I even ran various OpenGL test programs to exercise the new card and see if it would die under far more demanding load than I expected to ever put on it.

(This wound up leading to some lockups.)

All of this sounds perfectly ordinary, but actually I left out an important detail that I only discovered yesterday. My old graphics card is a Radeon HD 5450, which uses the X radeon driver. My new graphics card is a Radeon RX 550, but things have changed since 2011 so it uses the more modern amdgpu driver. And I didn't have the amdgpu driver installed in my Fedora setup (like most X drivers, it's in a separate RPM of its own), so the X server was using neither the amdgpu driver (which it didn't have) nor the radeon driver (which doesn't support the RX 550).

The first surprise is that X worked anyways and I didn't notice anything particular wrong or off about my X session. Everything worked and was as responsive as I expected, and the OpenGL tests I ran seemed to go acceptably fast (as did a full-screen video). In retrospect there were a few oddities that I noticed as I was trying things due to my system hangs (xdriinfo reported no direct rendering and vdpauinfo spat out odd errors, for example), but there was nothing obvious (and glxinfo reported plausible things).

The second surprise is what X was actually using to drive the display, which turns out to be something called the modesetting driver. This driver is a quite basic one that relies on kernel mode setting but is otherwise more or less unaccelerated. Well, sort of, because modesetting was apparently using glamor to outsource some rendering to OpenGL, in case you have hardware accelerated OpenGL, which I think that I did in this setup. I'm left unsure of how much hardware acceleration I was getting; maybe my CPU was rendering 24-bit colour across two 1920x1200 LCDs without me noticing, or maybe a bunch of it was actually hardware accelerated even with a generic X driver.

(There is a tangled web of packages here. I believe that the open source AMD OpenGL code is part of the general Mesa packages, so it's always installed if you have Mesa present. But I don't know if the Mesa code requires the X server to have an accelerated driver, or if a kernel driver is good enough.)

PS: Kernel mode setting was available because the kernel also has an amdgpu driver module that's part of the DRM system. That module is in the general kernel-modules package, so it's installed on all machines and automatically loaded whenever the PCI IDs match.

PPS: Given that I had system lockups before I installed the X server amdgpu driver, the Fedora and freedesktop bugs are really a kernel bug in the admgpu kernel driver. Perhaps this is unsurprising and already known.

Comments on this page:

From at 2018-01-18 06:21:54:

Indeed, most acceleration code has been moved out of the "xf86" DDXes into the kernel & Mesa, because of course Wayland or Mir cannot use Xorg-specific modules, so it's advantageous to many projects.

It has even gotten to the point where xf86-video-modesetting (using Glamor) is often considered better and faster than the "official" xf86-video-intel DDX, at least in the IRC channels I frequent. (It supports DRI3, and certainly doesn't crash the way xf86-video-amdgpu has started doing.)

Mesa provides backends for VDPAU and LibVA as well (although they might be in a separate package – look for libvdpau_radeon.si.so and radeonsi_drv_video.so.)

Written on 18 January 2018.
« My new Ryzen desktop is causing Linux to hang (and it's frustrating)
Why Go cares about the difference between unsafe.Pointer and uintptr »

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

Last modified: Thu Jan 18 00:54:49 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.