UMat lazy allocation: forcing synchronous GPU memory setup before a real-time loop

I am working with OpenCV's cv::UMat (assume OpenCV 4.x with the OpenCL transparent API) in a frame-processing pipeline where latency spikes on the first iteration are unacceptable. My understanding is that UMat defers the actual buffer allocation until first access, and that the allocation may even happen on a backend-managed thread.

The missing piece for me is a configuration boundary: the public API does not appear to expose any flag, allocator hook, or query that would let me force allocation to complete synchronously at construction time, or check whether the underlying memory has actually been committed yet. Calling getMat(ACCESS_READ) once as a warm-up works empirically, but I cannot tell whether this is guaranteed behavior or an implementation detail that could change across backends (OpenCL vs. CUDA interop).

I also see no way to attach a timeout or cancellation to the deferred allocation, which matters if the device is contended.

Is there a documented, supported way to pre-commit UMat storage deterministically before entering a timed loop? Can allocation status be queried through any public interface? If not, is a single warm-up access considered reliable across backends, or should this be treated as undefined?