ATI radeon + modesetting

[Andy Wingo]

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