Skip to content

perf(vu): clear pending pipeline entries directly - #252

Open
GTTeancum wants to merge 1 commit into
ran-j:mainfrom
GTTeancum:codex/vu-pending-entry-clears
Open

GTTeancum wants to merge 1 commit into
ran-j:mainfrom
GTTeancum:codex/vu-pending-entry-clears

Conversation

@GTTeancum

Copy link
Copy Markdown

Summary

  • Clear pending VF/VI/ACC, store, and scalar pipeline entries in place instead of constructing and copying zero-valued aggregate temporaries.
  • Preserve readiness checks, lane masks, issue-sequence checks, retirement order, and all default field values. Assert the positive-float-zero representation at compile time.
  • Add a synthetic regression covering all 16 masks, raw signed-zero/NaN/infinity/subnormal load/store bits, reused VF/VI/store entries, and per-cycle write visibility.

Why

On MSVC x64, sampled queue retirement contained repeated stack construction and reload sequences for aggregate assignment. Direct clearing removes these sequences. This follows the same motivation as the flag-entry clearing in #250, but this PR does not change FMAC flag handling or depend on that PR. It is based directly on upstream main (14b1e5c), with no game-specific code or private assets.

Validation

  • Release build: all 426 tests pass on upstream main plus the regression, before the runtime change.
  • Release build: all 426 tests pass after the runtime change.
  • In the separate X-Men integration, 140 VU tests and both recorded workloads at normal/1/8/16/64-cycle budgets retain exact state, memory, graphics packets and cycles.
  • Seven alternating local VU replay comparisons: original 2120.947 -> 2049.752 ms (3.357% lower, 7/7 wins); spread 1637.766 -> 1532.869 ms (6.405% lower, 7/7 wins). The integration also applies direct clearing to its local compiled-block path, which upstream does not have. These numbers are not a standalone-upstream benchmark or a game-FPS claim.
  • Updated integration completes first-level startup and closes normally; existing rendering defects remain. Its shared-host 4.38 FPS observation does not establish a controlled gameplay speedup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant