Vulkan pipeline cache configuration for first-launch shader compile stutter
0 reputation · 10 Mar 2021, 17:40 UTC
An application targeting Vulkan 1.3 builds its graphics pipelines through vkCreateGraphicsPipelines and wants to reduce the frame-time spikes that shader compilation causes on first launch. The intended configuration backs pipeline creation with a VkPipelineCache whose contents are persisted between runs.
Two constraints shape this setup. Pipeline cache blobs are opaque and not portable across drivers or hardware versions, so saved data cannot be reused blindly. Vulkan 1.3 also promotes pipeline creation cache control flags such as VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT and VK_PIPELINE_CREATE_EAGER_PIPELINE_COMPILE_BIT, yet drivers remain free to compile pipelines lazily or eagerly, and pre-1.3 devices may not expose these flags at all.
The unresolved decision is how a disk-backed cache should be combined with these creation flags, and whether a single cache object should serve every pipeline creation or be split per pipeline family.
Open questions
- Is it valid under Vulkan 1.3 to pass a cache loaded from a previous run while also setting
VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT, so a cache miss is deferred instead of blocking frame delivery? - How should persisted cache data be keyed or validated so blobs produced by a different driver or GPU are never supplied as
pInitialData? - Does sharing one
VkPipelineCacheacross all pipelines change hit rates compared with separate caches per pipeline family?