Lazy‑mapped UMat versus explicit map/unmap for deterministic GPU‑CPU synchronization

The goal is to reduce host‑GPU synchronization latency in OpenCV pipelines while ensuring that GPU buffers allocated as UMat are never inadvertently exposed to host code.

Lazy‑mapped UMat (the default) postpones the actual transfer until the data is first read on the host, which can avoid unnecessary copies but introduces variable stalls when the first access follows a kernel launch. Explicit map/unmap forces an immediate synchronization, delivering predictable latency at the cost of possible extra bandwidth and host‑memory usage if performed more often than needed. Because the point at which lazy mapping happens is implementation‑dependent and may differ between CPU fallback and OpenCL devices, designers cannot rely on a fixed worst‑case latency without measurement.

Which strategy yields lower frame‑time variance on integrated GPUs typical of embedded vision systems? Does the predictable latency of explicit mapping justify the additional power draw on mobile platforms? Can a selective pre‑map approach for only latency‑critical kernels achieve both safety and low overhead?