Hi, I just upgraded my desktop machine for the first time in about 3 months. It has this graphics card from about 5 years ago:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 7570] After the upgrade, I was experiencing horrible tearing and corrupted graphics. (I do install the binary firware blobs, for what that's worth, but that wasn't the source of the problem.) This reminded me of something I had experienced in the past with Intel on laptops, though with less intense effects: https://bugs.freedesktop.org/show_bug.cgi?id=101620 The ultimate problem in that case was that when running an OpenGL-enabled composited window manager like gnome-shell, some updates would not be synchronized to the display. There were various things you could do to ungarble the display on the application level, but it was very irritating. The origin of the problem is that the synchronization facilities exposed by OpenGL / GLX weren't playing well with the acceleration architecture in the Intel xorg driver. To explain this, some background follows. Historically there were different acceleration paths for 2D and 3D graphics on Linux/X. Some graphics people work to accelerate 3D, and some do 2D. If you have an intel card you might remember XAA, EXA, UXA, SNA, etc; those are all 2d acceleration paths. Now these days there is convergence to accelerate 2D in terms of 3D -- i.e. translate 2D operations to 3D operations, as much as possible. Then you just need to have one good generic 3d acceleration backend. The new "modesetting" xorg driver is just that: a generic xorg graphics driver incorporating a generic 2D-in-terms-of-OpenGL acceleration architecture called "glamor". The modesetting xorg driver needs basic facilities from the kernel to get the card into the right mode, then it can hook into the card-specific support for OpenGL/etc provided by Mesa. One of these kernel facilities is called "modesetting", hence the name of the driver. Glamor and the modesetting driver are now shipped as part of the X server itself, not as separate modules. Switching from the Intel driver to the modesetting driver was thus a switch from a separate 2D and 3D accel path to a unified path. Additionally, the 2d accel path in the intel driver was not very well maintained. There had been no release of xf86-video-intel for a couple years; distros that used that driver (a dwindling number; Debian switched over last year) used Git snapshots. The "SNA" acceleration architecture that the Intel devs came up with was indeed fast, but had some problems that couldn't be resolved related to buffer synchronization. Normally SNA worked fine but for some reason emacs under a composited WM exhibited corruption, so in guix we switched back to UXA, an earlier 2D accel architecture, but that was quite slow. So in c68c201fdd429140da1c606861c9296b9cb01265, we switched over to prefer the modesetting driver for Intel cards that are recent enough to have enough OpenGL support for the glamor pipeline to be usable. Recalling all of this history, I thought that perhaps a switch to modesetting could fix my radeon problems as well, and indeed, voilà, this patch fixes it: --- a/gnu/services/xorg.scm +++ b/gnu/services/xorg.scm @@ -117,7 +117,7 @@ Section \"Files\" FontPath \"" font-adobe75dpi "/share/fonts/X11/75dpi\" ModulePath \"" xf86-video-vesa "/lib/xorg/modules/drivers\" ModulePath \"" xf86-video-fbdev "/lib/xorg/modules/drivers\" - ModulePath \"" xf86-video-ati "/lib/xorg/modules/drivers\" + # ModulePath \"" xf86-video-ati "/lib/xorg/modules/drivers\" ModulePath \"" xf86-video-cirrus "/lib/xorg/modules/drivers\" ModulePath \"" xf86-video-intel "/lib/xorg/modules/drivers\" ModulePath \"" xf86-video-mach64 "/lib/xorg/modules/drivers\" Removing the ATI driver from the X server makes modesetting the "best" available driver; from Xorg.0.log: [ 465.481] (==) Matched ati as autoconfigured driver 0 [ 465.483] (==) Matched ati as autoconfigured driver 1 [ 465.485] (==) Matched modesetting as autoconfigured driver 2 [ 465.487] (==) Matched fbdev as autoconfigured driver 3 [ 465.489] (==) Matched vesa as autoconfigured driver 4 [ 465.491] (==) Assigned the driver to the xf86ConfigLayout [ 465.491] (II) LoadModule: "ati" [ 465.494] (WW) Warning, couldn't open module ati [ 465.494] (II) UnloadModule: "ati" [ 465.494] (II) Unloading ati [ 465.498] (EE) Failed to load module "ati" (module does not exist, 0) [ 465.498] (II) LoadModule: "modesetting" [ 465.500] (II) Loading /gnu/store/2ka3fa3rkxglhn88pqfv8gpcw0ai8fjk-xorg-server-1.19.5/lib/xorg/modules/drivers/modesetting_drv.so [ 465.502] (II) Module modesetting: vendor="X.Org Foundation" [ 465.502] compiled for 1.19.5, module version = 1.19.5 [ 465.504] Module class: X.Org Video Driver [ 465.504] ABI class: X.Org Video Driver, version 23.0 I think I would like to apply this patch to Guix. My only concern would be that perhaps there are people using older radeon cards that don't support Glamor; dunno. I do see bugs around this area that suggest that the radeon driver is also slipping into disrepair, e.g.: https://bugs.freedesktop.org/show_bug.cgi?id=102054 But considering that the ATI driver was only added to the default modules a year ago in 3126fd8820e8c30e27ef978d66dced8763d04905, before our Xorg server configuration included the paths to the modesetting driver, perhaps the risk is low. Any thoughts? Andy
