OpenCL 3.0's Optional Capability Model: Reject Devices or Ship Fallback Kernels?

OpenCL 3.0 redefined the specification as a lean core aligned with OpenCL 1.2, making every post-1.2 capability optional and queryable per device. A host program can no longer treat a device that reports OpenCL 3.0 as guaranteed to provide behavior that was core in OpenCL 2.x.

The goal is a portable selection policy for a host application that enumerates platforms through the ICD and queries each device before committing to kernels. The relevant query surface — CL_PLATFORM_VERSION, CL_DEVICE_VERSION, CL_DEVICE_OPENCL_C_VERSION, and extension strings — is related but not interchangeable, and a 3.0 platform can expose older devices. The unresolved decision is what to do when a 3.0 device lacks an optional capability the kernels rely on: reject the device as unsupported, or keep it on a slower fallback path.

Which queried capabilities should act as hard gates during device selection, and which should merely choose between a primary and a fallback kernel? Should the requirement be expressed per feature or as a minimum device profile? And to what extent should ICD-level multi-vendor enumeration shape the policy, given that capability support is per device rather than per platform?