igdext64.dll. It lets Windows games running on Linux call Intel's Direct3D 11 Graphics Extensions and hands those calls to DXVK's Vulkan implementation, so the games don't drop back to plain D3D11. Phoronix reported the project on September 23, 2026, and Proton already ships it on its bleeding-edge branch. Nobody has published benchmarks, and the project doesn't list which games use these extensions. For now it's a targeted compatibility fix for Intel Arc on Linux, and any speed gain in a given game is still unmeasured.
Intel's dxvk-igdext brings Arc-specific D3D11 extensions to Wine
According to Phoronix, Intel engineers have been quietly developing dxvk-igdext as their own component for DXVK Direct3D 8 / 9 / 10 / 11 atop the Vulkan API for leveraging Intel Direct3D 11 Graphics Extensions. DXVK is the translation layer that turns Direct3D calls into Vulkan. Valve's Proton, the Wine-based compatibility tool behind Steam Play, is built on top of it. Phoronix presents the project as a way to improve the Linux (Steam Play) gaming experience on Intel Arc Graphics hardware.
The public repository is GameTechDev/dxvk-igdext on GitHub. Its README states the goal plainly. The DLL lets games use Intel D3D11 Graphics Extensions (UAV overlap, MultiDrawIndirect, depth bounds) under Wine by forwarding them to DXVK's native implementation, instead of the game silently falling back to slower default D3D11 behavior when the extensions can't be found.
The word "silently" describes the problem this solves. A game built with Intel's extension SDK checks at startup whether the Intel extension library is present. On Windows with Intel's driver installed, it finds the library and uses the Intel-specific paths. Under Wine that library has never existed, so the game takes its generic D3D11 path without any error. Players get no warning that a faster code path was skipped.
Intel has also set a clear platform limit: the project is Linux/Wine only for now, not for use on native Windows. Windows users with Arc cards already get these extensions from Intel's own driver. Nothing here replaces or changes that.
How igdext64.dll fits into the Wine, DXVK and Proton stack
Getting a game to find the DLL takes more than dropping a file into a folder. The README says the location games search, along with the fake DX11 Intel UMD (igd10iumd64.dll) that makes games look for it, come from wine's HACK/INTEL patches (fake UMD DLL, DriverInfPath, SetupGetInfDriverStoreLocationW) plus DXVK's [d3d11] Load Intel vendor hack DLL patch, which loads that UMD. A UMD is a user-mode driver, the part of a Windows graphics driver that runs inside the game's own process.
The chain works like this. Wine installs a dummy Intel D3D11 user-mode driver DLL in a Windows-style DriverStore folder. DXVK loads that dummy driver when the adapter is an Intel GPU. The game's Intel loader code then follows the driver's location to igdext64.dll, which sits beside it. Valve's Wine fork contains a commit titled "HACK/INTEL: igd10iumd64: Add dummy DLL and install it under DriverStore". The commit message says Intel requested it and that games use it to locate igdext64.dll. It installs the dummy DLL under DriverStore\FileRepository\igd_faux.inf_1.
The README also describes where each piece lives: the wine side lives in Proton's own wine fork and the DXVK side is upstream, so a reasonably recent Proton build likely has both already. The Wine part is currently in Valve's fork, not in mainline Wine. That affects anyone running Wine outside Proton, which the practical section below covers.
On the Proton side, the README says Proton ships this project on its bleeding-edge branch as of dxvk-igdext: Add submodule and copy igdext64.dll into the prefix: it builds dxvk-igdext as a submodule into lib/wine/igdext/x86_64-windows and copies igdext64.dll into the prefix at launch, so there is no manual step. In a Proton build that includes this change, the user has nothing to set up. Proton puts the file where games expect it each time a title launches.
What the bridge forwards, and what stays stubbed
The README names three extension features, and the export table shows how each is handled:
| Capability | Exported entry points | Behavior under Wine |
|---|---|---|
| UAV overlap | _INTC_D3D11_BeginUAVOverlap, _INTC_D3D11_EndUAVOverlap | Forwarded to DXVK |
| Multi-draw indirect | _INTC_D3D11_MultiDrawIndexedInstancedIndirect, _INTC_D3D11_MultiDrawInstancedIndirect, and their CountIndirect variants | Forwarded to DXVK |
| Depth bounds | _INTC_D3D11_SetDepthBounds | Forwarded to DXVK |
| Texture creation | _INTC_D3D11_CreateTexture2D | Passed to plain CreateTexture2D, no DXVK extension |
As general background, not taken from the project's documentation: UAV overlap lets a game tell the driver that consecutive operations writing to unordered access views don't need to wait on one another. Multi-draw indirect issues many GPU-driven draw calls through a single API call. Depth bounds testing throws away pixels whose stored depth falls outside a given range. Each one cuts overhead or wasted GPU work, which is why a game that uses them would lose some efficiency when forced onto the fallback path.
The DLL exports two generations of Intel's extension API, because games can be built against either one depending on which version of Intel's SDK they linked. The legacy pre-2019 ABI uses names without the _INTC_ prefix, such as D3D11CreateDeviceExtensionContext. The modern ABI uses _INTC_D3D11_* and _INTC_D3D12_* names, plus a few loader-compatibility entry points like D3D11GetSupportedVersions2. The module definition file Igdext.def lists 38 exports in total.
Many of those 38 exports carry no graphics functionality at all, and this project does nothing for Direct3D 12. The README says D3D11 entries forward to DXVK. D3D12 entries are inert stubs: GetSupportedVersions reports zero and CreateDeviceExtensionContext always fails. They exist only because the loader in Intel's igdext.lib needs the exports to be present. Version negotiation reports a hardcoded maximum version. The application-callback registration and internal-extension entry points are also stubs. Anyone hoping for D3D12 help on Arc should look at VKD3D-Proton, which is a separate effort.
Performance claims for Arc on Linux stay unquantified
The project describes the fallback path it avoids as "slower", and Phoronix frames it as an improvement for Arc owners. Neither Intel nor Phoronix has published frame-rate figures, a list of affected games, or before-and-after tests. Which Steam games actually link Intel's extension SDK and call these three features is also unknown. A game that never checks for igdext64.dll will run exactly as it did before.
Intel's Arc hardware is also missing from the project's scope statement. Phoronix ties the work to Arc graphics, while the README only refers to Intel adapters in general. The DXVK side loads the vendor DLL for Intel adapters. Whether older Intel integrated graphics also see a benefit depends on the Vulkan driver exposing what DXVK needs, and the project hasn't documented that.
The project also has a history that explains the approach. In 2022, GamingOnLinux reported that Intel's Windows Arc drivers used code from DXVK to improve DirectX 9 performance. Turns out, they're using code from the open source DXVK which is part of Steam Play Proton. dxvk-igdext flows the other way: Intel is contributing code so that its Windows-side extension ecosystem works on top of DXVK on Linux.
What this means for you
If you game on Linux with an Intel GPU through Steam, you don't need to do anything. Protonless Wine users will need patched components before any of this helps them. Windows users are not affected. Anyone who wants to try it now should use a Proton build that already includes the integration, not a hand-copied DLL.
Steam users can try Proton's bleeding-edge branch today. The project hasn't said when the change will reach stable, numbered Proton releases, and no other outlet has reported that timing. Once it arrives in whatever Proton version you use, the DLL is copied into each game's prefix automatically at launch.
Users of other launchers are in a different position. On the Bottles project's GitHub, a user opened an issue pointing out that Intel D3D11 Graphics Extensions are not available under wine/dxvk and asking for dxvk-igdext support. That shows the integration hasn't reached every Wine front end. For non-Proton setups, the README's manual deployment path puts the DLL at $WINEPREFIX/drive_c/windows/system32/DriverStore/FileRepository/igd_faux.inf_1/. For a Steam Proton prefix, the equivalent location is <Steam library>/steamapps/compatdata/<appid>/pfx/drive_c/windows/system32/DriverStore/FileRepository/igd_faux.inf_1/. Copying the DLL alone does nothing unless your Wine build carries the HACK/INTEL patches and your DXVK includes the Intel vendor-DLL loading change.
Developers can build it themselves. The documented build uses CMake with a MinGW-w64 cross toolchain, cmake -B build -DCMAKE_TOOLCHAIN_FILE=./toolchain-mingw64.cmake followed by cmake --build build, and produces build/igdext64.dll. The README notes it also builds under MSVC if you leave out the toolchain argument. Even so, the result is only meant for Wine.
- dxvk-igdext supplies
igdext64.dll, which forwards Intel D3D11 extension calls for UAV overlap, multi-draw indirect and depth bounds to DXVK on Linux. - Proton's bleeding-edge branch already bundles the DLL and copies it into game prefixes at launch, and no timing for stable Proton has been announced.
- Manual installation only works if Wine has Valve's HACK/INTEL patches and DXVK has the Intel vendor-DLL loading change.
- Direct3D 12 entry points are non-functional stubs, so D3D12 games get nothing from this project.
- No benchmarks or lists of affected games have been published, so any speedup depends on whether a specific title calls Intel's extensions.
- The DLL is not intended for native Windows, where Intel's own driver already provides these extensions.
Intel is putting engineering time into making Windows games that were tuned for its hardware keep those tunings under Linux translation. It's being done with small, verifiable pieces: a dummy driver DLL in Valve's Wine fork, a loader change in upstream DXVK, and a submodule in Proton. The next concrete step is the bleeding-edge integration landing in a stable Proton release. At that point every Arc owner on Steam for Linux gets the bridge by default, and independent testers can finally measure what it does in real games.