diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-19 17:35:21 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-19 19:23:06 -0400 |
| commit | e20123d000807b1dd0c728870961e31b1f0bffb9 (patch) | |
| tree | 07a89a5c71b3c6db1acbffa6566315a68d95af7c /tools | |
| parent | 48a367e98ddd057155745699b74ed57c8c0c5612 (diff) | |
| download | open-iov-e20123d000807b1dd0c728870961e31b1f0bffb9.tar.gz open-iov-e20123d000807b1dd0c728870961e31b1f0bffb9.zip | |
vgsp: fail4 r297-r300 - decode-time staging snapshot (H2D shapes only) + ops-order release guard
1. CONT.53 step (1): device-dst copies from host sources now snapshot the
source at op-build (bounded pool 16 x 4 MB, 30 s TTL) and execute
from the snapshot, so the staging read happens at the push's
processing position.
2. The capture gate is aperture-based (dst VID, src SYS) after the r300
captures showed a naive VA-floor gate also caught D2H readbacks and
froze pre-kernel zeros.
3. Ops-order release guard: a pass that built ops queues its releases
through the pending pass instead of applying inline, so a fence
never clears before the pass's copy ops read their source.
A/B (r297/r299/r300): snapshots fire (6-7 per run) but the +2 MB phase
persists (win@0/1M = exp[+2M]); the r300 capture contents show the H2D
op sources already carry late-chunk data at decode - the scrambling is
at the driver's staging hand-off into the push stream, before our
service sees the op (next instrument: correlate the client's PTRS with
per-capture buffer identity).
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions
