v1.7.1 is a quick "hotfix" release, bringing you the latest improvements in upstream DXVK. Most notably, users with AMD GPUs can finally enjoy their FSAA emulation in games making use of 16-bit color back buffers, as radv's 16-bit format texel buffer limitation has been worked around.
This means that if you're on AMD, you can stop using the ddraw.emulateFSAA = Disabled workaround and actually enjoy FSAA emulation in games that support it (or force it on even in games that don't, though be mindful of potential breakage). For Nvidia and Intel GPU users, it's all business as usual and this release doesn't do much, since there was no breakage to begin with.
For more details, see #120.
DXVK-Sarek v1.12.0
Meanwhile, DXVK-Sarek has seen a new release, which backports most D7VK functionalities onto its aging, yet non Vulkan 1.3 requiring, 1.10.x DXVK backend.
As I've mentioned before, this is good news for anyone stuck on a Nvidia Kepler card or an older Intel iGPU, however note that due to limitations inherent in its codebase, several D7VK features are unavailable within DXVK-Sarek, namely:
- Support for color key transparency
- Game controllable FSAA states (only force enabling FSAA emulation is possible)
- Conservative FPS limiter triggering
- Above mentioned 16-bit texel buffer limitations on AMD cards/radv remain in effect, though this is less critical due to the second bullet point in this list
The bottom line is that if you're in a situation where you have a Vulkan 1.3 capable GPU, so you can use D7VK, that will always remain the better choice, due to our tracking of the upstream codebase, and our rolling patch-set model, which gradually brings in the latest features and improvements from DXVK. That being said, we will also try to backport as much as we can to DXVK-Sarek, whenever that is possible without bumping backend requirements or causing general havoc/regressions.