The RGB-direct CPU-upload path allocated and zero-filled a whole padded frame on
every submit, filled it row by row, then memcpy'd the whole thing into the mapped
staging buffer. The zero-fill was entirely dead: the row loop writes every byte
of every row, and rows past the source re-copy the last source row. So the frame
paid for an allocation, a page-fault storm over fresh pages, a full zero-fill,
and two full-frame copies where one would do.
Map first, write the padded rows straight into the mapping. Nothing reads back
from the destination — the row source is always the caller's buffer, never the
staging memory — so writing into (write-combined) host memory costs nothing
extra, and `make_host_buffer` allocates HOST_COHERENT, so the writes need no
flush before the transfer reads them.
Measured on real RDNA3 780M silicon, release build, `submit` alone, 400 frames
x 3 rounds:
- **1920x1080** (rows padded to 1088): p50 2315 -> **1725 us** (-25%),
p99 2819 -> **1972 us** (-30%), and the spread (p99-min) tightens 739 -> 483 us.
- **1366x768 -> 1408x768** (BOTH axes padded, so the column tail loop runs):
p50 1013 -> **926 us** (-8%), p99 1303 -> **1110 us** (-15%). This is the one
case where the new code could have been slower — 4-byte stores straight into
write-combined memory — and it is not.
- **CONTROL, 1280x720** (64x16-aligned, so the branch is never entered):
p50 692 vs 692 us. No delta, which is what makes the two above attributable to
this change rather than to anything else on the branch.
The branch is reached by any RGB-direct session at a mode that is not 64x16
aligned, whenever capture delivers CPU frames (the default Linux capture path is
dmabuf and never enters it). 1080p qualifies, since 1080 aligns to 1088. ⚠ An
earlier draft of this message claimed "33 MB at 4K" — that is wrong: 3840 and
2160 are both already aligned, so 4K UHD never enters this branch at all. The
large case is an ultrawide like 3440x1440 -> 3456x1440, ~20 MB.
Three things this deliberately does NOT do:
- The extent guards stay scoped to the `pad` branch. The CSC path deliberately
supports a source SMALLER than the encode extent — its shader clamps at sample
time — so a guard hoisted above the branch would break it.
- Every fallible step stays above the map. An error raised between `map_memory`
and `unmap_memory` would strand the mapping for the life of the slot's staging
buffer, and the next frame's `map_memory` on it then violates
VUID-vkMapMemory-memory-00678. (The filed "two exits above the map leak Vulkan
objects" hazard is separately already gone: `47a23bec` moved that unwind into
`make_host_buffer`.)
- It adds guards rather than removing them: a zero source axis made `sh - 1`
underflow, and "cannot fail after the map" has to be true by construction.
Three corrections to an earlier draft, all found by review of that draft:
- The `dw*dh*4 == need` precondition was a `debug_assert!` placed BELOW the map.
That is wrong twice: it made the only check on the slice length vanish from the
builds that ship, and a fired assert would have unwound past `unmap_memory` —
the exact failure the bullet above says was designed out. It is now a real
checked `?` above the map.
- `need` was `(iw * ih * 4) as u64`: a u32 multiply widened after the fact, which
agreed with the usize slice length only up to ~32768x32768. The old code's
`min(need)` was a hard backstop against exactly that and the rewrite dropped
it. Now widened before the multiply, matching `read_slot`'s existing discipline.
- The extent guard now runs BEFORE the payload-length guard, so the usize
`sw * sh * 4` cannot overflow on a garbage frame header.
WP6.2(a).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
enricobuehlerandClaude Opus 5
9fe9cbbf07