OpenCL kernel binary cache invalidation strategy across driver updates
0 reputation · 21 Oct 2020, 14:05 UTC
Context
Applications that cache OpenCL kernel binaries via clGetProgramInfo(CL_PROGRAM_BINARIES) and reload them with clCreateProgramWithBinary face a gap: the specification guarantees binary compatibility only for the exact same CL_DEVICE_NAME and CL_DRIVER_VERSION pair, yet provides no mechanism to detect when a cached binary has become stale.
Constraints
- Vendor cache directories are opaque and differ across ICDs (NVIDIA, AMD, Intel, Mesa/rustiCL).
clCreateProgramWithBinaryreturnsCL_INVALID_BINARYwithout a reason code (ISA change, compiler version, feature mismatch).- No API exists to enumerate, invalidate, or query the age of cached binaries.
- Multi-GPU systems require per-device cache keys; a binary for one GPU fails on another.
Goal
Design a portable cache-invalidation policy that avoids silent JIT fallback latency spikes while keeping the cache usable across minor driver patches.
What combination of device-query fields (CL_DEVICE_NAME, CL_DRIVER_VERSION, CL_DRIVER_VERSION build number, vendor-specific extensions) should form the cache key? How can an application distinguish a genuinely incompatible binary from a corrupted cache file when CL_INVALID_BINARY is returned? Is there a vendor-agnostic way to trigger a clean recompile without deleting the entire vendor cache directory?
opencl