I noticed that for some Vulkan apps, the AMD driver's pipeline cache files located in %LocalAppData%/AMD/VkCache aren't reused and instead a new file with a _1, _2, _3, ... suffix is created frequently.
This will cause long shader compilation times, as everytime a cache file for a Vulkan application in %LocalAppData%/AMD/VkCache gets invalidated, all shaders have to be completely rebuilt again.
I investigated this problem and found that this issue only happens, when vkCreateGraphicsPipelines/vkCreateComputePipelines is called simultaneously by multiple threads.
It seems like the pipeline cache is not properly synchronized, despite the vkCreate*Pipelines calls should be thread-safe, according to the Vulkan specification.
The same corruption might happen with a custom pipeline cache (VkPipelineCache) created with vkCreatePipelineCache that gets supplied to parallel vkCreate*Pipelines calls, but I am not sure.
The Vulkan specification states that all calls, that modify the VkPipelineCache object, should be synchronized internally by the Vulkan driver, unless the flag VK_PIPELINE_CACHE_CREATE_EXTERNALLY_SYNCHRONIZED_BIT is set.
Noticeably the final size of the cache (obtained with vkGetPipelineCacheData) was slightly different every time in my test runs even the same set of shaders/pipelines were loaded. Maybe though it just could be because of different alignments, depending in which order the pipelines were built.
At least this custom cache can still be reused by the Vulkan application.
It seems older driver don't have this problem and 22.2.1 introduced it.
This bug affects at least GCN cards on Windows 10/11, but I guess it affects all AMD graphics cards.
