Vulkan pipeline cache invalidation: UUID comparison versus embedded metadata

An application serializes VkPipelineCache data between runs to accelerate pipeline creation. The Vulkan specification guarantees that incompatible or stale initial data passed to vkCreatePipelineCache is silently ignored, treating the cache as empty. The only staleness signal exposed by the API is the pipelineCacheUUID returned in the cache header from vkGetPipelineCacheData, which can be compared against VkPhysicalDeviceProperties::pipelineCacheUUID.

However, the specification does not define when the UUID changes — driver updates, device swaps, or other implementation-defined events may alter it — and it provides no guarantee that cache data remains valid across driver versions. Pipeline creation feedback (VK_KHR_pipeline_creation_feedback, core in Vulkan 1.3) reports an application cache-hit flag, but its semantics are advisory and vary across drivers.

Given that the spec only promises incompatible data is ignored rather than validated, the open decision is whether comparing the UUID alone is sufficient for cache invalidation or whether the application should embed its own metadata — such as driver version, build ID, or SPIR-V module hashes — inside the serialized blob to detect subtle incompatibilities that the UUID does not capture.

• Is UUID comparison the intended and sufficient invalidation strategy per the specification, or do implementations expect applications to carry additional versioning?
• Are there documented cases where a matching UUID still yields incorrect pipeline compilation results?
• What metadata scheme do production engines use to achieve reliable cache invalidation across driver updates?