[Linux] Vulkan/OGL shader cache is rebuilt on every game launch

[Shakes]

ISSUE

Vulkan and OpenGL shader caches that Steam generates with its pre-caching feature are ignored and rebuilt at every game launch.

OS

Linux Mint 19.3 MATE

Kernel 5.3.0-23-generic
GPU: NVIDIA RTX 2060 KO Ultra
CPU: Intel i5-4590

STEPS

1. Make sure "shader pre-caching" is enabled in Steam's settings. "Allow background processing of Vulkan shaders" can optionally be enabled as well.
   
2. Launch any game where Steam can generate the shader cache before the game actually runs
   
3. Allow the game to run, then quit that game
   
4. Launch the game again.

RESULTS

Steam rebuilds the game's shader cache even though nothing has changed that would require a new cache to be built. Additionally, skipping rebuilding the new cache still results in invalidation of the old one meaning in-game stutters due to shader caching are unavoidable.

EXPECTED

Steam should launch the game and use the already-existing shader cache.

[Shakes]

Addendum: I found after several hours of manually building a shader cache for the only game I play regularly, that it appears that if the X server is restarted at any point, any shader caches that were built manually (e.g., without any sort of pre-caching) disappear into the void and need to be rebuilt yet again. Does this mean that Steam's shader caching system is only compiling into Xorg's working memory? Surely this is a huge oversight and not a symptom of my hardware configuration? This doesn't explain why I need to pre-cache at every launch, but is an unforeseen hole in the workaround I was attempting that unfortunately means the game becomes nigh unplayable after any restarts or Xorg resets/crashes.

Surely, I can't be the only person with this problem? It seems there's a GitHub issue[github.com] on this, but it's not getting any attention or even an attempt to diagnose the underlying issue. I'm going to have to drop out of the beta for the time being as this is ridiculous and incredibly annoying.

Edit: Oh lovely, even in the stable branch, the pre-cache is useless. Stutters out the wazoo even after waiting 20 minutes for shaders to compile.

[*BURRRP!*]

My issue(s); Using iotop, I'd see a process from Steam (steam [CJobMgr::m_Work]) taking up nearly 100% disk I/O process throughput (mostly read rate) and the Steam client doesn't appear to be validating anything or processing Vulkan shaders (the usual culprits for such heavy background disk usage from Steam). Once this is the case (this process is running) I have to KILL Steam as it causes severe slowdowns of the system where anything requires disk I/O as it hasn't mattered how long I let the process run it doesn't end on its own. Exiting/quitting Steam is of no avail, the interface will disappear, the icon stays in the tray and the process continues to run.

My only way to prevent this was to disable Vulkan Shader pre-caching entirely, clear Downloads and restart Steam. Right now I'm not seeing the process run at all. It usually came up after playing a more graphically intense title like Battlefield 1 or Red Dead 2, then it was time to KILL Steam and restart it. A real PIA.

I'm on Manjaro KDE so, of course, no official support.

[KaiausderKiste]

Okay, so this issue is old and has just been ignored. Don't know what to think about that.

[Shakes]

I believe when I originally wrote this, that the issue was actually a problem with NVIDIA drivers and not so much a problem with Steam itself.

In the current beta, if you let the shader cache get built, everything should be okay. That is, until you restart Steam or log out and then it rebuilds it again. The label for the box that pops up always says "vulkan" even if the game already uses OGL, like TF2 for instance.

This is problematic because skipping building the cache for TF2 results in huge graphical errors, like models being invisible or not loading textures in. Normally, the game would build its own internal cache at startup if it needed to, but for the last few builds of Steam beta, Steam itself has been trying to handle it.