CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE: latency reduction versus implicit kernel reordering for sporadic workloads

For a sporadic OpenCL workload where kernels are enqueued intermittently, the runtime enqueue overhead dominates total execution time. Configuring the command-queue with CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE may amortize that overhead while preserving kernel sequencing.

Out-of-order execution allows the runtime to reorder enqueued kernels, which can violate functional correctness when implicit data dependencies exist between kernels launched in the same context. The extent to which the runtime infers or respects these dependencies without explicit synchronization is uncertain for low-traffic scenarios.

Under what conditions does the OpenCL implementation preserve kernel ordering when CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE is active? Does SVM memory flag interaction alter reordering behavior? What profiling metrics reliably differentiate intentional reordering from accidental kernel merging?