Driver invalidates compiled shaders and forces recompilation on every boot

[AnotherUser97]

I was told to file an issue here after approaching the Discord support.

System specs: AMD Ryzen 5 3550H with Radeon Vega Gfx AMD Radeon RX 560X (notebook GPU) 8 GB DDR4 RAM 25000 MB Page File 512 GB internal NVMe SSD Storage Windows 11 Enterprise 64-bit (Build 22000.739) AMD Radeon Software 22.5.1

Issue: Precompiled shaders located at %LocalAppData%\AMD\VkCache are invalidated every time yuzu is launched. This results in yuzu recompiling all the shaders again causing long load times at boot. Initially 2 1 KB .parc files are created when yuzu is first launched. After initial compilation of shaders, one of the files stores all of the compiled shaders. If yuzu is launched again, a duplicate of this file is created with an _1 at the end of the file name. This file then stores the shaders which are forced to be recompiled. This happens on every boot and the files keep stacking with _2, _3, _4 and so on at the end of the file name. Refer: https://media.discordapp.net/attachments/400106910231035904/989520037608063006/unknown.png

Expected behaviour: yuzu loads the precompiled shaders stored in the .parc file instead of creating a new one.

Possible solutions tried (all failed):

1. If the _1 file is replaced with the file which already has shaders (before launching a game), the _1 file gets invalidated and creates an _2 file (this sequence can be extrapolated as the files keep stacking)
2. Clearing shader cache from AMD Software does not resolve the issue
3. Adding yuzu as a profile in AMD Software does not resolve the issue (deleting the cache after adding the profile does not fix it either)
4. Creating a completely new set of shaders from scratch does not resolve the issue
5. Creating a new user in Windows temporarily solves the issue as long as only one game is run and built shaders for. If another game is launched and the shaders are to be built for it, the issue resurfaces. The issue persists even after clearing the cache if another game is run.
6. Downgrading the drivers to an earlier version does not resolve the issue
7. Upgrading to the beta drivers (22.5.2 or 22.6.1) does not resolve the issue
8. Removing the drivers using DDU in Safe Mode and then reinstalling the drivers does not resolve the issue
9. Downgrading yuzu to a much older build (say 8XX) does not resolve the issue
10. Removing yuzu's configuration file and starting fresh does not resolve the issue
11. Completely clearing all of yuzu's data from %AppData% and setting it up from scratch does not resolve the issue
12. Running yuzu as Administrator does not resolve the issue
13. Resetting the Windows install does not resolve the issue

Other observations:

1. Checking if the .parc file was locked using Resource Monitor or Process Explorer reveals the file is not locked by any process
2. No other emulators / games show this issue. Tested with Dolphin, Cemu and Ryujinx
3. A user on the Discord support speculated yuzu might not have the right read permissions for the compiled shader cache, not sure if this is correct
4. If the .parc file is 1 KB in size, a new file is not forced to be created. Otherwise, it is forced to create a duplicate and recompile the shaders.

Log file (of shaders being forcefully rebuilt): https://drive.google.com/file/d/190V3G_a7sD7bHrLqxJnASyQ6ttis8dcP/view?usp=sharing

[AnotherUser97]

UPDATE: Seems like it is not restricted to "working when only 1 game is being run". It CAN store multiple games' shader caches in a single .parc file without duplication TILL the .parc file reaches a certain file size. If the file size created is larger than this size, it starts duplicating. I don't know what exactly this file size is but it seems to be random and changes every now and then (it is sometimes 6-7 MB, sometimes 16-17 MB, sometimes 19-20 MB). Now I have absolutely no idea what could be the cause of this issue, but I've narrowed it down to file size at least.

[AnotherUser97]

UPDATE 2: Seems to be fixed by downgrading to 21.10.1 (I think this is the earliest driver compatible with Windows 11). Will update if the issue resurfaces, but for now it seems to have been a driver issue.

[AnotherUser97]

UPDATE 3: Issue does not appear on any drivers up to 22.1.2. It starts breaking on 22.2.1 and isn't fixed even on 22.6.1. Notably, 22.2.1 introduced Vulkan 1.3 (maybe the bug was introduced during this implementation). Thus, the current workaround is to sit on 22.1.2 and patiently wait till a future version fixes the issue.