How does DXVK NVAPI works

This page contains contains information about internals of DXVK-NVAPI and background of certain design decisions.

DXVK-NVAPI internals

NVAPI entry points can be roughly divided in two categories, extensions for Direct 3D and for querying topology/system information.

D3D11/D3D12

Implemented methods in DXVK-NVAPI for D3D11 or D3D12 mostly just forward data into DXVK or VKD3D-Proton using extension interface on the D3DxDevice, like ID3D11VkExtDevice. Those methods never use any Vulkan calls directly.

Sysinfo

For topology methods (querying all adapters, all outputs and their properties etc) to work, DXVK-NVAPI needs to build its own topology. It does so using DXVK's DXGI (EnumApapters and EnumOutputs). Since DXGI's GetDesc is limited in what it tells about an adapter, DXVK-NVAPI uses the Vulkan handles exposed by IDXGIVkInteropAdapter to query all kind of things directly from Vulkan. This way it can e.g. correctly report the driver version, but also determine the GPU architecture (Turing, Ampere) based on supported device extension.

Doing it this way is convenient since it exposes exactly the same adapters/outputs like DXVK, thus DXVK device filtering is automatically applied, and using the exposed Vulkan handles is just plain easy since no magic is needed for correlating devices between different API's.

TODO

Add notes about NVML, D3DLowLatencyDevice, VulkanLowLatencyDevice, NVOFAPI.