// TOM'S HARDWARE US — HARDWARE & GADGET
25 years after the death of 3dfx, the Voodoo 3 gets a Linux driver update — classic Voodoo GPUs can now boot without a PC BIOS
It's been a quarter-century since the firm folded, but the graphics chips still have utility in esoteric use cases.
When you purchase through links on our site, we may earn an affiliate commission. Here’s how it works.
Linux kernel 7.3 is set to bring an oddly nostalgic update for 3dfx's Voodoo 3, one of the most recognizable graphics cards of the late 1990s. Don't get too excited; the venerable PCI-and-AGP accelerator isn't suddenly getting a modern Linux graphics stack, but the kernel's existing tdfxfb framebuffer driver is being updated so that it can initialize a Voodoo 3 itself rather than relying on the system firmware to have already run the card's video BIOS. It's a small change with a surprisingly specific purpose, and one that illustrates why ancient hardware occasionally gets attention in contemporary Linux.
The problem is that the tdfxfb driver historically assumed that the Voodoo card had already been initialized by the PC's firmware. That's because, at the time it was written, that was a reasonable assumption on a conventional x86 PC. The system firmware would execute the card's video BIOS during boot, configure the hardware, and then hand Linux something that is already capable of displaying an image. That assumption breaks down on newer and unusual platforms where the firmware cannot or does not execute the VGABIOS. The creator's patch description specifically calls out non-x86 computers, systems where another graphics card is primary, and newer BIOSes that can't run the old video BIOS.
The developer behind the patches, Daniel Palmer, was using a Voodoo 3 in an Amiga 4000 equipped with a PCI bridge when the problem cropped up. Linux could detect the card, but the Voodoo was still completely uninitialized, leaving him staring at "no signal detected." The new code uses configuration information from the card's own video BIOS to perform the initialization from Linux instead, allowing the driver to bring the VGA core up and establish a working display without depending on the system firmware. For now, the new manual initialization code is specifically aimed at the Voodoo 3; he had initially noted support for the VSA-100-based Voodoo 4 and 5 cards, but their BIOS layouts are different, so that support was removed from the current patch series. The code has been tested on both a modern x86-64 system and an Amiga 4000 with a Mediator PCI bridge.
On a conventional modern-ish x86-64 PC with a Voodoo 3 installed, the practical result is fairly modest. Load tdfxfb and you can get a working Linux framebuffer device, typically exposed as /dev/fb0, with the Voodoo driving a display that can host the Linux virtual console. In other words, this is enough to turn the Voodoo from "a PCI device that Linux can identify" into an actual display adapter capable of putting pixels on the screen even when firmware didn't initialize it first. Applications that know how to use the Linux framebuffer interface can also draw to it, just as they could with other old framebuffer devices.
The thing is, that's also where the limits of this work become apparent. Linux fbdev is a legacy graphics interface and has long been superseded by Linux's DRM/KMS graphics infrastructure, so this ain't a resurrection of the Voodoo 3 as a contemporary Linux GPU. Loading tdfxfb does not give you a Mesa stack, modern OpenGL, Wayland acceleration, or the sort of 3D functionality you would expect. It is essentially a very old-fashioned "squirt pixels at the display" arrangement, but that's useful enough for a Linux console, embedded-style framebuffer applications, and, apparently, people putting exotic PCI graphics cards into even more exotic old computers, but it's not exactly a compelling reason to install a Voodoo 3 in a modern desktop.
The more interesting part is that Palmer is working on a separate 3D path for the Voodoo 3, and that effort is already much further along than the framebuffer work alone might suggest. The experimental interface exposes t