Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

the async patch partially breaks the dxvk-cache #55

Open
JustinSpedding opened this issue Oct 13, 2022 · 12 comments
Open

the async patch partially breaks the dxvk-cache #55

JustinSpedding opened this issue Oct 13, 2022 · 12 comments

Comments

@JustinSpedding
Copy link

I've noticed a problem with the dxvk-async patches affecting the dxvk cache.

Many games stutter with shader compilation in the same spots after restarting the game when they should not stutter in those same places the second time due to the shader cache.

While I have noticed this with several games, I will use The Quarry running in DX11 mode as an example. The following occurs when DXVK_ASYNC=1:

  • I load up the game
  • I press continue
  • The scene starts rendering, but things look off because it is compiling many shaders for the first time
  • I return to the main menu, then press continue again
  • This time, the scene renders correctly immediately because the shaders are already compiled
  • I close the game entirely, load up the game again, and press continue again
  • The scene starts rendering, but things look off because it is compiling many shaders
  • I look at the last modified timestamp on the .dxvk-cache file, and it did not get updated at all with the new shaders during the previous play session

The expected result is that it should cache shaders between stopping and restarting the game.

When DXVK_ASYNC=0, it updates the .dxvk-cache file with the new shaders that it compiles synchronously.

What is strange is that, if I delete the .dxvk-cache file entirely and start it back up again with async turned on, it will make a new cache and start writing some of the shaders to disk. But, it stops writing any new shaders shortly after it turns on.

For instance, when I run the first ~30 of the scene from The Quarry that I used to test with no pre-existing .dxvk-cache file, it generates a new cache of size 68kB when async is off and 21kB when async is on. So it writes at least some of the shaders, but not all of them.

My setup used to test:

  • Ryzen 7 5800X
  • RTX 3080 (515.76 driver)
  • Fedora 36
  • GE-Proton7-36
  • command used to launch The Quarry from steam: DXVK_HUD=compiler DXVK_ASYNC=1 WINEFSYNC=1 bash -c 'exec "${@/2KLauncher\/LauncherPatcher.exe/TheQuarry.exe}"' -- %command% -UseAllAvailableCores (The weird bash command it to work around the game launcher. The env variables are the important part.)
@Sporif
Copy link
Owner

Sporif commented Oct 13, 2022

Yes, the state cache has always been an issue with dxvk-async, and I don't understand it enough to fix it. Personally I don't use dxvk async any more, as stock dxvk with its new GraphicsPipelineLibrary feature is good enough for me. But that requires a vulkan dev driver or the just released 520.56.06.

But it shouldn't spend time recompiling the same shaders on the next startup, that should be in the gpu shader cache. If you can find where that is, check if it's increasing in size. It's possible it's reaching the stock limit, which can be disabled with __GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1. Also, theoretically it should be fine to disable the state cache with DXVK_STATE_CACHE=disable and still have no stutters.

@ghost
Copy link

ghost commented Oct 19, 2022

@Sporif

So what is need to done to get "GraphicsPipelineLibrary" used?

Is Nvidia 520.56.06 driver and DXVK 1.10.3 (latest stable) enough? Or do need to do something else, or need wait for newer DXVK release?

Edit: yeah heard it requires much newer DXVK version, from master not stable releases, so may need wait quite while... using wineGE-custom lutris builds, so yeah need DXVK build from github, don't know how to build stuff by myself.

@Rosentti
Copy link

For steam games you can use proton experimental. You might need to enable the experimental dev branch for it though.

@Blisto91
Copy link

Blisto91 commented Oct 19, 2022

@runboy93 you can download pre built master builds from this page https://github.com/doitsujin/dxvk/actions/workflows/artifacts.yml?query=branch%3Amaster

If using proton then regular experimental is enough.

@ghost
Copy link

ghost commented Oct 21, 2022

@Blisto91

So got some random dev build from link you provided, what I do now with it? These are pre built right, is it simple now as using standard dxvk?

Yes, not my cup of tea stuff but want to test now as NVIDIA 520.56.06 driver has that feature added.

So now I don't need "DXVK_ASYNC=1" anymore right?

Is there to test to see how it's working, other than lag / not lagging?

@Blisto91
Copy link

Blisto91 commented Oct 23, 2022

In your dxvk logs you should see a line saying info: DXVK: Graphics pipeline libraries supported or when you have full hud on with DXVK_HUD=full (or just DXVK_HUD=pipelines i think) there should be a line called graphics shaders. If the game does it well then it should go up already in the main menu or during loading.

Don't use DXVK_ASYNC=1 with it no if you want to use GPL

@begin-theadventure
Copy link

Don't use DXVK_ASYNC=1 with it no if you want to use GPL

Async isn't even in the main repo, so it just won't do anything.

@Blisto91
Copy link

Blisto91 commented Oct 23, 2022

No but async versions based on master contains both. The variable disables GPL in those. (Not directed directly at the person above as i guess they use the link i provided. Just as general fyi)

@Ryusennin
Copy link

For what it's worth: while GraphicsPipelineLibrary is an improvement, stuttering is still an issue with a game like AC Origins, in which the async patch definitely performs seamless and much better than the regular build, even when deleting the cache file.

@ghost
Copy link

ghost commented Oct 27, 2022

Yeah, I tried GPL shortly with wotlk classic and was disappointed, basically stuttering each time character moves / do anything ("Auto" value on dxvk.conf compiles stuff on background). Same setting on dxvk async, nothing, it just works.

Game / engine specific results maybe, but yeah I would like to see async patch too in future (for 1.10.x dxvk, which may continue to get small updates), sad if he stop updating this :(

GloriousEggroll added a commit to GloriousEggroll/proton-ge-custom that referenced this issue Jan 18, 2023
Upstream DXVK has implemented the GraphicsPipelineLibrary (GPL) back in August, which takes over dxvk-async's job:

https://www.khronos.org/blog/reducing-draw-time-hitching-with-vk-ext-graphics-pipeline-library
doitsujin/dxvk#2798

Driver support for Nvidia was added in version 515.49.10:
https://developer.nvidia.com/vulkan-driver

Driver support for AMD/RADV was added in August 2022 and is an ongoing WIP:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17542

Per the above, it can be exposed for testing on AMD/RADV via:
RADV_PERFTEST=gpl

dxvk-async now causes problems with the dxvk-cache, which is not something new users may know how to clear:
Sporif/dxvk-async#55

In light of the above, in addition to the current rebase still not working properly, I am removing the dxvk-async patch from Proton-GE.

RIP dxvk-async 2018-2023
@luigicara
Copy link

Hi, do you know if I started building cache with dxvk async on and now I remove it, do my cache is corrupted and not compling shaders the correct way? Or simply I remove the launch options from steam and it starts compiling the shaders again?

@Vrashabh-Sontakke
Copy link

@Sporif , After reading your suggestion at the top, should I keep shader pre caching on and allow background processing of vulkan shaders in steam settings while I have nvidia-vulkan drivers and latest dxvk 2.3 installed.
And here are my current launch options in steam (Apex Legends) : gamemoderun %command% -preload -dev -novid -high
Any other settings or launch options or environment variables, would you please recommend ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants