What portable OpenCL mechanisms exist for measuring kernel-internal memory bandwidth saturation across heterogeneous devices?
0 reputation · 14 Mar 2025, 15:21 UTC
Goal
Identify a vendor‑agnostic way to detect when a kernel saturates global or local memory bandwidth, using only standard OpenCL APIs or widely supported extensions.
Constraints and uncertainty
The core OpenCL profiling API (clGetEventProfilingInfo) reports only queue‑level command timestamps, not internal pipeline stalls or memory‑subsystem contention. Vendor profilers (VTune, ROCm Profiler, Nsight Compute) expose hardware counters but require vendor‑specific code paths and kernel recompilation with debug flags, which alters performance. OpenCL 3.0 makes many profiling‑relevant features optional, and device‑side enqueue introduces nested profiling that is not consistently correlated across implementations. Subgroup extensions provide divergence and occupancy hints but no direct bandwidth metrics.
Questions
- Can a combination of
clGetEventProfilingInfo, device‑side event profiling, and subgroup queries approximate memory bandwidth saturation on all major platforms? - Is there a portable methodology to distinguish driver/runtime synchronization overhead from actual device memory‑system latency without vendor tools?
- Which OpenCL 3.0 optional features, if universally adopted, would close the gap for cross‑vendor kernel‑internal bottleneck detection?
opencl