Vulkan Pipeline Cache Staleness Detection: Defining Responsibility for Invalidating Stale Blobs

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?