Proton and Wine

[Zema Bus]

Since we both ran into the same issue it seems like there would be a number of users who are running 6.14 and experiencing it, but I didn't find a single mention of it on a search. I looked on ProtonDB too but there was only one report from someone running 6.14 with one of these Sniper Elite games and he didn't mention it. He was running CachyOS.

[Grogan]

It's definitely something in the kernel, going back to 6.13.x, the Reverb Audio works correctly again. (I tested that soon after discovering this problem)

[Grogan]

So I had been trying a few times to build a proton-tkg with Valve's new Proton 10 (Experimental Bleeding Edge 10 sources).

The first snag was that Valve has enabled winedmo (an alternate method of handling that MF'er embedded video shit that uses a dll linked to ffmpeg)

This introduces a new alternative FFmpeg-based implementation for the MF byte stream handlers, while keeping the current GStreamer-based as default.

The new implementation can be enabled by setting the DWORD value:

DisableGstByteStreamHandler = 1

in the HKCU\Software\Wine\MediaFoundation registry key.

(I haven't gotten around to trying that, tonight I'm going to try it with Borderlands 3 with my Wine 10.7 ntsync build. I'll have to figure out how to run wine-regedit in context... proton makes that shit hard, with fugly paths to use in variables etc.)

This is already in upstream Wine, but Valve is using old ffmpeg (4.4) for it and theirs doesn't compile against modern ffmpeg. So I had to install ffmpeg 4.4.5 and use variables in the build-64.sh file in the wine-tkg-scripts directory.

Code: Select all

FFMPEG_CFLAGS="-I/usr/include/ffmpeg4.4" FFMPEG_LIBS="-L/usr/lib/ffmpeg4.4 -lavcodec -lavformat -lavutil"

That got me through the winedmo build, but then the bloody thing failed on opencl. I don't use opencl (for anything... I don't even build the back end with Mesa), but I have ocl-icd, lib32-ocl-icd and opencl-headers installed because they are build dependencies for a lot of things. I couldn't figure it out, my opencl headers were defining everything the linker was failing on.

It turns out it was sabotage. There was a commit (Valve I presume, it's not in the wine-tkg-git project) that builds a stub if the opencl headers are not present on the host system. This causes the build to fail if the real opencl-headers are installed as it can't link. Rather than figure out where in the scripts to revert the commit after the Valve sources are checked out, I just temporarily removed my opencl-headers and finally got a successful build of "proton_tkg_experimental.bleeding.edge.10.0.195152.20250507" and it works.

I don't use my Valve builds much anymore, but there are a few games that don't run with ntsync so I still maintain one. Oddly, one of the games that doesn't work with ntsync is Wolfenstein New Colossus. I was surprised, because that's a pretty straight forward game that uses a Vulkan renderer. It has always worked with any Proton (moreover, it's the very first game I ever tried at Proton's inception). Another game that doesn't run with ntsync wine is F.E.A.R 2 Project Origin. (It's not just the 32 bit thing either, plenty of other 32 bit games run just fine). The Ubisoft client also doesn't work with ntsync wine proton either, so therefore none of its games. The only one I have installed now is Assassin's Creed Valhalla.

The EA App and games work well in Lutris with wine ntsync builds, so that leaves Ubisoft biting the weenie. When I'm finished with this Valhalla playthrough I'll remove it so my life can be Ubisoft free. I'm not buying any more of their games (refunded that stupid Star Wars Outlaws and skipped Assassin's Creed Shadows)

P.S. Sadly, no, Borderlands 3 intro videos don't quite work with that winedmo. The audio plays and it doesn't freeze or crash but the intro videos are just a black screen (that's actually noteworthy in this situation and probably means you could actually play the game without the embedded videos showing up, because the sequence would actually complete)

I ran regedit in context, and created the new subkey and Dword value as above. I deleted the key and went back to the protonmediaconverter.so (gstreamer based) and the videos display again. It probably won't be long before there's no more need for that. It's a pain in the ass to keep that working against the system's gstreamer (proton-tkg are native builds), I already have to keep recompiling gstreamer 1.24.9 when Arch breaks it upgrading libraries it links against.

[Zema Bus]

I discovered I didn't have the Kraken Awakes DLC in Sniper Elite 5 so I picked that up, along with Sniper Elite Resistance and Indiana Jones. I started Kraken Awakes, it's pretty good so far. Next weekend is a three day weekend so I'm planning on more game time for the first time in a while and less other stuff

[Grogan]

Yes, Kraken Awakes is an interesting map, with that giant ship in the harbour etc.

You can't go too far wrong with Sniper Elite games.

I hope you get further than I did in Indiana Jones. I finished the Vatican level and got to Egypt, but never went back to it and reclaimed the disk space.

[Grogan]

I've been noticing a regression in performance in Sniper Elite 5, using the game's Vulkan renderer option. I use 150% resolution scaling (because of the shitty antialiasing in that engine), so the performance degradation was noticeable.

I tried the DirectX 12 renderer for the first time, and oddly, performance was much better (like how it used to be) so I've been playing it with that. One would think that would be worse, with extra overhead of DirectX 12 -> Vulkan translation.

That MAY be because of this:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/13766

vulkan/common: Legacy render pass inserts barriers naively everywhere

While testing some stuff with Granite I ran into an effect which causes severe pessimization for back-to-back independent legacy render passes:
...
...

This manifests as barriers that should not exist:
...
...
This won't affect dynamic rendering (e.g. vkd3d-proton / DXVK), but there's lots of other native Vulkan content out there which needs to be 1.1 compatible and cannot rely on dynamic rendering.

[Grogan]

So now, Wine 10.16 has NTSYNC natively. It's a different implementation that they call inproc-sync, using the ntsync kernel module. I got successful builds last night (tkg... no more need for the ntsync patchsets), of a proton-tkg, a wine-tkg runner for lutris and a wine-tkg for my system wine (PKGBUILD)

At least with these tkg builds, it's enabled by default and I don't have to use any environment variable. (I can tell it's working by "lsof | grep /dev/ntsync")

So far, so good, it's at least as good (and compatible) as the legacy ntsync patchsets I've been using with TKG.

Pretty soon everyone will be using this (though Valve would need to get onboard with it for their protons)

P.S. I have to say that this builtin inproc ntsync is MORE compatible than the old patchsets. I have a game (Control) that wasn't working with ntsync before, that now works with my new wine. On the next release cycle, I will probably be able to skip building a lutris runner (just use my system wine seeing as it can now have all the amenities).

[Grogan]

Whatever problem that was causing the Vulkan renderer in Sniper Elite 5 to have poor performance seems fixed now. I haven't played that in some time and I tried the Vulkan renderer again, and performance was back to normal. The regression was noticeable because I was using 150% resolution scaling for better antialiasing effects.

It could have been Mesa, or it could have even been my proton/wine (which I hadn't considered at the time since it worked so well with other things). Thinking more on it now, there were times when the wine-vulkan patchsets were broken, omitted or dodgy in those builds.