perf(amdgpu): LDS-cache efc_force in tiled_wc Phase 4b#81
Open
zhihuidu-amd wants to merge 1 commit into
Open
Conversation
Replace per-lane HBM reads of efc_force in the J^T@efc_force inner loop with cooperative LDS fills during Phase 4a, then fast LDS reads in Phase 4b. The 8 lanes per env already write efc_force to HBM in COOP-strided order during Phase 4a. This patch stores efc_val into efc_force_lds at the same time (while the value is hot in registers), then Phase 4b reads from LDS instead of HBM for the inner j_c accumulation loop. LDS budget: (ENVS=8, MAX_CON=64) float32 = 2 KB, well within the 64 KB per-workgroup LDS limit on gfx942. No VGPR overhead vs the HBM path. Why LDS over register cache (Fix-4b): - Register cache consumed 8*8=64 VGPRs per lane, hurting occupancy on MI325X - LDS cache uses shared on-chip memory with zero VGPR cost - LDS latency (~100 cycles) vs HBM (~600 cycles) still gives significant speedup - Tail path handles n_con > 64 via HBM fallback (uncommon on humanoid robots) Correctness: efc_force_lds is filled before the existing block.sync() that Phase 4b already depends on, so no additional synchronization is needed.
Author
|
/run-ci |
1 similar comment
Author
|
/run-ci |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Cache
efc_forcein LDS during Phase 4a, then read from LDS in Phase 4b(
J^T @ efc_forceinner loop), eliminating repeated HBM round-trips.Approach
The 8 lanes per env already write
efc_forceCOOP-strided during Phase 4a.This patch stores
efc_valintoefc_force_ldsat the same time (value ishot in registers), then Phase 4b reads from LDS instead of HBM.
LDS budget: (ENVS=8, MAX_CON=64) float32 = 2 KB — well within 64 KB limit.
Zero additional VGPR cost. Tail path handles n_con > 64 via HBM fallback.
Correctness
efc_force_ldsis filled before the existingblock.sync()that Phase 4balready depends on — no additional synchronization needed.
Validation
Pre-submit CI: build Genesis-Embodied-AI#380, all tests PASSED. Awaiting code review.