# qemu-3dfx: giving QEMU a 3Dfx Glide and MESA GL device

> qemu-3dfx is a set of overlays and patches that add a 3Dfx Glide pass-through device model to QEMU, plus host and guest side wrappers so that retro Windows games get hardware accelerated OpenGL inside a virtual machine. It is a preservation project rather than a general graphics stack, and its build instructions assume an MSYS2 shell on Windows.

**kjliew/qemu-3dfx** — MESA GL/3Dfx Glide pass-through for QEMU

- Repository: https://github.com/kjliew/qemu-3dfx
- Stars: 577 · Forks: 83
- Language: C
- License: GPL-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/kjliew-qemu-3dfx

## A device model, not a graphics driver

The repository describes itself as a MESA GL and 3Dfx Glide pass-through for QEMU, and the name of the mechanism is worth being precise about, because it is not the same as a graphics driver. A pass-through device model is a virtual device that QEMU presents to the guest, while the actual rendering happens on the host through MESA and, for the Glide path, through the OpenGLide translation layer on the host side. The guest therefore believes it is talking to a 3Dfx Voodoo card, and the host translates the Glide calls into modern OpenGL.

The repository layout is a good map of how that is assembled. The qemu-0/hw/3dfx directory is an overlay for the QEMU source tree that adds the 3Dfx Glide pass-through device model, and qemu-1/hw/mesa is the overlay adding the MESA GL pass-through device model. The wrappers/3dfx directory holds the Glide wrappers for supported guest operating systems and environments, which the README lists as DOS, Windows and DJGPP, and wrappers/mesa holds the MESA GL wrapper for Windows guests. There is also a virgil3d/ directory at the top level, a scripts/ directory with a sign_commit script for stamping the commit id, and the three patch files themselves. The project is written in C, licensed GPL-2.0, the default branch is master, and the last push to the repository was on 2026-09-29.

## Three patches, one per QEMU generation

The patch set is versioned against QEMU releases, and that is the first thing to get right. The repository carries 00-qemu92x-mesa-glide.patch for QEMU version 9.2.x, covering both MESA and Glide, 01-qemu82x-mesa-glide.patch for version 8.2.x, and 02-qemu72x-mesa-glide.patch for version 7.2.x. The numbering prefix makes the intended order obvious, and the README's build guide uses the 9.2.x patch as its worked example.

The three-way split is a maintenance statement as much as a technical one. QEMU's device model interfaces change between major releases, so an overlay that adds a new device has to be re-based each time, and the project carries a patch per generation rather than one patch that spans them. If you pick a QEMU tarball that does not match the patch, the patch will not apply, and there is no compatibility range to negotiate because the split is by release line.

The overlays are copied into the QEMU source tree rather than applied as a diff, which is why the build guide uses rsync for them. The overlays are additive, they add files under hw/, and the patch then wires them into the build. That split is the reason a user who tries to apply the patch without copying the overlays first will see failures that look like patch errors and are not.

## Building QEMU under MSYS2 on Windows

The build instructions are based on an MSYS2 or mingw-w64 BASH shell environment on modern Windows, and the README says it is meant to be simple, with minor variations inevitable because of the different flavours of Linux distributions. The sequence is short, and it starts by making a working directory and cloning the overlay repository.

```bash
    $ mkdir ~/myqemu && cd ~/myqemu
    $ git clone https://github.com/kjliew/qemu-3dfx.git
    $ cd qemu-3dfx
    $ wget https://download.qemu.org/qemu-9.2.2.tar.xz
    $ tar xf qemu-9.2.2.tar.xz
    $ cd qemu-9.2.2
    $ rsync -r ../qemu-0/hw/3dfx ../qemu-1/hw/mesa ./hw/
    $ patch -p0 -i ../00-qemu92x-mesa-glide.patch
    $ bash ../scripts/sign_commit
    $ mkdir ../build && cd ../build
    $ ../qemu-9.2.2/configure && make
```

The two steps that are easy to miss are the rsync of the overlays into ./hw/ and the sign_commit script, which stamps the commit id so a build can be traced back to the overlay revision it came from. The build itself is a separate out-of-tree directory, ../build, so the source tree stays clean and the build can be thrown away without re-extracting the tarball.

## The guest wrappers need four different toolchains

The host-side wrappers are the second build, and the requirements list is the most demanding part of the project. It needs base-devel with make, sed and xxd among others, gendef and shasum, a mingw32 cross toolchain of binutils, gcc, windres and dlltool for the WIN32 DLL wrappers, Open-Watcom at 1.9 or 2.0 or Watcom C/C++ 11.0 for the DOS32 OVL wrapper, and the i586-pc-msdosdjgpp or i686-pc-msdosdjgpp cross toolchain of binutils, gcc and dxe3gen for the DJGPP DXE wrappers.

The build steps are the same for both wrapper directories.

```bash
    $ cd ~/myqemu/qemu-3dfx/wrappers/3dfx
    $ mkdir build && cd build
    $ bash ../../../scripts/conf_wrapper
    $ make && make clean

    $ cd ~/myqemu/qemu-3dfx/wrappers/mesa
    $ mkdir build && cd build
    $ bash ../../../scripts/conf_wrapper
    $ make && make clean
```

The reason there are three toolchains is that the Glide API has to be presented to the guest in whatever form each environment expects, and those environments did not share a toolchain. The Win32 DLL wrappers are built as Windows DLLs with the mingw32 cross compiler, the DOS OVL wrapper is an overlay module built with the Open Watcom or Watcom C/C++ toolchain, and the DJGPP wrappers are built as executables with a DOS cross toolchain.

## Installing the guest side by hand

Once the wrappers exist, installing them is a matter of copying files into the guest, and the README separates the two Windows generations because the file sets differ. For Win9x and ME, FXMEMMAP.VXD goes to C:\WINDOWS\SYSTEM, along with GLIDE.DLL, GLIDE2X.DLL and GLIDE3X.DLL, GLIDE2X.OVL goes to C:\WINDOWS, and OPENGL32.DLL goes into the Game Installation folders. For Win2k and XP, the set changes to FXPTL.SYS in %SystemRoot%\system32\drivers, the three GLIDE DLLs in %SystemRoot%\system32, and INSTDRV.EXE is run with Administrator Priviledge, which the README spells that way, before OPENGL32.DLL goes into the Game Installation folders.

The administrative requirement on the XP path is the notable one, because the driver has to be installed rather than dropped in. The Game Installation wording also means the file has to be placed per game directory, which is the same pattern OpenGL and Direct3D wrappers use generally: the guest application has to load them, so they have to be where the application is.

The README frames the result in terms of what the user avoids. Most games can be installed and played in pristine condition without the hassle of hunting down unofficial, fan-made patches to play them on modern Windows or Linux and Wine. There is a YouTube channel, a presence on the VOGONS forums and a project wiki, and the README invites people to witness, experience and share thoughts on modern CPU and GPU prowess for retro Windows games on Apple Silicon macOS, modern Windows and Linux.

## Where qemu-3dfx is the wrong tool

Three cases point elsewhere. The first is a user who wants graphics acceleration for modern 3D workloads. The scope of this project is Glide and MESA GL for period Windows titles, and the pass-through device model is a translation layer for those APIs, not a general purpose virtual GPU. Modern virtual GPU work belongs in QEMU itself, not in an overlay patch.

The second is a user who wants a packaged binary. Everything here is a source build: the overlays have to be copied into a QEMU source tree, a patch has to be applied, and the wrappers need three separate cross toolchains. That is a day of setup for a preservationist and a barrier for anyone else.

The third is a Linux-first user who expects the README's instructions to transfer. The build guide is explicitly based on an MSYS2 or mingw-w64 BASH shell on modern Windows, and the README warns that minor variations are inevitable because of the different flavours of Linux distributions, which is a thin assurance for someone starting from a Linux host.

The alternative worth weighing is running the original game on a period-correct or emulated environment, or using a community driver such as dgVoodoo, which does the same translation job outside the virtual machine and skips the QEMU patch entirely. The difference in approach is where the translation happens: qemu-3dfx puts the pass-through device inside the emulator, so the guest sees period hardware and the game runs unchanged, while dgVoodoo sits inside the guest and needs the game to load it. The trade is fidelity against setup effort.

## Conclusion

qemu-3dfx fits a preservationist who wants retro Windows games to run with real 3D acceleration under QEMU rather than in a software rasteriser, and who is prepared to build QEMU from source and place guest drivers by hand. It does not fit a user who wants a packaged QEMU with graphics acceleration, since the project ships patches and overlays rather than binaries, and it does not fit anyone whose interest is modern 3D workloads, since the whole scope is Glide and MESA GL for period titles. Before you start, read the patch file list, because the overlays are versioned against QEMU releases, with the 9.2.x patch first, then 8.2.x and 7.2.x, and pick the QEMU tarball that matches the patch you apply.

## FAQ

### What does qemu-3dfx add to QEMU?

It adds a 3Dfx Glide pass-through device model through the qemu-0/hw/3dfx overlay and a MESA GL pass-through device model through the qemu-1/hw/mesa overlay, with host and guest side wrappers for DOS, Windows and DJGPP guests. The rendering happens on the host through MESA and the Glide wrappers.

### How do I build QEMU with the qemu-3dfx patches?

The README's guide runs in an MSYS2 or mingw-w64 BASH shell on Windows. You clone the repository, download and extract the QEMU tarball, copy the two overlay directories into ./hw/ with rsync, apply the matching patch with patch -p0, run the sign_commit script, and then configure and make in a separate build directory.

### Which QEMU versions does qemu-3dfx support?

The repository carries three patches, 00-qemu92x-mesa-glide.patch for QEMU 9.2.x, 01-qemu82x-mesa-glide.patch for 8.2.x and 02-qemu72x-mesa-glide.patch for 7.2.x, and the build guide's worked example uses the 9.2.x patch with the qemu-9.2.2 tarball.

### What toolchains are needed to build the guest wrappers?

The requirements are base-devel with make, sed and xxd, gendef and shasum, a mingw32 cross toolchain for the WIN32 DLL wrappers, Open-Watcom 1.9 or 2.0 or Watcom C/C++ 11.0 for the DOS32 OVL wrapper, and the i586-pc-msdosdjgpp or i686-pc-msdosdjgpp cross toolchain for the DJGPP DXE wrappers. Each wrapper directory is built with a conf_wrapper script followed by make.

### Which guest files does qemu-3dfx install?

For Win9x and ME, FXMEMMAP.VXD, GLIDE.DLL, GLIDE2X.DLL and GLIDE3X.DLL go to C:\WINDOWS\SYSTEM, GLIDE2X.OVL to C:\WINDOWS and OPENGL32.DLL to the game installation folders. For Win2k and XP, FXPTL.SYS goes to %SystemRoot%\system32\drivers, the three GLIDE DLLs to %SystemRoot%\system32, INSTDRV.EXE is run with administrator privileges, and OPENGL32.DLL goes to the game installation folders.

## Sources

- [Issues](https://github.com/kjliew/qemu-3dfx/issues)
- [kjliew/qemu-3dfx on GitHub](https://github.com/kjliew/qemu-3dfx)
- [License: GPL-2.0](https://github.com/kjliew/qemu-3dfx/blob/master/LICENSE)
- [README](https://github.com/kjliew/qemu-3dfx/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kjliew-qemu-3dfx