The amazing progress with DXVK [GitHub] continues! This Vulkan-based compatibility layer for Direct3D 11 with Wine just put out version 0.64.
Here's what's new:
- Added support for D3D11.1 resource discard functionality
- Fixed possible violation of the minStorageBufferAlignment device limit
- Updated MSAA sample locations to match the Vulkan 1.1.82 spec update
- Removed redundant barrier preventing parallel execution of compute shaders in some games
- Dragonball Xenoverse 2: Fixed shader compilation issue on RADV (#523)
- Final Fantasy XV: Added workaround for broken compute shader barriers on RADV
- Hellblade: Fixed overly aggressive flushing behaviour when waiting for mapped resources
- Hitman (2016), World of Warships: Fixed incorrect clamp-to-border behaviour (#517)
This marks the 17th release so far this year!
I'm still amazed the project is as far along as it is, considering it hasn't been around for that long. While I don't personally make use of it, I absolutely appreciate having it on Linux for those games I might eventually want to play that never get a Linux version.
Having the option is good! If it brings more people to Linux, enabling them to continue playing their favourite games certainly helps.
Some you may have missed, popular articles from the last month:
Quoting: KristianI would argue it's not redundant, even a little, for a number of reasons.Quoting: ShmerlQuoting: KristianSo DXVK not being merged into Wine, does that mean that the Wine project will continue their effort to implement DX11 on top of OpenGL? So there will be two separate DX11 implementations on Linux?
Yes, they are continuing working on D3D11 over OpenGL. It's already working for the most part, except for performance issues which they didn't address yet.
See https://bugs.winehq.org/show_bug.cgi?id=44315
Thanks that is quite interesting. At one point then there could be two complete implementations of D3D11 on Linux. Might seem a bit redundant, but a natural consequence of FLOSS. In the proprietary world if you don't like something, too bad. You often can't do anything about it.
OpenGL is a well-supported, well-established, and simpler API. Vulkan, as great as it potentially and practically may be, isn't even available on all hardware and software configurations. Completing the OpenGL implementation regardless of the progress of the Vulkan one broadens potential targets on which you'll be able to play Windows games. Broader availability is always better, I think is safe to say.
And having two implementations drastically improves debugging potential. It's immensely easier to figure out a problem when you have a reference implementation that already solved it.
1 Likes, Who?
Quoting: qptain NemoI would argue it's not redundant, even a little, for a number of reasons.
OpenGL is a well-supported, well-established, and simpler API. Vulkan, as great as it potentially and practically may be, isn't even available on all hardware and software configurations. Completing the OpenGL implementation regardless of the progress of the Vulkan one broadens potential targets on which you'll be able to play Windows games.
I'd argue, features that are needed to implement D3D11 in OpenGL require quite high OpenGL version (4.5 practically), so any hardware / OS configuration which supports that should support Vulkan as well. But having another implementation is good anyway.
Last edited by Shmerl on 5 August 2018 at 4:41 pm UTC
0 Likes
Quoting: KristianSo DXVK not being merged into Wine, does that mean that the Wine project will continue their effort to implement DX11 on top of OpenGL? So there will be two separate DX11 implementations on Linux?
Personally consider follow with actual translation is a big time loss specially with actual DXVK state
^_^
1 Likes, Who?
Quoting: mrdeathjrThe Witcher 3I'm seriously tempted to break my “five year rule” and buy that now. My specs aren't quite up to yours, but I could live with 30fps.
With DXVK using Core i3 8350K Tri-Core @ 5.0ghz + CoolerMaster Hyper T4
0 Likes
Quoting: DuncI'm seriously tempted to break my “five year rule” and buy that now. My specs aren't quite up to yours, but I could live with 30fps.
Wait a bit more, until there is a workaround for missing stream output. I haven't played the game through yet because of it.
Last edited by Shmerl on 5 August 2018 at 9:54 pm UTC
0 Likes
Quoting: DuncI'm seriously tempted to break my “five year rule” and buy that now.
My specs aren't quite up to yours, but I could live with 30fps.
For now try wait because steam flash sales possible back
https://www.techpowerup.com/246478/valve-reportedly-bringing-flash-sales-back-from-the-dead
Many game houses with actual lower discounts can provide better discounts in short time
Respect specs ryzen 7nm must be stay very close in single thread than my actual core i3 8350K Tri-core 5.0ghz
^_^
0 Likes
I would like to see a comparison between the Feral ports of Tomb Raider (2013), Mad Max and Rise of the Tomb Raider versus the windows versions of those games running via wine/DXVK..
1 Likes, Who?
Quoting: Comandante ÑoñardoI would like to see a comparison between the Feral portsTL;DR of that would be that it beats the native port of TR2013 by a mile but runs into some weird issues with Tessellation enabled that I never figured out, while the native port of RoTTR beats DXVK by a mile (not to mention that RoTTR is completely unplayable on dxvk because it has insane amounts of shader compiler stutter).
Last edited by YoRHa-2B on 6 August 2018 at 4:42 pm UTC
0 Likes
Quoting: YoRHa-2BNnot to mention that RoTTR is completely unplayable on dxvk because it has insane amounts of shader compiler stutter.
Is the only way to reduce it, to make shader compiler itself much faster / parallelized?
Last edited by Shmerl on 7 August 2018 at 1:17 am UTC
0 Likes
Quoting: ShmerlQuoting: DuncI'm seriously tempted to break my “five year rule” and buy that now. My specs aren't quite up to yours, but I could live with 30fps.
Wait a bit more, until there is a workaround for missing stream output. I haven't played the game through yet because of it.
I heard this is a problem linked to LLVM version 6? Do you think it will be fixed with LLVM 7 releasing in September?
0 Likes
See more from me