#Pipeline cache takes 40 seconds to load on state restore

16 messages · Page 1 of 1 (latest)

whole gale
#

MacOS/Vulcan/Pre-release.

So I know the pipeline cache (the shaders, I assume?) on vulcan is supposed to be persistent in the new pre-release, but I was puzzled why it takes about 40s to load the pipeline cache when restoring a saved state. It shows there are over 50k items it's loading. Having such an enormous delay loading a saved state severely reduces the usefulness of saved states. Is this expected behaviour? Have I encountered a degenerate case with the game I'm playing and there aren't usually this many shaders? I'm playing Link Between Worlds.

shut prawn
whole gale
#

Yes, I didn't realize at first that it also takes that long when launching the game.

#

For now I've turned off the disk cache, but it was nice avoiding a lot of the stuttering when using it. I don't have a huge amount of time to play so I'm an unrepentant save-scummer and use save states a lot.

whole gale
#

So, I tried Monster Hunter 4 Ultimate and while I'm getting similar loading performance per-shader, the number of shaders (so far) is less than 1/10th of LBW. What's confusing, though, is that the shaders seem to be, on average, less than 1K each, and they're (presumably) pre-compiled and in the most efficient form to be used by the emulator (because otherwise why bother caching them), and yet they take about 1.5ms each to load. My Zelda shader pipeline file is 13.3Mb, but that's taking 40s to load. Meanwhile, with the shader disk cache turned off, I can load an entire saved state (about 25Mb) in less than 1/2s. Is this expected behaviour?

whole gale
#

Another thing: Why does the shader cache have to be reloaded when loading saved state? Shaders can't be state dependent or they would need to have a completely separate copy of the shader cache for each saved state.

shut prawn
# whole gale So, I tried Monster Hunter 4 Ultimate and while I'm getting similar loading perf...

try with the latest artifact from master, see if it improves things. But maybe it's just moltenvk being slow and not related to file IO.
https://github.com/azahar-emu/azahar/actions/runs/22328913279

GitHub

An open-source 3DS emulator project based on Citra. - cmake: Only add catch2 library if ENABLE_TESTS is enabled · azahar-emu/azahar@d721cbe

#

having a log would also be useful to see which configuration you have

shut prawn
whole gale
#

Nope, downloaded the build artifact, cleared the existing shader cache and played for a bit to rebuild part of the cache and I see approximately the same shader loading performance.

#

That's a shame that state loads require a complete clearing/reloading of the shader cache because waiting to initially load the game would worth it for the improvement of game performance, but for a shader-heavy game like LBT it's not worth it when using saved-states. Might be worth adding a note on the configuration GUI warning that it's very slow on the Mac.

#

That all said, I really appreciate the very solid Mac support!

#

I know a lot of developers of cross-platform gaming stuff don't always have ready access to Mac hardware to test on, so if there's a major change you'd like help testing with, feel free to reach out and I'd be happy to do what I can. I have an extensive professional software development background, just not in games.

#

Incidentally, while I can see from the log there is version compatibility checking for saved states, there doesn't seem to be for the shader cache, and when it's trying to load incompatible shaders from a different version it seems to just hang indefinitely while attempting to load in the pipeline. This happened when I switched from stable to pre-release and again when I switched from pre-release to the nightly you pointed me at.

whole gale
#

One thing I just noticed: If I play the game for a few seconds, save state and reload immediately, hundreds of new shaders get added to the cache. In those few seconds of playing, I'm just idle. The cache appears to just grow unbounded, implying (from my limited understanding of it) that either the game is constantly generating completely unique shaders on the fly (seems unlikely), or that the shader component is failing to find existing shaders in the cache and they are actually almost all duplicates. This might actually be the root problem, since if there were only a few hundred shaders, the loading performance wouldn't matter.