diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-09 19:07:28 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-09 19:07:28 -0400 |
| commit | 22238ebd3cfc6e568049cdd73773fb842ea41565 (patch) | |
| tree | 1ff794f76be352163d68515c467dfa5181172072 /scripts/test_cuda_workloads.sh | |
| parent | c126d3f9a6a5ff4a34b14bbaed15bcbb33854467 (diff) | |
| download | open-iov-22238ebd3cfc6e568049cdd73773fb842ea41565.tar.gz open-iov-22238ebd3cfc6e568049cdd73773fb842ea41565.zip | |
vgsp-sema: forwarding owns the release when a candidate is captured (ISSUE-0002)
r65 showed the operand-hold release gate must not run before the
forwarding gate: for a GR launch push whose software operand was
pending, the operand hold applied the launch-completion release as soon
as the software op ran, so the client passed the launch-completion wait
while the physical launch was still in flight; when the physical launch
later timed out (qmd_rel stuck at 5, want 6) the client read zeros
(MAIL bad).
Order the release sites fwd-first: when a forwarding candidate is
captured, drop any operand-hold record for the entry (the fwd record set
carries the same release) and record into the fwd set so the hardware
completion (or its bounded fallback) is the single delivery edge. The
operand hold keeps owning the release only when no candidate is
captured, exactly as r62 intended.
Diffstat (limited to 'scripts/test_cuda_workloads.sh')
0 files changed, 0 insertions, 0 deletions
