Latency bounds for concurrent host-thread submissions to a shared OpenCL out-of-order queue

Scenario

A host application uses a single OpenCL context with an out-of-order command queue. Multiple host threads call clEnqueueNDRangeKernel concurrently, each with its own event, and later wait via clWaitForEvents. Under single-threaded submission the enqueue-to-completion interval is stable, but the design goal is to keep per-command latency predictable as the number of submitting threads grows.

Constraint

The OpenCL specification permits concurrent submissions from multiple host threads to a shared context, but it does not appear to define an upper bound on the latency a runtime may add when serializing internal queue access or inserting implicit synchronization points. clEnqueueMarker and clEnqueueBarrier create ordering points, yet their latency relative to concurrently submitted commands is also unspecified. Vendor behavior is documented as implementation-defined, so any bound observed on one driver (e.g., Intel Compute Runtime vs. an NVIDIA OpenCL implementation) may not transfer.

Questions

1. Does any OpenCL version or extension provide a way to bound or measure the extra latency introduced by concurrent host-thread submissions, beyond event status queries?
2. Is the only portable strategy to accept implementation-defined behavior and validate on each target driver, or is there a documented queue configuration that guarantees serialized submission cost does not grow with thread count?
3. Would partitioning work across one queue per thread change the guarantees, or does the specification treat per-queue concurrency the same way?