Vulkan Pipeline Cache Staleness Detection: Defining Responsibility for Invalidating Stale Blobs
0 reputation · 02 Jun 2023, 04:23 UTC
0 reputation · 02 Jun 2023, 04:23 UTC
The Vulkan specification leaves the handling of stale or incompatible VkPipelineCache data to the implementation, stating only that implementations should reject or ignore cache blobs that do not match the current device.
Applications can persist cache data and reuse it across runs, but driver updates may change the internal cache format, making previously valid blobs stale.
The unresolved decision is whether the application should version its own stored cache blobs (for example, by keying on VkPhysicalDeviceProperties::pipelineCacheUUID) or rely on the driver to detect and discard stale entries.
This creates uncertainty about when a cache hit is safe and when an application must expect a pipeline‑compile stall.
Should the application treat a mismatch in VkPhysicalDeviceProperties::pipelineCacheUUID as sufficient cause to discard its persisted cache?
Can VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT be relied upon to detect stale‑cache misses across all vendors?
Is there a recommended versioning strategy that combines pipelineCacheUUID with driver version to minimize unnecessary recompilation?
32275 reputation · 02 Jun 2023, 07:32 UTC
The application should treat a mismatch in VkPhysicalDeviceProperties::pipelineCacheUUID as a sufficient cause to discard its persisted cache. While the Vulkan specification requires drivers to ignore or reject incompatible blobs, application-side invalidation prevents wasting I/O and memory on data the driver will inevitably discard.
Responsibility for staleness detection is shared, but serves different purposes:
vkCreatePipelineCache. If the blob is incompatible, the driver will ignore the data, effectively treating it as an empty cache.pipelineCacheUUID, the application avoids loading large, useless blobs from disk and can proactively manage storage.This bit (introduced in Vulkan 1.3 or via VK_EXT_pipeline_creation_cache_control) cannot be relied upon as a universal staleness detector. It indicates whether a pipeline must be compiled, but it does not specify why. A failure could be caused by a stale cache, but it could also be caused by a missing entry for a specific pipeline state that was never cached. Furthermore, this feature must be explicitly enabled and is not supported by all legacy implementations.
To minimize unnecessary recompilation while ensuring stability, use a composite key for your persisted cache files. Do not rely on the UUID alone, as some drivers may not update the UUID for minor patches that still maintain binary compatibility, or conversely, may change it for updates that could have been compatible.
Recommended Key Components:
VkPhysicalDeviceProperties::pipelineCacheUUID: The primary hardware/driver compatibility signal.To verify your invalidation logic, perform the following:
pipelineCacheUUID and driver version at startup and compare them against the metadata stored with your cache file.vkCreateGraphicsPipelines with a warm cache versus a deliberately invalidated cache to confirm the driver is actually utilizing the blob.VkPhysicalDeviceProperties to ensure pipelineCreationCacheControl is supported before attempting to use FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT.Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.