Vulkan pipeline cache configuration for first-launch shader compile stutter

Answer for this setup

Yes. Under Vulkan 1.3 it is spec-legal to create a VkPipelineCache from a disk blob loaded in a previous run and use that cache object for vkCreateGraphicsPipelines with VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT set. If the cache cannot satisfy the pipeline without compilation, the call can return VK_ERROR_PIPELINE_COMPILE_REQUIRED instead of blocking the thread for shader compilation. That lets you defer the compile or fall back to a simpler path for that frame.

Cache validation is required before reuse. A single VkPipelineCache can be shared across all pipeline families; the spec imposes no restriction. Empirically a shared cache tends to increase reuse of compiled shader stages, while per-family caches reduce size and fragmentation. The choice should be driven by profiling on your target hardware.

Confirmed facts vs likely behavior

Confirmed: Vulkan 1.3 core promotes VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT and VK_PIPELINE_CREATE_EAGER_PIPELINE_COMPILE_BIT. vkGetPipelineCacheHeaderVersion and vkGetPipelineCacheHeaderData are core in 1.3 and return device UUID, vendor ID, driver version and a pipeline cache UUID that changes with driver updates. Pipeline cache blobs are opaque and not portable across drivers or hardware versions.

Likely / driver dependent: VK_PIPELINE_CREATE_EAGER_PIPELINE_COMPILE_BIT is advisory. Drivers may still compile lazily. Combining it with FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT does not guarantee eager compilation, it only gives you a non-blocking error path when a compile would be required. Pre-1.3 devices expose the same flags via VK_KHR_pipeline_cache_control when available, but older drivers may ignore them.

Steps needed for this case

1. Validate before loading. On startup, query the current physical device: vkGetPhysicalDeviceProperties, vkGetDeviceUUID, vkGetDriverVersion. If you have a saved blob, create a temporary VkPipelineCache with pInitialData pointing to the blob, then call vkGetPipelineCacheHeaderData and compare device UUID, vendor ID, driver version and cache UUID with the current device. Discard the blob on any mismatch.
2. Load a validated cache. Create the persistent VkPipelineCache with the validated blob as pInitialData. Keep one cache object for the process if you want maximum reuse. Separate caches per family are allowed but require extra bookkeeping.
3. Create pipelines with non-blocking control. Set VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT on vkCreateGraphicsPipelines. Optionally also set VK_PIPELINE_CREATE_EAGER_PIPELINE_COMPILE_BIT where you want the driver to attempt eager work. Handle VK_ERROR_PIPELINE_COMPILE_REQUIRED by deferring creation to a worker thread or using a fallback pipeline.
4. Persist after use. After a successful creation session, call vkGetPipelineCacheData, write the blob to disk keyed by device UUID + driver version + vendor ID. Do not reuse a blob across different GPUs.

Verification you can run now: load a cached blob, validate header fields against vkGetDeviceUUID and vkGetPhysicalDeviceProperties, create a pipeline with FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT and confirm the return code on a cache miss, measure first-frame time with and without the flag, and profile hit rate with a single shared cache versus per-family caches.

One missing detail that changes the recommendation: do you need to support devices that only expose VK_KHR_pipeline_cache_control and not Vulkan 1.3 core? If yes, flag availability must be queried at runtime and fallback handling for drivers that ignore the flags is required.