search

ValveSoftware / Proton

Compatibility tool for Steam Play based on Wine and additional components
Other
23.48k stars 1.03k forks source link

Warhammer: Chaosbane (774241) #5632

Open SeraphisCain opened 2 years ago

SeraphisCain commented 2 years ago

Compatibility Report

System Information

I confirm:

steam-774241.zip

Symptoms:

The game runs relatively well in most areas, but in the cemetery area (roughly 2 hours into the game), the framerate drops from 60 into the 10s/20s and GPU usage jumps from the usual 55-60% to 100%. Moving back to the hub area causes the framerate to get stuck at ~30 FPS until reboot. Using PROTON_USE_WINED3D fixes this issue completely, but also causes the HUD to disappear on 7.0-1. Proton 5.0-10 + PROTON_USE_WINED3D eliminates the framerate issues with no HUD side-effects. I'm posting this here as it seems to possibly be a regression with newer Proton.

EDIT: Some more information after testing with more Proton versions:

Proton 5.13: Works the same as Proton 5.0, no discernible difference.

Proton 6.3: Problem areas drop from 60 to 30 FPS, but do not spike GPU usage to 100% as with Proton 7.0. HUD is not missing when using WineD3D.

Additionally, further testing on 7.0 with a new character reveals that the framerate and GPU issues actually start before the cemetery area. Perhaps I just wasn't looking for them at the time, or chalked it up to the game itself rather than Proton, but in outdoor areas (but not the hub area), the FPS drops noticeably (but not as bad as the cemetery) and GPU usage spikes to 100%. Using Proton 5.0 or 5.13 with WineD3D similarly eliminates the issues in these areas, as well.

Reproduction

Play the game until the cemetery section using Proton 7.0-1 or Experimental.

kisak-valve commented 2 years ago

Hello @SeraphisCain, it should be noted that PROTON_USE_WINED3D is not considered a supported runtime option. It would be more interesting to focus on what's happening with the game and DXVK on the default render path.

The symptoms you've described sounds like the game has run out of vram and the video driver has pushed part of the render hot path to system ram. Can you keep an eye on vram usage, and also check PCIe bandwidth utilization in NVIDIA's settings utility? We've seen the PCIe bandwidth utilization percentage jump up significantly when that scenario happens.

SeraphisCain commented 2 years ago

@kisak-valve Looks like you're spot on, here. Here's the GPU usage on 7.0-1. VRAM is full, GPU utilization 100%, PCIe bandwidth utilization at 73%:

image

Meanwhile, here's the GPU usage in the same area on 5.13 with PROTON_USE_WINED3D. VRAM at 93%, GPU utilization only 67%, and PCIe bandwidth utilization a mere 5%:

image

(Even though I know "recommended specs" aren't always accurate, to put it lightly, it should be noted that the game's recommended specs only list 2 GB of VRAM.)

EDIT: So I've noticed something else that's interesting. On Proton 7.0, VRAM usage in the hub city immediately jumps to 100% (3903 MB), though the framerate/GPU usage/PCIe bandwidth is unaffected. On 5.13 with WineD3D, VRAM usage in the hub is a much lower 62% (2417 MB).

nhkcon commented 2 years ago

System Information

I confirm:

Symptoms

Game crashes before the intro video.

Reproduction

always, just start the game and try to get to the main menu

steam-774241.zip

System Information

I confirm:

Symptoms

Game crashes between title screen and main window, either getting stuck showing the title screen or just showing a black screen.

Reproduction

always, just start the game and try to get to the main menu

steamdeck-774241.log.zip

On another system with nvidia card the game runs without issues, though I never looked at the fps. OS: Solus KERNEL: 5.14.21-210.current CPU: AMD Ryzen 5 1600X Six-Core GPU: NVIDIA GeForce GTX 1060 6GBGPU DRIVER: NVIDIA 510.54

hakzsam commented 2 years ago

@nhkcon Thanks for the great report, I can reproduce, I will investigate.

hakzsam commented 2 years ago

This seems a pretty complex problem to solve actually. In the mean time, you can workaround it with RADV_DEBUG=nocompute %command% or RADV_DEBUG=nongg %command%. Let me know if it works with that, thanks!

nhkcon commented 2 years ago

This seems a pretty complex problem to solve actually. In the mean time, you can workaround it with RADV_DEBUG=nocompute %command% or RADV_DEBUG=nongg %command%. Let me know if it works with that, thanks!

On the deck RADV_DEBUG=nocompute %command% helps and the game seem to run without issues in the short test I did. On the desktop none of those parameters help but I figured out the problem is related to my display resolution. At 5120x1440 the game always crashes, if I lower it down to 2560x1440 in the game's setting tool it works even without any of those parameters.

hakzsam commented 2 years ago

Yes, the problem on your desktop is different, the driver failed to allocate a texture which makes sense somehow given the large resolution you used.

Would be interesting to confirm that RADV_DEBUG=nongg on the Deck also fixes the GPU hang. Also if you find rendering glitches in the game, feel free to report here. Thanks a lot.

nhkcon commented 2 years ago

nongg also works to get the game running on the deck. Thanks for the quick workaround.

hakzsam commented 1 year ago

This issue should be fixed properly in Mesa main now https://gitlab.freedesktop.org/mesa/mesa/-/commit/26c8fedc1bb12fa8f3d6c646308f4b46756d77c7