The Vulkan-based implementation of D3D9, D3D10 and D3D11 for Linux / Wine named DXVK (used with Proton) has a 1.9.4 version release, plus it appears that Proton 7.0 is closing in. More info on Steam Play Proton on our dedicated page.
DXVK 1.9.4 is quite a small one simply preparing for the next Proton release, here's what's new:
- Fixed an issue that would cause VRAM to not be utilized on RBAR-enabled Nvidia GPUs if the
dxvk.shrinkNvidiaHvvHeap
option is enabled (#2438).- Enabled strict D3D9 float emulation by default on future versions of RADV. This may improve both accuracy and GPU-bound performance (PR #2448).
- Improved memory allocation behaviour. This may reduce memory usage especially in games that create multiple processes or D3D devices.
- Removed obsolete options to disable OpenVR support.
- God of War: Enabled performance optimizations and DLSS support. Note that these changes are already included in Proton Experimental.
More exciting is that it appears we shall be getting a new version of Proton soon, which will be rebased on the most recent Wine 7.0 release. You can see on SteamDB that the Proton team has been preparing it with a currently private Release Candidate in testing too. This should hopefully bring more compatibility for Windows games ready for the Steam Deck to release in February.
Be sure to follow our Steam Deck tag for all the news. All tags have a dedicated RSS feed.
Quotebring more compatibility for Windows games ready for the Steam Deck to release in February.
That wont be achieved if, first, they don't fix the WMF and MP4 problem ASAP... The actual remote transcoding system that Valve use is just... inefficient.
Quoting: Comandante ÑoñardoQuotebring more compatibility for Windows games ready for the Steam Deck to release in February.
That wont be achieved if, first, they don't fix the WMF and MP4 problem ASAP... The actual remote transcoding system that Valve use is just... inefficient.
I'm mostly of the same opinion, but the problem with WMF is one of proprietary codecs, and thus is practically unsolvable by just reimplementing WMF in FOSS code like what has been done with the rest of Wine. And since Microsoft won't ever release WMA/WMV/WMP to the world for free, the only effective solution is a) transcoding and b) that game devs do not use proprietary codecs for their videos in the first place.
The only issue with transcoding I can see is that, so far at least, it's been implemented on a need-to-use basis. In other words, a piece of media must first be requested by a Steam client somewhere in the world attempting to play it in its original form, and then Valve will flag it, transcode it, and add it to the bucket of available videos. This means that for new game releases, the first few (?) thousands of players who get to play them on launch day will suffer a less than stellar experience until the transcoded videos are ready. Not to mention the various hidden endings etc, which means that even further down the line there would be the possibility of players "enjoying" a sub-par experience.
But Valve being what they are (that is, both technically adept and NOT stupid) I firmly believe that this situation will have been resolved by the Steam Deck's launch date, by means of Valve preemptively transcoding all the media of every single game on the Steam list (or being very far in the process of doing so, with 100% of the most popular games already done and a lot of less popular games as well) and proceeding to also do that for all new releases from now on, so when players get to play a game on launch day, the transcoded media will have already been delivered along with the rest of the game, and everybody will be happy.
Regarding the need to download more data though (i.e. another form of inefficiency), this is unfortunately something that can't be changed.
See more from me