dxvk-igdext Forwards Intel D3D11 Extensions to DXVK Under Wine [2026]

By Indie Kings | September 21, 2026

Updated September 21, 2026: dxvk-igdext by Intel GameTechDev forwards Intel D3D11 graphics extensions like UAV overlap, MultiDrawIndirect, and depth bounds to native DXVK under Wine, per the official repository README. The 14-star project ships igdext64.dll with 38 dual-generation exports and already rides Proton bleeding-edge automatically. Linux and Wine only, not native Windows.

Image: The dxvk-igdext repository header. Credit: Intel GameTechDev via GitHub.

What igdext64 does under Wine

Per the official repository README at github.com/GameTechDev/dxvk-igdext, games using Intel D3D11 extensions silently fall back to slower default D3D11 paths when extensions are missing under Wine. The DLL forwards UAV overlap, MultiDrawIndirect families, and depth bounds to DXVK native handling instead.

The repo holds 14 stars, 1 fork, and 4 commits at the time of writing. License is MIT with Intel code of conduct and contributing guides.

Scope is D3D11 forwarding only. D3D12 entries exist as inert stubs because the loader requires the exports, with version queries reporting zero and creation always failing.

How Proton handles it automatically

Per the README, Proton bleeding-edge builds dxvk-igdext as a submodule into lib wine igdext x86_64-windows and copies igdext64.dll into the prefix at launch. No manual step exists on those builds.

The Wine side depends on HACK INTEL patches for the fake UMD DLL, DriverInfPath, and SetupGetInfDriverStoreLocationW, per the README with Valve wine commit links. The DXVK side needs the d3d11 Load Intel vendor hack patch, already upstream.

Reasonably recent Proton likely carries both halves already, per the README. Check before hand-patching anything.

Manual deploy when Proton does not

Per the README, without auto-staging builds place igdext64.dll under drive_c windows system32 DriverStore FileRepository igd_faux.inf_1 inside the prefix, or the Steam compatdata appid pfx mirror. Copying alone is insufficient without the Wine and DXVK patches above.

Build needs a MinGW-w64 cross toolchain via cmake with toolchain-mingw64.cmake, per the README. MSVC configures too for hand builds on Windows, though runtime use targets Wine.

Confirm patch presence first. Hand patching over a Proton that already stages everything wastes an afternoon.

What the 38 exports cover

Per the README export table plus Igdext.def, two API generations ride side by side. Legacy pre-2019 ABI without INTC prefix serves older SDK links, while modern _INTC_ families serve current SDKs plus loader-compat aliases.

D3D11 entries forward to DXVK, including Begin and EndUAVOverlap, four MultiDrawIndirect variants, SetDepthBounds, and CreateTexture2D as plain creation. Internal Extensions and callback registrations stay inert stubs.

Version negotiation requires DXVK present, per the README. Hardcoded max versions answer GetSupportedVersions calls.

• Legacy: Pre-2019 ABI for older game links.
• Modern: _INTC_ D3D11 forwarding plus D3D12 stubs.
• Count: 38 exports listed in Igdext.def.

FAQ

What problem does this solve?
Per the README, Intel-extension games silently degrade under Wine without it. The DLL forwards those calls to DXVK.

Do I need to install it manually?
No on Proton bleeding-edge, per the README. It stages automatically per launch.

Where does the DLL go manually?
Per the README, the igd_faux.inf_1 DriverStore path inside the prefix, plus Wine and DXVK patches.

Does D3D12 work?
No. Per the README, D3D12 entries are inert loader stubs.

How do I build it?
Per the README, cmake with MinGW-w64 toolchain producing build igdext64.dll.

Is it for native Windows?
No. Per the README note, Linux and Wine only.

Bottom Line

dxvk-igdext keeps Intel-extension D3D11 games on their fast path under Wine with Proton staging it automatically. Manual deploys need the Wine plus DXVK patch pair first.

Related: How to write Windows emulator for Linux | ShadPS4 and the future of PS4 emulation | Dolphin 5.0 emulator release