Last modified: 2023-12-17 20:11
This page is about old GPUs on Linux. All referenced drivers are 32-bit x86 Linux unless otherwise stated.
Reference
Nvidia download links
Nvidia driver versions
Nvidia patching how-to
Nvidia MTRR fiasco
Extinction events
Kernel drivers
Nvidia
Arch maintenance
ATI/AMD
XFree86/X.Org
Mesa library
Utah GLX
Slackware cross-index for last working versions
Reversion kits
Nvidia 71.86.15
Nvidia 96.43.23, S3 ViRGE, S3 Trio3D, SiS 315, and Trident (XAA)
Nvidia 173.14.39
Nvidia 304.xxx
Experiences with drivers generically
Nvidia proprietary driver
Nouveau
Nv
Intel
Trident
S3virge
SiS
Experiences with specific cards / chipsets
Nvidia
ATI
Trident
S3
3dfx
SiS
Intel integrated graphics
You need all of these because the links don't always get updated.
304.137: file date 2017-09-15; compatible with Slackware 14.2 or Reversion Kit 4.
The 304 series is ostensibly the right choice for GeForce 6 series cards, but the following problems cause me to revert to 173.14.39 or 96.43.23.
NVIDIA OpenGL Driver requires CPUs with SSE to run.
The current CPU does not support SSE.
173.14.39: file date 2013-12-02; compatible with Slackware 14.1 or Reversion Kit 3.
96.43.23: file date 2012-09-04; compatible with Slackware 14.0 or Reversion Kit 2. 96.43 is needed by cards in the GeForce2 MX to GeForce4 range but is usable with 6-series cards.
71.86.15: file date 2011-07-20; compatible with Reversion Kit 1. The file date is misleading; apparently Nvidia maintained kernel compatibility for quite some time after they let the X server ABI breakage go to hell. I had to go all the way back to Slackware 12.2 (2008-12) before the driver would work, which means that the last compatible X server version is either 1.4 or 1.5.
The last kernel for which the 71.86.15 module will build and load without patching is 3.2.x (a longterm branch), and then only with an old environment. It worked for me with GCC 4.2.4 (what came with Slackware 12.2), but with GCC 4.8.2 under Slackware 14.1 it would say "Unknown symbol init_mm (err 0)" and refuse to load.
List of cards needing the 71.86 drivers:
NVIDIA chip name Device PCI ID ---------------------------------- ---------------------------------- RIVA TNT 0x0020 RIVA TNT2/TNT2 Pro 0x0028 RIVA TNT2 Ultra 0x0029 Vanta/Vanta LT 0x002C RIVA TNT2 Model 64/Model 64 Pro 0x002D Aladdin TNT2 0x00A0 GeForce 256 0x0100 GeForce DDR 0x0101 Quadro 0x0103 GeForce2 GTS/GeForce2 Pro 0x0150 GeForce2 Ti 0x0151 GeForce2 Ultra 0x0152 Quadro2 Pro 0x0153
And they're serious about it. The installer for 96.43.23 tests for a supported GPU and bails out with a very specific error if all it finds is a TNT card.
The arch patches, which are contained in tarballs such as nvidia-96xx-dkms.tar.gz that used to be available from aur.archlinux.org, apply like follows:
cd usr/src/nv # does not apply to 390 patch -p1 < whatever/173.14.36-37.patch patch -p1 < whatever/173.14.37-38.patch patch -p1 < whatever/linux-3.17.patch patch -p1 < whatever/linux-3.19.patch patch -p1 < whatever/linux-4.0.patch etc.
See the reversion kits.
Nvidia 96 and 173 want to link with a couple of kernel functions, mtrr_add and mtrr_del, that were hidden (un-exported) by kernel devs in version 4.3. This breaking change was an attempt to force drivers to migrate to a newer, architecture-agnostic API (commit).
The MTRR functions are useful only if PAT is not supported. Both are used by the Nvidia driver to optimize the performance of the memory cache. PAT has existed on Intel CPUs since the P3, but the kernel disables it on P3, Core Solo and Core Duo CPUs due to an erratum.
Since the MTRR function is useful only on very old CPUs, the workaround adopted in arch patches is to remove MTRR support from the Nvidia drivers. This could kill performance on PCs with Core Duo or older CPUs. A simple patch to put back the exports of mtrr_add and mtrr_del works with LTS kernel 4.9.337 (EOL on 2023-01-07) and regular kernels up through 4.12 or 4.13 (abandoned in 2017). Nvidia 96 and 173 FTB with 4.14 because a different function, spin_unlock_wait, disappeared.
When tested on an Athlon system where PAT was available, Nvidia 96.43.23 still used MTRR. This is baffling, since "Changed driver behavior such that PAT (Page Attribute Table) is used where possible instead of MTRRs" supposedly happened in 1.0-7167 (March 11, 2005).
When tested on a P3 system where PAT was disabled by the kernel, Nvidia
304.132 (unpatched) built for kernel 4.7.6 with the MTRR exports added back
still failed to use MTRR. To make it work, it was necessary to add the
module parameter nvidia.NVreg_UsePageAttributeTable=0.
Dmesg then showed:
[ 5.243598] NVRM: builtin PAT support disabled, falling back to MTRRs.
And /proc/mtrr then showed the write-combining entry added by Nvidia:
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back reg01: base=0x060000000 ( 1536MB), size= 256MB, count=1: write-combining
The 304 series apparently migrated to the new API before maintenance of the 304 series ended, making the kernel patch unnecessary.
2023-01-19: Phoronix: Kernel 6.3 to remove the following DRM drivers: i810, mga, r128, savage, sis, tdfx, and via.
2012-11: Nvidia dead-ended their 71.86 and 96.43 legacy drivers.
2014-03: Nvidia dead-ended their 173.14 legacy drivers.
2017-09: Nvidia dead-ended their 304 legacy drivers.
2017-12: Nvidia announced their intention to abandon all 32-bit drivers after release 390, with critical security fixes ending 2019-01. (Earlier it was said that the 340.* legacy releases would be supported through the end of 2019.)
2019-12: Nvidia dead-ended their 340 legacy drivers.
Here is the text of Support timeframes for Unix legacy GPU releases as of 2020-01-30:
The Linux 390.* legacy driver series is the last to support GF1xx ("Fermi") GPUs. Support for new Linux kernels and X servers, as well as fixes for critical bugs, will be included in 390.* legacy releases through the end of 2022.
The Linux 340.* legacy driver series is the last to support the G8x, G9x, and GT2xx GPUs, and motherboard chipsets based on them. Support for X.Org xserver version 1.20 was added to the 340.* legacy driver series with version 340.107, and support for Linux kernels up to Linux 5.4 was added with version 340.108. No further releases from the 340.* series are planned.
The Linux 304.* legacy driver series is the last to support the NV4x and G7x GPUs and motherboard chipsets based on them. Support for X.Org xserver version 1.19 was added to the 304.* legacy driver series with version 304.134, and support for Linux kernels up to Linux 4.13 was added with version 304.137. No further releases from the 304.* series are planned.
Support for X.Org xserver version 1.15 was added to the 173.14.* legacy driver series with version 173.14.39. No further releases from the 173.14.* series are planned.
Support for X.Org xserver version 1.12 was added to the 96.43.* legacy driver series with version 96.43.23. No further releases from the 96.43.* series are planned.
No further releases from the 71.86.* legacy driver series are planned.
For more information about the GPUs supported by each Legacy GPU driver series, please see: http://www.nvidia.com/object/IO_32667.html (redirected)
71.86 — before their time?
nvidia-96xx-dkms: Last maintenance 2017-10-16 for kernel 4.12.
nvidia-173xx-dkms: Last maintenance 2017-10-16 for kernel 4.12.
For 304,
Apart from this one message about 304xx-dkms being dropped in the 2017 repository cleanup I have not found a way to determine when packages were deleted from AUR. The last downloads I have of 96xx and 173xx are dated 2018-09-30; identical files were retrievable through https://aur.archlinux.org/cgit/aur.git/snapshot/... in 2023-01.
ATI's Linux drivers never did support Wonder, Mach or Rage series cards.
2006-08: According to Unofficial Wiki for the AMD Linux Driver, ATI/AMD dropped support for Radeons in the R100 to RS350 range in the 8.28.8 fglrx driver.
2009-04: Paraphrasing the Unofficial Wiki for the AMD Linux Driver: ATI/AMD dropped Catalyst support for [a buttload of Radeon and FireGL models] in Catalyst 9-4. These cards are supported with the legacy ATI 9-3 Catalyst release, but that was dead-ended and requires kernel ≤ 2.6.28 and X server ≤ 1.5 to work.
2000-03: XFree86 version 4.0 release notes:
Introduction: "This release isn't quite as complete as we would have liked. The main missing pieces are a nice configuration tool and support for some of the hardware that 3.3.x supports. The first point means that configuring the server might be more painful than usual. The second means that your hardware might not be supported by 4.0, or it might be supported at a lesser level (conversely, some hardware is better supported in 4.0)."
ATI driver status: "All chips supported in 3.3.6 are supported in 4.0 except for Mach8 and some old Mach32 chips. The support in 4.0 is, however, unaccelerated for all chips except the Rage 128."
For me, with a Mach64 card, XFree86 version 4.0 was just one big regression.
AFAIK, there was no 3D support prior to 4.0, only 2D acceleration for supported cards.
2012-06: X11R7.7 release notes:
2012-09: X server version 1.13 dropped XAA, thereby breaking 2D acceleration in any of the legacy drivers that had not yet been otherwise sabotaged. Maintained drivers have migrated to EXA, but EXA has been a huge performance regression (comparable to vesa) in every case that I've tested, leaving proprietary drivers and reverting to old X.Org versions as the only acceptable options.
2009-12: The DRI drivers s3v (S3 ViRGE) and trident were dropped from Mesa 7.7 without a mention in the release notes.
2012-02: Mesa 8.0 release notes:
"Removed all DRI drivers that did not support DRI2. Specifically, i810, mach64, mga, r128, savage, sis, tdfx, and unichrome were removed."
"Removed the classic Mesa r300 and r600 drivers, which are superseded by the gallium drivers for this hardware."
Gallium only works with DRI2.
Utah GLX was a 3D infrastructure developed for XFree86 3 that was eventually dead-ended by the adoption of DRI in XFree86 4. It included some level of 3D support for the following graphics chipsets:
A branch was created for XFree86 4, but the last status update in 2003 indicated that only the Nvidia and Matrox drivers were running Quake.
As of 2014-08, I have not tested Utah at all. The README files for the various chipsets are full of scary things. However, the ATI README offers some advice that may be useful whenever X complains of insufficient GPU memory: "You must disable font and pixmap caching for the X server, otherwise there won't be any memory for 3D windows."
Disabling pixmap caching: for XAA, put Option
"XaaNoPixmapCache" in section Screen. For EXA, ?
Disabling font caching: ?
Multiple version numbers separated by a slash indicate original release versus subsequent patches or alternatives that were made available during the original install.
| Slackware version | Release date | XFree86/X.Org version | X server version | Mesa version | Kernel version(s) |
|---|---|---|---|---|---|
| 7.1 | 2000-06 | 3.3.6 | X11R6.3 | 3.2 | 2.2.16 |
| 8.0 | 2001-07 | 4.1.0 | X11R6.5.1 | no? | 2.2.19/2.4.5 |
| ... | |||||
| 12.1 | 2008-05 | X11R7.3 | 1.4.0.90/1.4.2 | 7.0.2 | 2.6.24.5 |
| 12.2 | 2008-12 | X11R7.3 | 1.4.2 | 7.0.3 | 2.6.27 |
| 13.0 | 2009-08 | X11R7.4 | 1.6.3 | 7.5 | 2.6.29.6 |
| 13.1 | 2010-05 | X11R7.5 | 1.7.7 | 7.8.1 | 2.6.33.4 |
| 13.37 | 2011-04 | X11R7.6 | 1.9.5 | 7.9.2 | 2.6.37.6 |
| 14.0 | 2012-09 | X11R7.7 | 1.12.3/1.12.4 | 8.0.4 | 3.2.29/3.2.83 |
| 14.1 | 2013-11 | X11R7.7 | 1.14.3 | 9.1.7 | 3.10.17/3.10.104 |
| 14.2 | 2016-07 | X11R7.7 | 1.18.3 | 11.2.2 | 4.4.14/4.4.153 |
| 15.0 | 2022-02 | X11R7.7 | 1.20.14 | 21.3.5 | 5.15.19/5.15.94 |
2009-08: The X.Org fbdev driver quietly disappeared from Slackware
version 13.0. This seems to have been a Slackware move and I've been
unable to locate the explanation.
2012-09: fbdev returned, but it's in the 'extra' directory.
Last validation: 2014-03-23 with xz-5.0.5, gmp-5.1.3, mpfr-3.1.2, mpc-1.0.2, gcc-4.8.2, and nasm-2.11.02.
Patches and issues that are specific to Slackware 12.2 or Nvidia 71.86.15:
pcm.!default{
type hw
card 0
device 0
}
ctl.!default{
type hw
card 0
device 0
}
Section "Extensions" Option "Composite" "Disable" EndSection
#define __USE_ISOC99 in order to obtain
expected declarations from the header files in /usr/include.Dependency chains:
Reversion Kit 2 reverts the X server to version 1.12.4, which undeletes XAA and restores server compatibility with Nvidia 96.43.23. XAA enables the s3virge and sis X.Org drivers to have working 2D acceleration and XVideo but not DRI. For trident it is just a 2D speedup; XVideo is broken regardless.
2017-01: Nvidia + MTRR works with kernel 4.9.
-rw-r--r-- 1 dave users 543604 Jul 6 2012 pango-1.30.1-i486-1.txz -rw-r--r-- 1 dave users 42088 May 4 2012 xf86-input-evdev-2.7.0-i486-1.txz -rw-r--r-- 1 dave users 52720 May 22 2012 xf86-video-s3virge-1.10.5-i486-1.txz -rw-r--r-- 1 dave users 252552 May 4 2012 xf86-video-sis-0.10.4-i486-1.txz -rw-r--r-- 1 dave users 73308 May 4 2012 xf86-video-trident-1.3.5-i486-1.txz -rw-r--r-- 1 dave users 1907696 Oct 10 01:16 xorg-server-1.12.4-i486-2_slack14.0.txz
-rw-r--r-- 1 dave users 341480 Aug 23 14:49 libgcrypt-1.5.6-i486-1_slack14.1.txz
ln -s /usr/src/linux/include/generated/uapi/linux/version.h /usr/src/linux/include/linux/version.hReversion Kit 3 restores ABI and kernel compatibility with the Nvidia legacy driver version 173.14.39.
2023-03: Nvidia + MTRR works with kernel 4.9.337 (LTS, EOL on 2023-01-07). The available patches support kernels up to 4.12 and may suffice for 4.13, but those kernels were abandoned in 2017.
While the Nvidia 173 driver does not require SSE, several important packages in Slackware 15.0 use SSE despite nominally being for arch i586 or i686. To get GL working on an older CPU, you must build (or rebuild) the Nvidia driver after replacing the Mesa package with a non-SSE version.
42692 Oct 13 2013 xf86-input-evdev-2.8.2-i486-1.txz 1789512 Dec 15 2021 xorg-server-1.14.3-i486-7_slack14.1.txz
| Library | Dist | Package |
|---|---|---|
| /usr/lib/libnettle.so.4.7 | 14.1 | nettle-2.7.1-i486-1.txz |
| /usr/lib/libXfont.so.1.4.1 | 14.2 | libXfont-1.5.1-i486-2_slack14.2.txz |
| /lib/libudev.so.0.13.1 | 14.1 | udev-182-i486-7.txz |
| or | 14.2 | aaa_elflibs-14.2-i586-23.txz |
17 Jan 25 19:50 lib/libudev.so.0 -> libudev.so.0.13.1
57556 Sep 27 2013 lib/libudev.so.0.13.1
17 Jan 25 19:50 usr/lib/libXfont.so.1 -> libXfont.so.1.4.1
241900 Nov 29 2017 usr/lib/libXfont.so.1.4.1
16 Jan 27 16:12 usr/lib/libnettle.so.4 -> libnettle.so.4.7
199968 Aug 30 2013 usr/lib/libnettle.so.4.7
2016-10: Prior version used Slackware 14.2 and kernel 4.8. The process was similar but no action was required for libudev or libXfont.
Nvidia 304.137 still works with Slackware 14.2. The MTRR patch is not needed, but for kernels 4.15 and later the driver needs fix-for-4.15-timer-change (courtesy of kari-kivioja, 2018-02-23). FIXME: What about the 4.14 patch in nvidia-304xx-ck?
As described above, even on a system with no PAT
support, this driver may not fall back to MTRRs unless PAT is further
disabled with module parameter
nvidia.NVreg_UsePageAttributeTable=0.
The X server in Slackware 14.2 needs to be started with +iglx
to enable GL.
304.137 is reportedly broken by X server version 1.20.
Even Nvidia's currently maintained drivers constantly need random patches to make them compatible with the latest kernels.
The Nvidia installer or deinstaller may delete the libEGL.so or libvdpau.so that came from Slackware, breaking apps that depend on those libs.
Recent testing of Nvidia 96 and 173 in the midst of the MTRR fiasco was confounded by failures that were accompanied by syslog messages like this (Xids):
Aug 21 19:34:22 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0100 ffffffff 0000c1ac 01010200 00c3c3c3 Aug 21 19:41:02 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0400 00000000 000012cc 01f80004 00160005 Aug 21 19:41:03 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0400 00070395 0000fdd8 03990000 00c3c3c3 Aug 21 19:41:04 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0100 00000000 000035c4 00000000 00c3c3c3 Aug 21 19:41:04 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0400 00000000 00003c28 01f80004 00160005 Aug 21 19:41:08 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0400 00000000 00002fe0 01f80004 00160005 Aug 21 19:41:10 plague kernel: NVRM: Xid (0001:00): 6, PE0000 0400 0007056f 0000fdf8 05730000 00c3c3c3
Nvidia 173 seemed to stabilize after reverting to kernel 4.4. 96 OTOH gave me Xids when trying to use XVideo with both 4.4 and 4.7 kernels.
Relative to the proprietary drivers, Nouveau is a regression, but I can't say if Nouveau itself has had regressions because I never got it to do much successfully.
2012-10: Slackware 14.0 and kernel 3.6.2 with a GeForce 6800 Ultra Extreme: DOOM 3 fell on its face. Back to proprietary drivers.
2013-01: Slackware 14.0 with an AGP 2× Riva TNT 16 MiB: got segfaults trying to play video. Back to Windows XP.
2014-01: Slackware 14.1 and kernel 3.12.8 with an Asus GeForce2 MX400 32 MiB recently orphaned by the EOL of Nvidia's 96.43.23 fork: the Nouveau drivers appeared to start up normally with support for DRI2, EXA 2D acceleration, and XVideo, but EDuke32 and PrBoom-Plus both caused Nouveau to spew errors and die as soon as they started. Low-def videos played, but the video quality was unacceptable. Xterm visual bell (a simple 2D filling operation) managed not to crash the server but was excruciatingly, inexplicably slow. BSOD on exit. Aaaaaaaaaaaaaaaagggghh!
2014-03: Slackware 14.1 and kernel 3.13.5 with an AGP 2× Nvidia Riva TNT 16 MiB: Given previous results with the Radeon driver I tried different combinations of kernel modules, but this time there really was no way to get 2D acceleration to work. XAA is gone now, leaving only EXA which is super slow.
2016-09: I flipped the bozo bit on Nouveau in 2014 and since then have rarely bothered to test it, much less take careful notes of the outcome. Once in a while I will try it in the vain hope of avoiding the need for a reversion kit, but not once has it worked tolerably well with any Nvidia card, in any PC, with any version of kernel and X server.
2014-01: 2D acceleration broke somehow in the upgrade from Slackware 14.0 to 14.1 (x86_64). The performance of X11 (scrolling xterms) is now just as slow as with vesa.
Although Intel is to be commended for their commitment to open-source drivers, they always give me trouble.
There currently are four different options for 2D rendering: SNA, UXA, Glamor, and "none" (option "NoAccel").
2014-02: In Slackware 14.1, the X.Org trident driver crashes on launch and is completely unusable. It was working in 14.0.
[ 451.398] (II) LoadModule: "trident" [ 451.398] (II) Loading /usr/lib/xorg/modules/drivers/trident_drv.so [ 451.399] (EE) Failed to load /usr/lib/xorg/modules/drivers/trident_drv.so: /usr/lib/xorg/modules/drivers/trident_drv.so: undefined symbol: TRIDENT_Sync [ 451.399] (II) UnloadModule: "trident" [ 451.399] (II) Unloading trident [ 451.399] (EE) Failed to load module "trident" (loader failed, 7)
2016-07: In Slackware 14.2, the trident driver is usable again. It defaults to XAA which doesn't exist. Option "AccelMethod" "exa" starts successfully, but is much slower for scrolling text than no acceleration at all and causes the server to hang on exit. XVideo is always corrupted. Use Reversion Kit 2 to get XAA speedup.
2014-06, Slackware 14.1: The X.Org s3virge driver was screwed by the deletion of XAA in X server version 1.13.
[ 57.649] (II) Loading sub module "xaa" [ 57.649] (II) LoadModule: "xaa" [ 57.662] (WW) Warning, couldn't open module xaa [ 57.662] (II) UnloadModule: "xaa" [ 57.662] (II) Unloading xaa [ 57.662] (EE) S3VIRGE: Failed to load module "xaa" (module does not exist, 0) [ 57.663] (II) S3VIRGE(0): Falling back to shadowfb
The s3virge driver has no EXA support at all. As far as I can tell, the only 3D support for these S3 cards that ever existed in Linux was in Utah GLX. Mesa had a DRI driver called s3v_dri.so until it disappeared from version 7.7, but I have not located a matching DRM module in any version of the kernel. ???
Without the remedy of Reversion Kit 2, 2D scrolling is slow (although shadowfb is a lot better than nothing), XVideo is disabled, and the X server hangs on exit.
With or without Reversion Kit 2, 1600×1200 mode doesn't work at any bit depth on 4 MiB cards even though Windows 98 SE can manage it at 16 bpp. This has nothing to do with memory management; the error is "horizontal timing out of range." Looks like an old fault in the S3virge driver that will never be fixed.
The X.Org sis driver in Slackware 14.1 tries to use EXA but the server crashes immediately. sis has DRI support for the 300-series chipsets but not 315. Use Reversion Kit 2.
2014-03: Nouveau was hopeless. With Reversion Kit 1 (Nvidia proprietary drivers 71.86.15), everything worked as well as could be expected given the vintage of the card and the system under test (700 MHz Pentium 3 CPU):
This card gets along very well with a 440BX motherboard and DOS applications. Its analog output is as clear as it gets and switching VGA modes doesn't require recalibrating the monitor every time.
2015-10: With Reversion Kit 2, kernel 4.2.3 and Nvidia 96.43.23 drivers, it worked.
2015-10: With Reversion Kit 2 and kernel 4.2.3, Nvidia 96.43.23 didn't work right. The screen was all green. Messing with lots of options only managed to change it from green to red. Colors were normal in nv and nouveau.
173.14.39 bailed out immediately stating that 96.43.23 is the correct driver.
This anachronistic card rehashes a GeForce 2-derived chipset with AGP 8×, DVI, and S-video while dropping analog VGA.
2016-09, Slackware 14.2, kernel 4.7.4, Reversion Kit 2, Nvidia 96.43.23 with arch patches (MTRR disabled), tested on 440BX PC:
2017-01, kernel 4.9.2, Reversion Kit 2 with MTRR enabled, on KT133A PC: same thing, same Xids, just slightly better performance.
2016-08, Slackware 14.2, testing on the QDI P2DI-AL/C motherboard: So, running Nvidia drivers with GeForce 6-series used to be so easy that it wasn't worth writing them up, but recently I had a bunch of problems with both 304.131 and 173.14.39. This needs retesting to sort it all out. They might just hate this motherboard, or maybe the kernel went through a bad time. The working configuration that I landed on was RK3 with longterm kernel 4.4.19.
As for other drivers: Nouveau caused a hard lockup that prevented the kernel from booting (same 'ol Nouveau). fbdev refused to do 1600×1200. nv and vesa were willing to try if Option "FlatPanel" "false" was set, but it still didn't work (X server chose the correct mode and refresh rate but monitor still reported signal out of range). nv didn't even work in 1024×768.
2023-02, Slackware 15.0 with RK3 refresh and SSE removal, testing with Athlon T-Bird CPU on KT133A chipset:
[vo/gpu/opengl] GLX does not support GLX_ARB_create_context_profile [vo/gpu] Failed initializing any suitable GPU context! Error opening/initializing the selected video_out (--vo) device. Video: no video
ERR| Unable to set video mode: SDL_GL_CreateContext failed: Could not create GL context. ERR| Video driver does not support OpenGL version 2 or greater; all OpenGL modes are unavailable.Then fails ugly because of a regression that prevents it from falling back to software rendering.
2016-09, Slackware 14.2, kernel 4.7.6 with MTRR export patch, Nvidia drivers 304.132 with NO patches, testing on a 440BX P3 system:
pci=realloc because the BIOS
would not alloc 512 MiB video memory.nvidia.NVreg_UsePageAttributeTable=0
to really enable MTRR.+iglx to enable GL.2018-09, Slackware 14.2, kernel 4.18.7, Nvidia drivers 304.137 with patch for timer changes in kernel 4.15, same hardware, same parameters, updated apps:
libEGL warning: DRI2: failed to authenticate [vo/gpu/opengl] Suspected software renderer or indirect context. [vo/gpu/opengl] before video texture creation: OpenGL error INVALID_ENUM. [vo/gpu/opengl] after rendering: OpenGL error INVALID_ENUM.
As of 2013-08-29, kernel 3.10.10, Slackware 14.0: It's impossible to get 2D and 3D acceleration working at the same time. All permutations of drivers have a problem with the screen going black (no signal) until the next reboot about 50% of the time when modesetting occurs.
With option 2 (DRI2), background or sky textures are missing in EDuke32 and there is flakiness in PrBoom-Plus. Reverting Mesa to 7.11.2 with DRI drivers only or setting Option "DRI2" "false" in xorg.conf makes no difference.
2014-09-02, kernel 3.16.1, Slackware 14.1: The modesetting BSOD problem is still there and I can't stand it for long enough to test anything else.
2013-09-28: Per the Wiki, Catalyst 9-3 needs kernel ≤ 2.6.28 and X server ≤ 1.5.
Just downgrading the kernel and X server is a nonstarter. Kernel 2.6.28.10 is not usable under Slackware 14.0. Too many things quit with "kernel too old" errors. So it's back to Slackware 12.2.
Building kernel 2.6.28.10 under Slackware 14.0 with GCC 4.8.1 requires at least four files to be patched. It's better to bootstrap Slackware 12.2 with a generic kernel and then build the old kernel with the old tools.
The following kernel configs were necessary for Catalyst to install and work correctly: CONFIG_X86_LOCAL_APIC=y, CONFIG_X86_IO_APIC=y, CONFIG_PCI_MSI=y, CONFIG_AGP=y, CONFIG_DRM=n. (The first two are prerequisites for CONFIG_PCI_MSI to become available.)
ati-driver-installer-9-3-x86.x86_64.run can be run from a text console just like the Nvidia drivers. ATI's installation process isn't much different from Nvidia's except that the ATI installer will modify /etc/X11/xorg.conf without even asking. Back it up!
There was a stubborn problem with startx crashing on launch regardless what was in xorg.conf. The point of commonality in all of the stack dumps was libvbe.so(VBEExtendedInit+0x8f). Deleting /usr/lib/xorg/modules/libvbe.so worked around the problem with no obvious collateral damage.
With the Catalyst driver successfully installed, every problem experienced with the Gallium driver went away. However, now the screen is left in a trashed state when X exits.
PrBoom-Plus played flawlessly on the first try. EDuke32 was pretty discouragingly messed up at first, but it was a matter of bad defaults:
XVideo (xv) worked fine once the conflicting OpenGL overlay was turned off (a well-known quirk of fglrx), but this was confounded by an unrelated problem: the old GCC included with Slackware 12.2 produced broken code for ffmpeg 2.0.1 with the effect that every video seemed corrupted. That problem went away after rebuilding ffmpeg with GCC 4.8.1. The new compiler produced a new build error in libavdevice/xv.c, which was fixed by reversing the order of the XShm.h and Xvlib.h includes.
In summary, it is a massive pain to revert to Slackware 12.2, but the Gallium driver is still outclassed by the legacy proprietary driver.
2013-09: Slackware 14.0, X.Org module mach64, kernel 3.11: As it was, 1600×1200 @ 16 bpp worked with XAA 2D acceleration, but 3D did not work at any resolution because neither the DRM kernel module nor the Mesa DRI driver was present.
The missing DRM kernel module is out-of-tree (mach64drm). ArchLinux says it was never stable. Version mach64-20130130 builds OK with kernel 3.11.
Installing the binary package mach64-dri (version tested was 7.11.2-5-i686) from ArchLinux without reverting Mesa does not work. DRI gets enabled but Gallium won't use it. Reverting Mesa to the Slackware 13.37 package, leaving everything else from Slackware 14.0, does work. However, because of memory constraints, the usable resolution with 3D enabled is limited to 800×600 @ 16 bpp. (1282 kB of video RAM is allocated for XAA alone.)
The drivers are stable enough for eduke32 to run, but it locks up immediately if the framerate counter is enabled. PrBoom-Plus crashes immediately with various different errors as soon as OpenGL is enabled. Building MesaLib-7.11.2 from source and recompiling all applications did not change anything.
2014-01: Slackware 14.1, X.Org module mach64, kernel 3.12.6: 1600×1200 @ 24 bpp was corrupted. Both 1600×1200 @ 16 bpp and 800×600 @ 24 bpp worked with EXA 2D acceleration, but as expected, there was no DRI/DRI2 support. Playing video gave a black screen.
[ 74.082] (WW) MACH64(0): Direct rendering is not supported for ATI chips earlier than the ATI 3D Rage Pro.
Although the Rage IIC has some kind of hardware 3D, it's not supported by the Mach64 module of X.Org. This is not a regression; it never worked. Too bad xv doesn't work either.
Way back when, I bought this rather pricey Mach64 card specifically because it had a working Linux driver. XFree86 3.x gave me 32 bpp accelerated. Then came XFree86 version 4.
At last check, 2008-06-08: With the X.Org version included in Slackware 12, the only thing that worked correctly for the Mach64 card was the unaccelerated and intolerably slow generic VESA driver. This needs a revisit since it ought to work as well as the Rage.
2012-09: X.Org trident driver in pre-14.0 Slackware-current was broken for 24 bpp (unable to display an uncorrupted desktop). In addition, the desktop corrupts on powersave. 16 bpp needs further testing.
2014-05: In Slackware 14.1 the X.Org trident driver
is unusable. With the X.Org vesa driver, 800×600
at 24 bpp works as long as xorg.conf includes
DefaultFbBpp 24 to override the default of 32.
1024×768 fails with the monitor reporting an out of range signal
regardless what vertical refresh is specified in xorg.conf; the log reports
"VBESetVBEMode failed, mode set without customized refresh" for every
mode. The video BIOS lists resolutions up to 1280×1024 16 bpp,
but the modules tridentfb and vesafb in kernel 3.14.4 are inexplicably unable
to use any mode except 640×480 8 bpp.
2012-09: XVideo was broken in the X.Org trident driver in pre-14.0 Slackware-current.
2016-07: Slackware 14.2: XVideo is still broken the same way. 1152×864 24 bpp is usable without acceleration. By default it tries to use XAA. EXA can be enabled but it is much slower for scrolling text than no acceleration at all and causes the server to hang on exit. Install Reversion Kit 2 and get 1152×864 24 bpp with XAA acceleration.
The man page for trident (versioned xf86-video-trident 1.3.6) says:
SUPPORTED HARDWARE
| ... | ||
| ISA/VLBus | 8900C, 8900D, 9000, 9200CXr, Cyber9320, 9400CXi, 9440AGi | |
| These cards have been ported but need further testing and may not work. |
Guess what? It doesn't work.
2008-10, Slackware 12.1, kernel 2.6.27: The trident driver didn't detect the card. The generic vesa driver worked and fired up a 1024×768×8bpp interlaced mode. VGA bandwidth as judged by scrolling text in xterms was surprisingly good for an unaccelerated driver.
2014-02, Slackware 14.1, kernel 3.13.2: Complete and utter failure. The trident driver did a faceplant:
[ 554.592] (II) LoadModule: "trident" [ 554.791] (II) Loading /usr/lib/xorg/modules/drivers/trident_drv.so [ 554.923] (EE) Failed to load /usr/lib/xorg/modules/drivers/trident_drv.so: /usr/lib/xorg/modules/drivers/trident_drv.so: undefined symbol: TRIDENT_Sync [ 554.926] (II) UnloadModule: "trident" [ 554.930] (II) Unloading trident [ 554.933] (EE) Failed to load module "trident" (loader failed, 7)
And even the vesa driver failed to detect the card:
[ 1209.209] (II) VESA: driver for VESA chipsets: vesa [ 1209.216] (--) using VT number 7 [ 1209.331] (WW) Falling back to old probe method for vesa [ 1209.336] (EE) No devices detected. [ 1209.348] (EE) Fatal server error: [ 1209.355] (EE) no screens found(EE)
TO DO: Diff old and new vesa driver, find out how they broke it and patch it. It's a really simple driver. The following might be useful too: tinyx, "We resurrected Xvesa from the depths of git history, and intend to maintain it with Xfbdev."
2014-02: Slackware 14.1, kernel 3.13.4: This card uses the s3virge X.Org driver, which was screwed by the deletion of XAA in X server version 1.13. After installing Reversion Kit 2 it's possible to use 1024×768 24 bpp mode with 2D acceleration. 1600×1200 mode doesn't work at any bit depth. XVideo claims to be enabled (xvinfo: Adaptor #0: "S3 ViRGE Backend Scaler") but the video is corrupted and too slow regardless. (As usual, it could be that the PC is just too slow.)
There was a DRI driver s3v_dri.so which disappeared in Mesa 7.7 (between Slackware versions 13.0 and 13.1), but reverting to mesa-7.5-i486-2.txz from Slackware 13.0 sans any matching kernel module did nothing.
2014-06: Slackware 14.1, kernel 3.15: The behavior of this card was the
same as that of the Trio3D card above except
that Option "NoDDC" was needed in the Device section of
xorg.conf to stop it from hanging for 1 minute each time X was started.
Retesting XVideo with an mp4 scaled down small enough not to tax the CPU, it was demonstrated that XVideo does in fact work, but the scaler is of very poor quality. Scaled-up videos are as jaggy as possible; there's no hint of interpolation or smoothing.
2014-07: Slackware 14.1 + Reversion Kit 2, kernel 3.15.6: OK, this actually is worse. XVideo definitely does not work:
[ 44.718] (==) S3VIRGE(0): XVideo not supported. [ 45.805] (II) AIGLX: Screen 0 is not DRI2 capable [ 45.805] (II) AIGLX: Screen 0 is not DRI capable
DDC works without a hang.
Wikipedia says "UniChrome is an updated S3 ProSavage used in VIA's integrated graphics chipsets," so like Wikipedia I am filing this under S3.
2015-02: Slackware 14.1, kernel 3.18.6: Using the openchrome driver for X.Org, 1600×1200 24 bpp mode fires up with EXA 2D acceleration. There are some errors in the log but otherwise it seems to be good.
XVideo is enabled, as is the XvMC extension that provides MPEG-2 acceleration, but as soon as I try to use it, ffplay spews the following and dies:
X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 148 (XVideo) Minor opcode of failed request: 19 () Serial number of failed request: 26 Current serial number in output stream: 27
As for 3D, the kernel's DRM_VIA module is still there and the X server enables DRI, but the Mesa crew dropped the unichrome driver in 8.0. Reverting to mesa-7.9.2-i486-1.txz from Slackware 13.37, the Mesa module loads, but then this happens:
[ 4438.737] (EE) AIGLX error: Calling driver entry point failed [ 4438.738] (EE) AIGLX: reverting to software rendering
This seems to be one of those unhelpful, nonspecific errors. After also reverting to xorg-server-1.9.5-i486-3_slack13.37.txz, xf86-input-evdev-2.6.0-i486-1.txz and xf86-video-openchrome-0.2.904-i486-2.txz from Slackware 13.37, XAA 2D is faster than EXA was and 3D now seems to be enabled, but nothing OpenGL actually works. Either the log fills with nasty errors and the application fails in some horrible way or the application just hangs with a black screen. The BadAccess failure was unaffected by the reversions.
2013-10: Slackware 14.0, kernel 3.11.4: The kernel module DRM_TDFX is still there, in tree and working, but to get the corresponding DRI module, Mesa must be rolled back to version 7.
With Mesa reverted and driver "tdfx" specified in xorg.conf, 2D acceleration works fine for 1600×1200 at either 16 or 24 bpp, but the DRI driver works only at 16 bpp. It's a moot point, though, because every single GL program either quits with "insufficient resources for operation" or dies with a segfault. It makes no difference whether I use the Slackware 13.37 package or my own build of Mesa 7.11.2.
Xvideo is enabled (xvinfo says "3dfx Video Overlay"), but the pre-AGP system used for testing is apparently too slow to play video regardless.
2014-08, Slackware 14.1: Without Reversion Kit 2, the X.Org sis driver tries to use EXA but the server immediately segfaults and dies. Adding Option "NoAccel" "1" avoids the crash but then performance sucks.
With the reversion kit, XAA 2D acceleration and XVideo ("SIS 300/315/330 series Video Overlay") both work and perform well. The removal of the DRI driver from Mesa 8 is moot because sis never supported DRI on this chipset.
With or without the reversion kit, X always leaves the graphics in a trashed state when it exits.
Intel Core i5 661 ("1st generation Core" with Ironlake GPU)
OpenGL renderer: HD Graphics (ILK)
OpenGL version: 2.1
VAAPI decoders: MPEG2, H264
x86_64:
2012-08, Slackware 13.37: Segfault in /usr/lib64/libdrm_intel.so.1 every time on launch of PrBoom-Plus.
2012-10: Slackware 14.0, kernel 3.6.2, CONFIG_DRM_I915=y, CONFIG_DRM_I915_KMS=y: DOOM 3 runs for a little while but then locks up the GPU.
2013-12: Slackware 14.0, kernel 3.12.5: PrBoom-Plus is OK now. DOOM 3 TBD, audio is cutting out.
2014-01: Slackware 14.1, kernel 3.12.5: To avoid getting a black screen in EDuke32, settings.cfg needs r_texcompr "0".
2015-01: I was forced to disable the HD Graphics on this PC and install an Nvidia card because of code rot affecting Intel's Windows 7 drivers. A few months ago they started crashing to a black screen and restarting in an infinite loop, presumably as a result of incompatibility with some routine Windows update, and nothing since then has mitigated the problem. AFAICT Intel has stopped maintenance for this configuration and it will never be fixed.
Later that year: The Nvidia card died. I worked around the Windows driver problem by switching from HDMI to DVI.
2023-02: Slackware 15.0, kernel 6.1.5, Wayland: apps using GL are hit and miss.
[vo/gpu] Disabling scaler #0 spline36 (GLSL version too old). [vo/gpu] Disabling scaler #1 mitchell (GLSL version too old). [vo/gpu] Disabling scaler #2 spline36 (GLSL version too old). [vo/gpu] Disabling scaler #3 mitchell (GLSL version too old). [vo/gpu] Disabling linear/sigmoid scaling (GLSL version too old). [vo/gpu] Disabling debanding (GLSL version too old). [vo/gpu] correct-downscaling requires non-bilinear scaler. [ffmpeg] AVHWFramesContext: Failed to create surface: 14 (the requested RT Format is not supported). [ffmpeg] AVHWFramesContext: Unable to allocate a surface from internal buffer pool.
ERR| Unable to set video mode: SDL_GL_CreateContext failed: Could not create GL context: GLXBadFBConfig. ERR| Video driver does not support OpenGL version 2 or greater; all OpenGL modes are unavailable.Then fails ugly because of a regression that prevents it from falling back to software rendering.
2014-01: Slackware 14.1, kernel 3.12.6, EDuke32 rev. 4262: EDuke32 works only with the software renderer. If OpenGL is enabled, settings.cfg needs r_texcompr "0" to avoid getting a black screen and then it crashes during texture loading.
2014-04: Slackware 14.1, kernel 3.14, EDuke32 rev. 4418: EDuke32 OpenGL works again with r_texcompr "0". r_texcompr "1" still causes a black screen.
I am still getting the following log spew every time I run DOSBox:
Apr 6 17:28:42 EeePC kernel: [drm:intel_pipe_config_compare] *ERROR* mismatch in gmch_pfit.lvds_border_bits (expected 32768, found 0) Apr 6 17:28:42 EeePC kernel: ------------[ cut here ]------------ Apr 6 17:28:42 EeePC kernel: WARNING: CPU: 1 PID: 21281 at drivers/gpu/drm/i915/intel_display.c:9530 check_crtc_state+0x6b8/0xdd0() Apr 6 17:28:42 EeePC kernel: pipe state doesn't match! Apr 6 17:28:42 EeePC kernel: Modules linked in: snd_seq snd_seq_device snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore Apr 6 17:28:42 EeePC kernel: CPU: 1 PID: 21281 Comm: X Not tainted 3.14.0-EeePC #1 Apr 6 17:28:42 EeePC kernel: Hardware name: ASUSTeK Computer INC. 1000/1000, BIOS 1003 06/11/2009 Apr 6 17:28:42 EeePC kernel: 0000253a c14fdcde f0e63aa8 c1037aca c16168af f0e63ac0 00005321 c15f02f4 Apr 6 17:28:42 EeePC kernel: 0000253a c12be6b8 c12be6b8 f6014000 f6014648 00000003 f62709b4 c1037b14 Apr 6 17:28:42 EeePC kernel: 00000009 f0e63aa8 c16168af f0e63ac0 c12be6b8 c15f02f4 0000253a c16168af Apr 6 17:28:42 EeePC kernel: Call Trace: Apr 6 17:28:42 EeePC kernel: [<c14fdcde>] ? dump_stack+0x3e/0x4e Apr 6 17:28:42 EeePC kernel: [<c1037aca>] ? warn_slowpath_common+0x7a/0x90 Apr 6 17:28:42 EeePC kernel: [<c12be6b8>] ? check_crtc_state+0x6b8/0xdd0 Apr 6 17:28:42 EeePC kernel: [<c12be6b8>] ? check_crtc_state+0x6b8/0xdd0 Apr 6 17:28:42 EeePC kernel: [<c1037b14>] ? warn_slowpath_fmt+0x34/0x40 Apr 6 17:28:42 EeePC kernel: [<c12be6b8>] ? check_crtc_state+0x6b8/0xdd0 Apr 6 17:28:42 EeePC kernel: [<c12ca9fe>] ? intel_modeset_check_state+0x28e/0x790 Apr 6 17:28:42 EeePC kernel: [<c12caf8b>] ? intel_set_mode+0x2b/0x40 Apr 6 17:28:42 EeePC kernel: [<c12cb800>] ? intel_crtc_set_config+0x770/0x950 Apr 6 17:28:42 EeePC kernel: [<c128db77>] ? drm_mode_set_config_internal+0x47/0xc0 Apr 6 17:28:42 EeePC kernel: [<c1290698>] ? drm_mode_setcrtc+0xe8/0x5a0 Apr 6 17:28:42 EeePC kernel: [<c12905b0>] ? drm_mode_setplane+0x3e0/0x3e0 Apr 6 17:28:42 EeePC kernel: [<c1283d9e>] ? drm_ioctl+0x3be/0x440 Apr 6 17:28:42 EeePC kernel: [<c12905b0>] ? drm_mode_setplane+0x3e0/0x3e0 Apr 6 17:28:42 EeePC kernel: [<c10c91dc>] ? do_sync_write+0x5c/0x90 Apr 6 17:28:42 EeePC kernel: [<c12839e0>] ? drm_free_buffer+0x30/0x30 Apr 6 17:28:42 EeePC kernel: [<c10d8527>] ? do_vfs_ioctl+0x317/0x510 Apr 6 17:28:42 EeePC kernel: [<c104077b>] ? recalc_sigpending+0xb/0x20 Apr 6 17:28:42 EeePC kernel: [<c10411aa>] ? __set_task_blocked+0x2a/0x70 Apr 6 17:28:42 EeePC kernel: [<c10cb26a>] ? __sb_end_write+0x2a/0x60 Apr 6 17:28:42 EeePC kernel: [<c1042e74>] ? __set_current_blocked+0x24/0x40 Apr 6 17:28:42 EeePC kernel: [<c1042fcf>] ? sigprocmask+0x5f/0xa0 Apr 6 17:28:42 EeePC kernel: [<c10d875d>] ? SyS_ioctl+0x3d/0x70 Apr 6 17:28:42 EeePC kernel: [<c150364f>] ? syscall_call+0x7/0xb Apr 6 17:28:42 EeePC kernel: ---[ end trace 3798c13c21cf8e7e ]---
2014-10, Slackware 14.1, kernel 3.17.1, X.Org intel driver: Experience very similar to GMA 950. The kernel spews errors into the logs constantly. EDuke32 needs r_texcompr "0" to avoid a black screen of death but then fails with an out of memory condition while loading textures. PrBoom-Plus runs but the frame rate at 1600×1200 is too low. XVideo works on 854×480 videos but does not support 1280×720 or 1920×1080. 2D performance with UXA is good.
Intel Pentium J2900
HD Graphics for Atom Z3700 Series (et al.) - Bay Trail, Gen7
OpenGL renderer: HD Graphics (BYT)
OpenGL version: 4.2
VAAPI decoders: MPEG2, H264, VC1, JPEG/MJPEG
2015-03, x86_64, Slackware 14.1, kernel 3.18.8, X.Org intel driver: This time it's 2D or XVideo that's giving me trouble since the whole point of the box was streaming video.
I am focusing on Chrome as the video player. Chrome's ignore-gpu-blacklist flag triggers the following diagnostic, which might indicate that it is doing nothing useful at all:
[1468:1468:0314/200542:ERROR:gpu_video_decode_accelerator.cc(272)] Not implemented reached in void content::GpuVideoDecodeAccelerator::Initialize(const media::VideoCodecProfile, IPC::Message *)HW video decode acceleration not available.
Support for VAAPI appears to be lacking across the board.
| Kernel parameters | xorg.conf | Chrome flags | Result |
|---|---|---|---|
| None | Defaults (UXA) | Defaults (GPU blacklist enabled) | Tearing and random hard lockups |
| None | Option "AccelMethod" "sna" Option "TearFree" "true" |
ignore-gpu-blacklist | Random hard lockups |
| None | Option "AccelMethod" "sna" Option "TearFree" "true" |
Defaults (GPU blacklist enabled) | Random hard lockups |
| i915.semaphores=1 | Option "AccelMethod" "sna" Option "TearFree" "true" |
ignore-gpu-blacklist | Random hard lockups |
| i915.semaphores=1 | Option "AccelMethod" "sna" Option "TearFree" "true" |
Defaults (GPU blacklist enabled) | Random hard lockups |
| i915.semaphores=0 | Option "AccelMethod" "sna" Option "TearFree" "true" |
ignore-gpu-blacklist | Random hard lockups |
| i915.semaphores=0 | Option "AccelMethod" "sna" Option "TearFree" "true" |
Defaults (GPU blacklist enabled) | Random hard lockups |
| None | Option "AccelMethod" "glamor" | Defaults (GPU blacklist enabled) | Random hard lockups Unclear if option had any effect |
| None | Option "NoAccel" "true" | Defaults (GPU blacklist enabled) | Jaggy scaling and tearing, but no lockups |
So everything except the dumbest, dumbed-down, un-accelerated dumb mode is broken. Sigh. To be completely fair, this is new hardware versus a Slackware release that is due for an update, so it should be categorized as code rot rather than regression, but I was not expecting video to still be a problem for anything in the HD Graphics series.
The suggestion to try i915.semaphores came from here. I did not test SNA without TearFree.
3D got only cursory testing, not enough to discover random lockups. FWIW, EDuke32 still needs r_texcompr "0" but there were no other immediate 3D failures.
2023-02: Ubuntu 22.10, Wayland: VAAPI decoding is working, but to stream 1920x1080 30 fps without dropping frames I need to remove profile=gpu-hq from mpv.conf and use the default.
Reversion kits needed (based on troubleshooting already done):
To be tested:
To be retested: