D7VK 2.2 is now available as a new version of the graphics translation layer designed to run classic Windows games on Linux. The project, derived from DXVK, focuses on translating the older Direct3D 7, 6, 5, and 3 APIs to Vulkan for use with Wine and Proton, and this new version dedicates a significant portion of its work to one of the areas that still had the most shortcomings: Direct3D 3 support.
The update arrives just a few weeks after D7VK 2.1 and continues the maturation process of a technology that is especially interesting for those who want to play games from the late 90s and early 2000s on modern Linux systems. In addition to improving Direct3D 3, D7VK 2.2 incorporates numerous bug fixes and internal adjustments, and is based on the recent DXVK 3.1 version.
D7VK 2.2 focuses on Direct3D 3
The main new feature in D7VK 2.2 is related to Direct3D 3, an API that had fallen somewhat behind the other older technologies supported by the project. Although the Direct3D 3 games that the developer had been able to collect and test already worked with D7VK, there were still several edge cases and behaviors that were not implemented correctly.
This was especially problematic because the catalog of games using Direct3D 3 is difficult to reconstruct. These are very old titles, many of which are no longer commercially available or are difficult to find, making it challenging to test all the possible implementations that might be encountered in practice.
With this version, the developer has revised a large part of the Direct3D 3 implementation to bring it closer to the level of maturity achieved by the other APIs compatible with D7VK.
The behavior of the D3D3 devices conforms to the original
One of the technical changes involves redoing the reference counting system for Direct3D 3 devices. D7VK 2.2 modifies this mechanism so that its behavior matches that of the native API implementation.
This type of detail might seem irrelevant to the user, but it's crucial in a translation layer. Older games can rely on specific behaviors related to object creation and destruction, and a seemingly small difference can lead to errors that are difficult to diagnose.
The new implementation thus reduces the chances of certain titles failing to manage their graphics devices in a way that D7VK did not expect.
D7VK 2.2 introduces improvements to transparency using color key
D7VK 2.2 also modifies color keying management on pure Direct3D 3 devices. Until now, the project used a very simple model in which this function remained always enabled under certain circumstances.
The new version allows for precise control over when to enable it, more faithfully reproducing the behavior of Direct3D 3. This is especially important for older games that use transparency techniques based on specific colors.
In addition, the calculations related to normalized color ranges have been optimized. These values ​​are now updated only when the surface description changes, allowing them to be cached and reused later.
The result should be a small to moderate improvement in performance in games that use color key transparency, as well as more correct behavior.
Boundary cases in execute buffers are corrected
Another important aspect of D7VK 2.2 is the revision of the Direct3D 3 execute buffer validations. The project has reorganized part of this logic to address various edge cases identified during testing.
To verify the expected behavior of the API, the developer has also been able to rely on Wine tests specifically related to Direct3D 3. These tests allow comparing the behavior of D7VK with that expected from a compatible implementation and detecting differences that might go unnoticed when using only well-known games.
This work is particularly valuable for such an old API, where the titles available for testing are scarce and do not always cover all the possibilities of the original implementation.
Greater robustness for Direct3D 5 and 3 textures
The update is not limited to Direct3D 3. D7VK 2.2 also improves the handling of textures used by Direct3D 5 and Direct3D 3 to prevent underlying surfaces from going out of range while still being used.
The change increases the robustness of graphics resource handling and can resolve errors that only appear under certain sequences of operations. The developer also notes that this improvement has had a positive effect on Frogger , originally released in 1997.
The patch shows how internal changes intended to address resource management issues can end up having visible effects on specific games, even when the modification is not specifically designed for them.
D7VK 2.2 also corrects transformation and matrix problems
D7VK 2.2 also fixes a bug related to the transformation of Direct3D 3 execute buffers. The problem was caused by an incorrect determination of the FVF format used for vertex inputs.
A problem with legacy projection matrix calculations has also been fixed. The bug was discovered through a Wine test that wasn't behaving as expected and could have negatively impacted certain Direct3D 6, 5, and 3 applications.
These changes further demonstrate the importance of compatibility testing for D7VK. Many of the problems with older graphics APIs don't necessarily appear in the most popular games, but rather in specific combinations of features that can remain hidden for years.
Less overhead on legacy draw paths
The new version also reorganizes the drawing path Begin() / Vertex() / End() Used by Direct3D 6 and Direct3D 5. The modification reduces memory consumption and provides a small performance improvement.
Once again, Frogger is among the games that can benefit from this change. While this optimization won't double the FPS of all retro titles, it does help reduce some of the overhead accumulated on the routes used by older APIs.
D7VK has already received significant performance optimizations in previous versions, so current work is increasingly focused on refining the implementation and eliminating unnecessary costs.
D7VK 2.2 part of DXVK 3.1
Another important feature of this version is that D7VK 2.2 has been superseded by DXVK 3.1 . This allows the project to benefit from a more recent base and keep its implementation aligned with the evolution of DXVK.
The relationship between the two projects is particularly important. D7VK originated as a fork of DXVK specializing in older Direct3D APIs not covered by standard DXVK usage, while both use Vulkan as the destination for graphics calls originating from Windows.
Thanks to this relationship, the structural improvements that come to DXVK can serve as a basis for D7VK to continue evolving without having to develop from scratch all the infrastructure necessary to communicate with Vulkan.
A project designed to revive classic games
D7VK has a very specific goal within the Linux ecosystem: to allow Windows games that use Direct3D 7, 6, 5, and 3 to run using Vulkan. This differentiates it from DXVK, which is primarily focused on Direct3D 9, 10, and 11.
The importance of the project increases when it comes to titles that depend on graphics technologies that Wine does not directly implement in the same way or that can benefit from a more accurate translation to Vulkan.
By combining D7VK with Wine or Proton, Linux users can recover a considerable amount of software from the late 20th and early 21st centuries without necessarily having to resort to an old Windows installation.
For those who use Wine or Proton to play games on Linux and are interested in reviving classic titles, D7VK 2.2 strengthens one of the most important pieces of the compatibility infrastructure. And while many of its improvements may be invisible to the user, each fix increases the chances that another game lost in the Direct3D 3, 5, 6, or 7 era can once again function correctly on a modern Linux system.