protonscr

Hot Lava freeze on startup

dxvkclosed bug
doitsujin/dxvk#477 · opened 2018-07-05 by Lahvuun · updated 2018-07-08 · 12 comments · github
1 matching comments, n / p to jump
LLahvuun 2018-07-05 github

All I can see is the initial splash art that says "loading". Nothing happens after this: no crash, no messages in terminal, just a frozen window. The game works with wined3d.

Software information

hotlava.exe, steam link.
Settings were set to "potato".

System information

  • GPU: Radeon RX 560
  • Driver: 18.2.0-devel (git-99c6cae227)
  • Wine version: 3.11 staging+pba
  • DXVK version: 0.61

Apitrace file(s)

apitrace

Log files

Ddoitsujin maintainer 2018-07-05 github

I'm not sure I understand what your apitrace is supposed to do, as it only contains two frames. Can you make one that goes past the loading screen?

Freezing issues are usually caused by some weird interaction between the app and d3d, which almost certainly means that I won't be able to fix this issue.

LLahvuun 2018-07-05 github

My bad. The game actually closes itself and starts the Steam client, so apitrace only got so far. This one should be better.

Edit:

Freezing issues are usually caused by some weird interaction between the app and d3d, which almost certainly means that I won't be able to fix this issue.

I'm not sure if it matters, but it's a Unity game. I think other Unity games play well with DXVK?

Edit 2:
Sorry about accidentally closing, I'm not very good with GitHub.

Ddoitsujin maintainer 2018-07-05 github

I think other Unity games play well with DXVK?

Unity Engine requires stream output for pretty much everything, but i can't see any of that in your logs so that shouldn't be the issue here.

Ddoitsujin maintainer 2018-07-05 github

Can you check htop while trying to start the game and check whether there is a significant amount of CPU load?

I can't think of anything wrong with the updated trace, it replays fine on my end, but I did notice that the game compiles over 9000 shaders and a total of over 10000 Vulkan pipelines during the first few frames, which takes several minutes on my Ryzen 2700X. While this sure is an annoyance, there's not much I can do about it.

LLahvuun 2018-07-05 github

Yes, the game uses 100% of a core. Looks like it uses only one at this stage.

I am not sure if I am doing this right, but my own retrace of apitrace crashes when using DXVK. Could this be a driver issue?

Ddoitsujin maintainer 2018-07-05 github

Yes, the game uses 100% of a core. Looks like it uses only one at this stage.

That would be expected. You can set DXVK_LOG_LEVEL=debug to monitor pipeline compilation, unfortunately it's very slow (especially if you built mesa in debug mode).

The crash is not a driver issue. I guess you recorded the trace on Wine, which implements some interfaces not present in DXVK, and that requires some hacks to make work.

I got this trace from another user though, you should be able to replay it out of the box.

By the way, since you're running mesa-git and llvm-svn, I recommend updating both now if you haven't already - there was a bit of an LLVM issue with my build from yesterday causing pipeline compilation failures, but it looks like it's fixed.

LLahvuun 2018-07-05 github

OK. I'm gonna rebuild these and report back.

Provided retrace is not crashing indeed, but I am not seeing any frames either. The retrace process is taking up a whole core as well.

there was a bit of an LLVM issue with my build from yesterday causing pipeline compilation failures

I'm not sure if that's the case here, since other games run just fine on my setup.

Meanwhile, I tried using placeholder shaders, as well as bumping the amount of pipecompiler threads to 8. The game is now using ~350% of CPU. After about a minute I managed to get into the game, with a couple elements drawn.

Ddoitsujin maintainer 2018-07-05 github

Provided retrace is not crashing indeed, but I am not seeing any frames either.

As mentioned it can take several minutes even on a fast CPU. The PoE hack is known to break a lot of games.

LLahvuun 2018-07-05 github

No, I'm using the binary 0.61 release for all my tests. But after you posted that it's basically just a huge amount of shader compiling, I remembered this hack and thought it would make sense to try it.

By the way, is this what it would look like to precompile all shaders at the start of a game? Multiple minutes of waiting, just for the stutter-less experience?

Ddoitsujin maintainer 2018-07-05 github

That's basically what the game does, yes. If the shader combinations and pipeline state were known in advance, it would be possible to compile pipelines in parallel (i.e. use all available CPU cores with near-perfect scaling), but with the D3D11 design that unfortunately isn't possible.

Ffrostworx 2018-07-06 github

I can confirm that the game works fine here after waiting some minutes.
the intro video isn't visible, but can be skipped. arch linux with dxvk git master, nvidia blob 396.24.02 with a gtx 980ti.

LLahvuun 2018-07-06 github

I updated llvm and mesa and yes, the game loads and works reasonably well. My bad for not realizing the game was simply taking this long to load. Please close the issue if there's nothing that can be done.

I'm not very familiar with how graphics work, but, in principle, what is stopping me from hacking up DXVK to store these initially compiled shaders and pipelines onto a disk, and load them when I restart the game? Do they change significantly with each restart? Nevermind, I found #261.

Launch options