# DXVK-NVAPI: an NVAPI stand-in for DXVK on Linux

> DXVK-NVAPI is a Windows DLL, built with MinGW, that reimplements enough of NVIDIA's NVAPI and NVOFAPI for DXVK and VKD3D-Proton to forward features such as DLSS, Reflex, PhysX queries and some D3D11 extensions. It forwards rather than implements those technologies, it only works alongside DXVK, and it is Linux only in practice.

**jp7677/dxvk-nvapi** — Alternative NVAPI implementation on top of DXVK.

- Repository: https://github.com/jp7677/dxvk-nvapi
- Stars: 666 · Forks: 69
- Language: C++
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/jp7677-dxvk-nvapi

## A shim that gives Linux games an NVAPI to talk to

DXVK-NVAPI provides an alternative implementation of NVIDIA's NVAPI and NVOFAPI libraries for use with DXVK and VKD3D-Proton. The way it works is similar to DXVK-AGS, the README says, but adjusted and enhanced for NVAPI.

The problem it solves is narrow and real. A Windows application written against the NVIDIA API will look for nvapi.dll, and on Linux under Wine or Proton that file either does not exist or comes from a source that does not implement the features the game needs. DXVK-NVAPI provides a DLL with those entry points so the application can call them, and the calls are then either answered by querying Vulkan or forwarded into DXVK or VKD3D-Proton, which are the layers that already speak to the driver.

The feature list is concrete. DLSS for Vulkan is supported by providing the relevant adapter information queried from Vulkan. DLSS for D3D11 and D3D12 is supported by querying from Vulkan and forwarding the relevant calls into DXVK or VKD3D-Proton. NVIDIA Reflex is forwarded into DXVK, VKD3D-Proton or a supported Vulkan implementation. Several NVAPI D3D11 extensions are covered, among them SetDepthBoundsTest and UAVOverlap. Entry points for querying PhysX capabilities are provided. And several GPU topology methods for adapter and display information are answered by querying DXVK and Vulkan.

The history explains the shape of the thing. It was originally developed for Unreal Engine 4 use, notably for Assetto Corsa Competizione, and more entry points have been added over time for other NVIDIA technologies.

## It forwards the technologies, it does not implement them

The README puts the caveat in one line, and it is the sentence to read first: DXVK-NVAPI does not implement DLSS, Reflex or PhysX, it mostly forwards the relevant calls. The DLL is a translation layer, not a graphics stack.

That distinction explains both the value and the ceiling. Value, because reimplementing DLSS would be a research project of its own, and forwarding means the actual feature keeps working through the driver's own path. Ceiling, because anything that needs a genuine implementation rather than a pass-through is out of scope, and the README is explicit that DXVK-NVAPI does not and will never cover the complete surface of NVIDIA's NVAPI. It is not meant as a full replacement, but as an addition to DXVK and VKD3D-Proton to enable several GPU features.

The scope of the surface is still substantial, and the repository shows how it is managed. There is a src directory for the implementation, inc for headers, a tests directory, an external directory for the submodules, and validate-methods.py, a prebuild validation script that is why Python 3 is a build requirement. The build variants are listed in the top level as separate text files, build-win32.txt, build-win64.txt, build-win32-llvm.txt, build-win64-llvm.txt, build-arm64x.txt and build-arm64ec-msvc.txt, so the same source is built for 32-bit and 64-bit Windows targets, with LLVM and MinGW toolchains, for Arm64X and for the Arm64EC ABI.

The project also carries a .noai file at the root, which is a declaration that contributions generated by AI are not accepted. That is worth knowing before you plan to send a patch.

## Vulkan Reflex has two backings, and the layer is the awkward one

The Reflex support is the most technically involved part of the design, and the README documents two backing implementations with a clear preference.

The first is a Vulkan driver that supports revision 2 of the VK_NV_low_latency device extension, together with winevulkan 1.4.357 or newer. The catch, spelled out in the README, is that this relies on the application enabling the extension on its own, which notably prevents Red Dead Redemption 2 from working using this method out of the box. The README says that going forward this will be the preferred choice.

The second is an additional Vulkan layer, shipped in the layer directory of the repository. This layer intercepts technically invalid Vulkan calls made by DXVK-NVAPI, enriches them with extra data, and forwards them to a Vulkan driver that supports the VK_NV_low_latency2 extension. It replaces requests to enable VK_NV_low_latency with itself. In other words, the layer exists because the first path cannot carry enough information, and it manufactures that information in the middle of the call chain.

The build cost of the layer is higher. The README states that the Vulkan Reflex layer needs Meson 1.0 and a C++ compiler supporting the C++20 standard, and that it is recommended and assumed that the layer is built as a Linux side library, so the compiler should target Linux rather than being a cross-compiler such as MinGW. The packaging script offers a --disable-layer flag for builds that leave it out.

One more integration point sits alongside these. When available, DXVK-NVAPI uses NVIDIA's NVML management library to query temperature, utilisation and other values for NVIDIA GPUs, and the README points to wine-nvml for adding NVML support to Wine or Proton.

## Building the DLL with MinGW, Meson and git submodules

Like DXVK, this library is built as a Windows DLL using MinGW, even though it is used on Linux. That is the trick at the centre of the project: the application is a Windows program running under Wine or Proton, so the artifact it loads has to be a Windows DLL, and it is cross-compiled to produce it.

The stated requirements are a MinGW-w64 compiler and headers version 9 or newer, the Meson build system at least version 0.58, and Python 3, which is needed for the prebuild validation script. The project uses git submodules, and the README asks you to fetch them while or after cloning, giving the clone command as the example. The layer, as covered above, needs more: Meson 1.0 and a C++20 capable compiler that targets Linux.

The build itself is one script:

```bash
./package-release.sh master /your/path [--disable-layer] [--enable-tests] [--build-arm64x]
```

The arguments show the shape of it. The first is the branch to build, the second is the output path, and the optional flags switch off the Vulkan layer, enable the tests, or build the Arm64X variant. The separate build-*.txt files at the repository root cover the other target combinations, including the LLVM toolchain and the Arm64EC ABI.

If you would rather not set up the toolchain, two other routes exist. DXVK-Docker is a separate project that provides a build setup using docker or podman, and prebuilt binaries of release versions are published on the releases page, with GitHub Actions set up for building development snapshots. So the practical options are a prebuilt release binary, a containerised build, or a local cross-compile.

## Dropping the DLL into Proton and into a Wine prefix

Support has been added to popular game launchers, and the README points at their documentation for usage details, so in practice the common path is letting a launcher manage the installation.

For manual installation the mechanics are simple. Under Proton, you copy and replace nvapi.dll, nvapi64.dll and nvofapi64.dll into the files/lib/wine/nvapi/i386-windows and files/lib/wine/nvapi/x86_64-windows folder of your Proton installation, for example in ~/.steam/steam/steamapps/common/Proton 11.0/ when updating the included version by hand.

Proton 9.0 or newer includes DXVK-NVAPI and enables it by default for all titles with a few exceptions. It can force-enable it for titles where it is disabled by default, and also for non-NVIDIA GPUs, by setting PROTON_FORCE_NVAPI=1, while PROTON_DISABLE_NVAPI turns it off. Proton Experimental Bleeding Edge additionally always contains the latest development version from master.

Under plain Wine the situation differs, because Wine does not include DXVK-NVAPI. You copy the same three DLLs into the syswow64 and system32 folders of your x86 or x64 prefix, and then there are three further requirements. You have to make sure Wine uses the native version of nvapi and nvapi64, with WINEDLLOVERRIDES=nvapi,nvapi64=n, which the README notes applies only to Wine versions that ship their own NVAPI implementation, such as Wine-Staging older than 7.22, and is generally no longer needed. You need the driver libraries nvngx.dll and _nvngx.dll present in the system32 directory of the prefix for DLSS SR. And you need DXVK installed in the prefix, with Wine using DXVK's dxgi.dll through WINEDLLOVERRIDES=dxgi=n, plus DXVK_ENABLE_NVAPI=1 set to disable DXVK's own nvapiHack so the two do not conflict.

## The boundaries: Linux, DXVK, and a partial API surface

Three constraints decide whether this project applies to you at all, and the README states all three.

It is supposed to be used on Linux using Wine or derivatives such as Proton, and usage on Windows is discouraged, with an explicit instruction not to replace nvapi.dll, nvapi64.dll or nvofapi64.dll on Windows with this version. The reason is structural: the implementation uses several DXVK and VKD3D-Proton extension points, so using DXVK for D3D11 and DXGI is a requirement, and using Wine's own D3D11 or DXGI implementation will fail.

Usage is not restricted to NVIDIA GPUs, but the default behaviour is to skip GPUs that are not running the NVIDIA proprietary driver or Mesa NVK, and some entry points offer no functionality or make no sense when a different GPU vendor is detected. The README adds that DLSS requires an NVIDIA GPU, Turing or newer, running the proprietary driver. The section on non-NVIDIA GPUs is cut off in the documentation available here, but what survives says that using DXVK-NVAPI with other vendors or drivers has very limited use.

The MIT licence makes redistribution easy, and there is a LICENSE file at the root of the repository. The release record shows a project that ships periodically, with v0.9.0 in March 2025, v0.9.1 in January 2026 and v0.9.2 in May 2026, and the last push was on 2026-10-16. The version numbering is still below 1.0, which is a fair signal that the entry point surface will keep moving.

## Conclusion

DXVK-NVAPI suits a Linux gaming setup that runs Windows titles through Proton or Wine with DXVK and wants NVIDIA specific features such as DLSS and Reflex to work, and it suits a Windows user poorly, since the README explicitly discourages replacing the driver nvapi.dll there. Before adopting it, confirm your setup uses DXVK rather than Wine's own D3D11 and DXGI, because the implementation depends on DXVK extension points and the README says Wine's implementation will fail, and decide which Reflex backing you want, since the Vulkan layer needs Meson 1.0 and a C++20 compiler while the driver path needs a recent winevulkan. The project is MIT licensed, the last push was on 2026-10-16, and the newest release is v0.9.2 from 2026-05-12.

## FAQ

### What does DXVK-NVAPI do?

It provides an alternative implementation of NVIDIA's NVAPI and NVOFAPI libraries for use with DXVK and VKD3D-Proton, so that applications can use DLSS, NVIDIA Reflex, PhysX capability queries and some NVAPI D3D11 extensions on Linux under Wine or Proton.

### Does DXVK-NVAPI implement DLSS and Reflex itself?

No. The README states that it does not implement DLSS, Reflex or PhysX, and mostly forwards the relevant calls to DXVK, VKD3D-Proton or a supported Vulkan implementation.

### What do I need to build DXVK-NVAPI?

A MinGW-w64 compiler and headers version 9 or newer, Meson at least version 0.58, and Python 3 for the prebuild validation script. The Vulkan Reflex layer additionally needs Meson 1.0 and a C++20 compiler targeting Linux. The project uses git submodules, so clone with --recurse-submodules.

### How do I install DXVK-NVAPI into Wine?

Wine does not include it, so copy nvapi.dll, nvapi64.dll and nvofapi64.dll into the syswow64 and system32 folders of your prefix, ensure DXVK is installed and Wine uses DXVK's dxgi.dll with WINEDLLOVERRIDES=dxgi=n, and set DXVK_ENABLE_NVAPI=1 to disable DXVK's own nvapiHack.

### Can I use DXVK-NVAPI with an AMD or Intel GPU?

Usage is not restricted to NVIDIA GPUs, but by default GPUs that are not running the NVIDIA proprietary driver or Mesa NVK are skipped, some entry points do nothing on other vendors, and the README says the use with other vendors is very limited outside of testing.

## Sources

- [Issues](https://github.com/jp7677/dxvk-nvapi/issues)
- [jp7677/dxvk-nvapi on GitHub](https://github.com/jp7677/dxvk-nvapi)
- [License: MIT](https://github.com/jp7677/dxvk-nvapi/blob/master/LICENSE)
- [README](https://github.com/jp7677/dxvk-nvapi/blob/master/README.md)
- [Releases](https://github.com/jp7677/dxvk-nvapi/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jp7677-dxvk-nvapi