D7VK is a Vulkan-based translation layer for Direct3D 7, 6, 5 and 3 for use with Wine / Proton, and with version 2.3 out now it's entering maintenance mode.
What is it? It uses a modified version of DXVK's D3D9 Vulkan backend as well as Wine's DDraw implementation, or the Windows native DDraw implementation, and acts as a proxy between the two. Basically, it's another way to run old Windows games on Linux with great performance and accuracy.
The developer announced version 2.3 has arrived:
"Although the codebase has reached what I'd call a point of maturity (also see the announcement below), this release rolls out several important reworks in terms of object handling as well as several new fixes and workarounds intended for early D3D games. There is also one (perhaps final) performance optimization I was able to pull off, by controlling the memory placement of our shadow surfaces. These are mirror surfaces we create on the "legacy" presentation path to swap in for the actual primary surface, in order to prevent swap chain infighting caused by presents on the DDraw (WineD3D) swap chain. They are fairly abused by games who are in the habit of blitting their cursor on top of the final rendered image, and as such we can see a rather nice performance improvement if we keep these shadow surfaces in system memory. Ironically, it's in Empire Earth where this difference is most noticeable, so although it already had its spotlight moment part of the v2.1 release, it makes a second appearance now, this time in a comparative benchmark and timeline evolution of D7VK performance:"
The announcement shows quite a difference between version 2.2 and 2.3 for Empire Earth as the example jumping from 80.6FPS to 137FPS in once scene:
Rebased on top of the recent DXVK v3.1.1 minor release.
Streamlined shadow surface creation and tweaked its placement for a performance boost in most scenarios. This will typically lower the overhead seen in games that blit a cursor directly on top of the primary surface. Star Trek: Armada is the only known title that is hit by a performance regression because of it, so there's now also a config option to keep shadow surfaces in sync with the primary surfaces, as placed by the calling application. Worry not, you can still get the best Star Trek: Armada experience with D7VK.
Added checks for Vulkan-side support of depth formats before reporting them as available. This might help sort out issues on various mobile platforms with limited format support.
Added a workaround to fix intro video playback in the original (unpatched) release of Need for Speed: Porsche, by simply not providing support for overlay surfaces (thanks to @CkNoSFeRaTU for noticing this quirk).
Handled interrupted/partial EnumSurfaces calls more robustly, preventing any surface leaks from the DDraw callbacks.
Thanks to @CkNoSFeRaTU, we've worked around unspecified dwVertexCount values used during execute buffer setup, which fixes rendering issues in Dark Vengeance. As a result the game is (finally) playable on Linux.
Relaxed RT surface validations for early D3D APIs, to reflect native behavior, which allowed for plain surfaces to be used as render targets.
Added a ProcessVerticesStrided implementation for D3D7, although there are no known users at the moment.
Updated extents during D3DPROCESSVERTICES_COPY execute buffer operations as well, as seen to be required by a few D3D3 games, such as G-Police and HyperBlade. The rework has also somewhat simplified the CPU ProcessVertices implementation, though it's unlikely there will be any noticeable performance differences.
Consolidated texture handle logic across all early D3D APIs. This was necessary because D3D6, although touting to do away with texture handles, ended up having a fallback path which included, you guessed it, texture handles. This doesn't fix any problems per se, but is generally more robust against games who abuse the feature, such as Grandia II.
Fixed a bug that caused stale alpha operations to remain in effect after the blend mode changed without any changes to the set texture. Thanks to @CkNoSFeRaTU for spotting it. This has fixed an issue with broken water surface transparency in Z.A.R..
The codebase is considered mature enough to have met its initial… well, rather ever extending goals… of providing good support for all early immediate mode D3D APIs.
No new major features are expected to be worked on in the future, though bug fixes and minor additions will trickle in, as usual.
The release cycle will be a lot more spread out, with less frequent releases.
kend implementations for materials and textures across D3D6/5/3, wherever possible, by leveraging the already existing common objects.
Unified the implementation of the D3D6/5/3 viewport, by implementing all interfaces with a single object. Sadly, it's only possible to pull off for viewports, since all viewport interfaces are extensions of one another, a singular case in early D3D. This has fixed crashing on game start with the (patched) GOG release of Star Wars: X-Wing Alliance and is generally more robust against mods/patches which hook the viewport vtable and rely on such implementation details.
Removed some validations on execute buffer description struct sizes, because apparently they're not performed by the native implementation and some games are known to send junk sizes (cough, Forsaken, cough).
Added an option to use an inverted LOD bias scale for mip mapping. This is apparently expected by some early D3D games, such as Redline Racer, due to a misleading D3D6/5 documentation entry.
With it now entering maintenance mode there will be less frequent releases, with no major new features expected to come.