Voodoo3 Gets New Linux Driver Support and Experimental 3D

Voodoo3 Gets New Linux Driver Support and Experimental 3D

More than two decades after 3dfx disappeared from the PC graphics market, the company’s Voodoo3 hardware is receiving new Linux driver development.

The upcoming Linux 7.3 kernel improves the legacy tdfxfb framebuffer driver by allowing it to initialize a Voodoo3 directly, without depending on the system firmware to execute the card’s Video BIOS. At the same time, an experimental user-space 3D stack is being developed that can directly control the Voodoo3’s 3D hardware and has already demonstrated the ability to run Quake.

The work is primarily interesting for retro-computing, hardware experimentation, and virtualization rather than modern desktop graphics. Nevertheless, it demonstrates that even a 1990s-era accelerator can still be brought back to life through modern Linux driver infrastructure.

🖥️ Voodoo3 Gains Standalone Initialization in Linux 7.3

#

The upcoming Linux 7.3 kernel updates the tdfxfb framebuffer driver so that it can independently initialize a Voodoo3 graphics card.

The original driver expected system firmware to initialize the GPU first by executing the card’s Video BIOS. That assumption creates problems on systems where firmware cannot or does not initialize the Voodoo3.

Examples include:

• Non-x86 platforms without compatible PC Video BIOS execution.
• Systems where another graphics adapter is selected as the primary display device.
• Modern firmware environments that do not support legacy Video BIOS execution.
• Retro systems using PCI bridges or non-standard hardware configurations.

The new initialization path moves this responsibility into the Linux driver, allowing the operating system to configure the Voodoo3 directly.

The Amiga 4000 Connection

#

The work was motivated in part by development involving an Amiga 4000 equipped with a Mediator PCI bridge.

Developer Daniel Palmer encountered problems getting the Voodoo3 initialized because the hardware could not rely on the traditional PC firmware initialization sequence.

The resulting patch has been tested on both x86-64 systems and an Amiga 4000 using a Mediator PCI bridge, demonstrating that the driver is not limited to conventional PC firmware environments.

Current Hardware Scope

#

The current patch focuses specifically on the Voodoo3.

Support for Voodoo4 and Voodoo5 was initially considered but was removed from the current implementation because their BIOS layouts differ from the Voodoo3.

This keeps the initialization work narrowly scoped and avoids treating the later Voodoo generations as if they were identical hardware.

🖥️ tdfxfb Remains a Framebuffer Driver

#

The improved initialization capability should not be confused with a complete modern 3D graphics stack.

Once loaded, tdfxfb can provide the Linux framebuffer device:

/dev/fb0

This enables functionality such as:

• Linux virtual-console output.
• Basic framebuffer graphics.
• Applications using the Linux framebuffer interface.
• Direct rendering through legacy framebuffer-oriented applications.

However, fbdev is a legacy graphics interface. Modern Linux graphics generally relies on the DRM/KMS architecture rather than the older framebuffer subsystem.

Consequently, the new tdfxfb support does not provide:

• Modern Mesa integration.
• Contemporary OpenGL support.
• Wayland compositor acceleration.
• A modern DRM/KMS-based Voodoo3 graphics stack.
• General-purpose acceleration for current desktop environments.

The practical result is that the Voodoo3 can become a functional Linux framebuffer device without becoming a modern desktop GPU.

🧪 An Experimental 3D Driver Is Being Developed

#

A separate development effort is targeting the Voodoo3’s 3D hardware directly.

Instead of integrating the accelerator into a conventional Mesa or DRM graphics stack, the experimental approach exposes the card’s register space to user space through a dedicated miscellaneous device:

/dev/tdfx3d

Applications can then interact with the Voodoo3 hardware through this interface.

This architecture is intentionally lightweight and experimental. It avoids requiring the full X11, Mesa, or Glide software stack.

smoltdfx and smolminigl

#

The experimental software stack includes two important components:

• smoltdfx — a user-space library for controlling the Voodoo3 hardware.
• smolminigl — a lightweight OpenGL 1.x implementation targeting the Voodoo3.

The combination provides a minimal path from an application to the graphics hardware:

Application
    |
    v
smolminigl
    |
    v
smoltdfx
    |
    v
/dev/tdfx3d
    |
    v
Voodoo3 hardware

This is fundamentally different from trying to recreate a complete modern Linux GPU driver stack.

The goal is instead to provide enough functionality to exercise the original 3D accelerator directly.

🎮 The Experimental Stack Can Run Quake

#

The 3D implementation has already been tested against physical Voodoo3 hardware and is capable of running Quake.

That is an important milestone because it demonstrates that the experimental driver path is not limited to register-level experimentation or static hardware detection. It can execute a real 3D workload on the original accelerator.

Performance remains modest, however.

The Voodoo3’s multi-texturing capabilities also require additional optimization, so the current implementation should be regarded as an experimental software stack rather than a production-quality graphics driver.

Why Quake Is a Useful Test

#

Quake is particularly relevant for this hardware because the original Voodoo generation was designed around the era of early hardware-accelerated 3D games.

Running it provides a practical validation target for several parts of the stack:

OpenGL API
    |
    v
3D rendering library
    |
    v
Voodoo3 command/register interface
    |
    v
Texture and rasterization hardware
    |
    v
Framebuffer

Successful execution therefore demonstrates significantly more than simply displaying pixels through /dev/fb0.

🔬 QEMU Provides an Additional Debugging Tool

#

Developers have also created a QEMU-based Voodoo3 emulator.

Hardware emulation provides a useful comparison point when developing a low-level graphics implementation:

Application
     |
     +--------------------+
     |                    |
     v                    v
Real Voodoo3          QEMU Voodoo3
     |                    |
     v                    v
Physical hardware     Emulated hardware
     |                    |
     +---------+----------+
               |
               v
       Rendering comparison

Comparing rendering behavior between emulated and physical hardware can help identify incorrect register programming, rendering differences, and hardware-specific behavior.

For a reverse-engineering-oriented project, this can substantially simplify debugging because software behavior can be observed in a more controlled environment.

🧩 Why This Matters for Retro Computing

#

The most interesting aspect of the project is not that a Voodoo3 can display a Linux console. The more significant development is the creation of a modern software path capable of initializing and directly driving decades-old 3D hardware.

Several characteristics make the work useful for retro-computing projects:

• It reduces dependence on legacy PC firmware.
• It enables Voodoo3 initialization on unusual platforms.
• It provides a lightweight experimental 3D interface.
• It creates a path for running legacy 3D applications on modern Linux systems.
• QEMU provides an additional environment for driver development and testing.

The ability to initialize the hardware without requiring a working Video BIOS is particularly valuable for non-standard systems and virtualization environments.

🖥️ Future Possibilities for PCI Passthrough

#

One potential application is retro operating-system virtualization.

In principle, a Linux host could eventually expose a physical Voodoo3 to a Windows 98 or DOS virtual machine through PCI passthrough:

Linux Host
    |
    v
PCI Passthrough
    |
    v
Voodoo3
    |
    v
Windows 98 / DOS VM

Such a configuration could potentially provide much more authentic graphics hardware to a legacy guest than software emulation alone.

However, this remains a future possibility rather than a turnkey solution.

Several technical issues still need to be addressed, including:

• Reliable hardware reset behavior.
• Proper device state initialization.
• Safe register-space exposure.
• Guest/host ownership of the device.
• PCI passthrough integration.
• Correct handling of hardware state across VM lifecycle events.

The standalone initialization work therefore represents only one component required for a complete passthrough solution.

🚧 Experimental Status and Limitations

#

The current driver work should be viewed as experimental.

The improved tdfxfb support provides basic framebuffer functionality, while the separate 3D stack is still under active development.

The distinction is important:

This is not a replacement for a contemporary GPU driver, nor does it turn the Voodoo3 into a practical modern desktop graphics accelerator.

Instead, it provides a technically interesting bridge between legacy 3dfx hardware and modern Linux development.

🧠 A Modern Linux Path for Classic 3dfx Hardware

#

The Voodoo3 may be more than twenty years old, but its renewed Linux support illustrates how legacy hardware can remain useful as an engineering platform.

The Linux 7.3 tdfxfb changes address a fundamental initialization problem by removing the assumption that system firmware must first execute the Voodoo3’s Video BIOS. The experimental /dev/tdfx3d path goes further by allowing user-space software to interact directly with the accelerator.

With smoltdfx, smolminigl, physical Voodoo3 hardware, and QEMU emulation all contributing to the development effort, the project provides a compact environment for experimenting with old 3D hardware without rebuilding the entire legacy graphics ecosystem.

For retro-computing enthusiasts, the ability to boot Linux, initialize a Voodoo3 independently of PC firmware, and run Quake through an experimental 3D stack is a remarkable demonstration of how far modern open-source development can extend the usable life of classic hardware.