Wine-Staging 4.9 Released With A Few New & Updated Patches

[phoronix]

Phoronix: Wine-Staging 4.9 Released With A Few New & Updated Patches

Wine-Staging continues chugging along and as of the version 4.9 release is more than 830 patches atop the upstream Wine code-base...

http://www.phoronix.com/scan.php?page=news_item&px=Wine-Staging-4.9-Released

[aufkrawall]

Heroes of the Storm instantly crashes with both wined3d and dxvk. Frankly, the release tags are quite useless for staging, they basically seem to be as likely broken as any random in between commit.

[Weasel]

Heroes of the Storm instantly crashes with both wined3d and dxvk. Frankly, the release tags are quite useless for staging, they basically seem to be as likely broken as any random in between commit.

And this did not happen with wine-staging-4.8 or wine-devel-4.9?

[aufkrawall]

And this did not happen with wine-staging-4.8 or wine-devel-4.9?

I don't use non-staging because it usually lacks important input fixes for games. But no, 4.8 staging was not affected. Well, staging 4.8 had broken esync, so of course I didn't use that one either and instead some later commit...

[Weasel]

So it only happens with esync? Pinning down the staging patch that causes the crash shouldn't be too hard, you don't have to compile anything, because if you find out it happens in staging only, it's relatively simple, as few patches get added/modified each version.

You don't even have to install anything. You can download the .deb (or whatever) packages from winehq.org and unpack them to somewhere in /tmp yourself (no install needed just unpack), and just run it from there on a temporary prefix, and see if it still crashes.

[aufkrawall]

Tried plain wine 4.9 from Arch repo and HotS doesn't crash anymore, but instead refuses to start at all. I'll wait for the next few commits before investigating further, e.g. already tried clean prefix without success.

[skeevy420]

Tried plain wine 4.9 from Arch repo and HotS doesn't crash anymore, but instead refuses to start at all. I'll wait for the next few commits before investigating further, e.g. already tried clean prefix without success.

Ever get anywhere with that flickering?

Just about to try my 4.9-staging build with Hitman 2, saw this post, and thought I'd ask.

EDIT: Does HotS have an "amd_ags_x64.dll" somewhere? If it does, perhaps you'll get lucky with dxvk-ags. Been using it with Hitman 2 and while I can't say if it made it better since my benchmarks were the same before and after, it clearly hadn't made it worse.

EDIT2: If it does, you'll just have to go down the line until you find the version that works. The game won't load until you're using the correct version of ags.

[aufkrawall]

skeevy420 The flicker issue is a known bug of Polaris Linux driver with refreshrates >73Hz and dynamic VRAM clocking. Forcing VRAM into fixed states makes the flicker go away, but of course either wastes power or kills performance. Nothing else can be done, except waiting on AMD for a fix (they tried to several times, but it didn't work out). I prefer using 73Hz and still having fully dynamic clocking.

Regarding the HotS alt + tabbing performance penalty issue mentioned on the tkg tracker: I can't reproduce anymore, maybe related to recent DXVK commits. The game seems to be running absolutely fine now with older wine-staging commit + esync + default systemd values for DefaultLimitNOFILE.

[skeevy420]

Just ran the Miami benchmark in Hitman 2 three times. Since 4.7 staging and the dxvk-ags 5.0 release and the corresponding dxvk git commit, now using everything from git master from an hour or two ago, it went from everything maxed out with medium shadows getting 30.2 fps to everything maxed out including shadows getting 36 fps (note: averages reported at the end & motion blur was off for both because fuck motion blur, it physically makes me sick). Pretty damn cool that in a month that that I gained a 6 fps average while increasing the graphical settings.

With earlier than DXVK 1.2.1 release & wine staging ~4.8r12 l played the game with reduced settings of HIgh LOD, Medium Shadows, and SSAO & SS Shadows off which resulted in 37.1 fps in reported at the end of the benchmark. All with Mesa 19.0.x and radv. I've been playing it maxed out for the past week.

Here's what's really cool. AMDVLK release 2019-4-21, using the same Wine stuff all lining up aroung the dxvk-ags 5.0 release as above, was getting 36.6 fps with my reduced settings. I just tested AMDVLK release "update api version to 1.0.108" from two days ago with all ultra settings, no motion blur and I'm getting 36 fps, the exact same results as radv. Each has their own little quirks and slowdowns in the benchmark, but it's neat that they average out the same. Everything done with dual Westmere x5687's, an RX 580 4G, and 48GB DDR3-1333 ram.

A big thanks to everyone involved in all these projects like dxvk, wine/staging, faudio, proton, & more; and Tk-Glitch for wrapping it all up and making it so easy to try all sorts of different variants and combinations until I can get dialed in just right...that's a really big help for me.

EDIT: Thought I should come back and update that, in game and playing Hitman 2, AMDVLK skips and lags pretty bad and RADV doesn't with the maxed settings. While they're equal on my PC in the benchmarks, in game they're not and RADV is the clear winner. That said, with my lowered settings with the older stuff, there really wasn't much of a difference in game so AMDVLK might just not like the extra shadows or something...I want to play my game so I'm not going to investigate it...

[skeevy420]

skeevy420 The flicker issue is a known bug of Polaris Linux driver with refreshrates >73Hz and dynamic VRAM clocking. Forcing VRAM into fixed states makes the flicker go away, but of course either wastes power or kills performance. Nothing else can be done, except waiting on AMD for a fix (they tried to several times, but it didn't work out). I prefer using 73Hz and still having fully dynamic clocking.

Regarding the HotS alt + tabbing performance penalty issue mentioned on the tkg tracker: I can't reproduce anymore, maybe related to recent DXVK commits. The game seems to be running absolutely fine now with older wine-staging commit + esync + default systemd values for DefaultLimitNOFILE.

Out of curiosity, do you oc/uv your card? I'm just wondering if using a workaround like "set state 0 to state 1's values and using that starting point to try to figure out what the real low mhz you need for >73hz should be" could work. Might even get lucky and can increase the mhz w/o the mv. Just saying I would be that surprised if slightly ocing the low end "fixed" it.

Sucks the latest stuff isn't working out for you. I'm having great results currently. My only real "issue" is it still detects my PS4 controller as a 360 controller...can't tell ya how many times I've hit the wrong X button.