Fix: initialize DSv4 decode buffers on device instead of the orchestrator - #1899
Merged
ChaoWao merged 1 commit intoAug 20, 2026
Merged
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
lwDavid
force-pushed
the
fix/dsv4-device-side-init
branch
2 times, most recently
from
August 19, 2026 09:31
f34cfeb to
2b8a0f0
Compare
…ator Replace the six orchestration-side set_initial_value(0) calls in the DeepSeek-V4 FLASH decode cases with device-side initialization, making the TMR and HBG orchestrations identical here and removing the last host write to a GM-heap device address (which segfaulted under HBG): - Each sh_gate_up_act_q* producer now clears the two padded h_tile_i8 rows owned by its logical block before producing its output. - A new hc_head_mixes_zero AIV kernel (func_id 367) seeds the dynamic mixes_raw split-K destination; an explicit task dependency orders every hc_head_linear AtomicAdd store after it. - decode_fwd.cpp, decode_fwd_hostbuild.cpp and decode_fwd_graph.cpp submit the seed task in place of the plain alloc + set_initial_value. Update both READMEs and test docstrings for the new kernel count (368) and the now-closed "AtomicAdd destinations cannot be initialized under HBG" runtime gap.
ChaoZheng109
added a commit
that referenced
this pull request
Aug 20, 2026
…r to valid rows (#1922) * Fix: initialize DSv4 decode buffers on device instead of the orchestrator Replace the six orchestration-side `set_initial_value(0)` calls in the DeepSeek-V4 FLASH decode cases with device-side initialization, so the TMR and HBG orchestrations are identical here and the host never writes a GM-heap device address. Under HBG that write segfaults the chip subprocess, which is why the calls were simply dropped when the case landed on main — leaving the `mixes_raw` AtomicAdd destination undefined. - `h_tile_i8` padding rows: each of the five `sh_gate_up_act_q*` AIV kernels clears the two padded rows owned by its logical block (`zero_h_tile_i8_padding`) before producing its output. - `mixes_raw` split-K destination: a new `hc_head_mixes_zero` AIV kernel (func_id 367) clears one up-to-16-row chunk per logical block; an explicit task dependency orders every `hc_head_linear` AtomicAdd store after the seed task. `decode_fwd.cpp`, `decode_fwd_hostbuild.cpp` and `decode_fwd_graph.cpp` submit it in place of the plain `alloc_tensors` + `set_initial_value`. Both full-network cases remain `manual` (368-kernel compile); READMEs and docstrings are updated for the new kernel count and for the closed HBG initialization gap. Ported from #1899, which landed on `perf/hbg-orch` rather than `main`. * Doc: name the shipped HBG orchestration variant correctly The HBG DSv4 test points at `decode_fwd_graph.cpp`, the Graph form. Its docstring and ring-sizing comment still described the predicated-dispatch variant with a static tile grid, which the README's ruled-out table records as an earlier form that stalls at the same task and is not what the case builds. The ring sizing itself is unchanged: `HBG_RECV_ROWS_PER_EXPERT` holds every per-expert tile loop at a constant trip count, so tile scratch is still allocated for all 32 experts per MoE layer. * Fix: bound hc_head_linear to valid input rows `x_flat [8,16384]` is a valid 512 KiB allocation, but both TLOAD views were hard-coded as `Shape<...,16,256>` with a 16384-element row stride, covering an almost 1 MiB range and reading rows 8-15 out of bounds. HBG's exact-size per-tensor allocation surfaces the over-read as an MTE out-of-range fault at task 15959; TMR's retained bump allocation keeps it inside a larger mapping and masks the same kernel bug. Derive `valid_rows = clamp(t_dim - row_base, 0, 16)` and use it for the two `x_flat` views and load tiles, the dependent matmul and accumulator tiles, and the `mixes_raw` AtomicAdd store. Cube tile capacity stays at 16. The HBG README records the completed non-Graph device body, corrects the earlier 13-of-16 dispatch reading of the stall, and keeps the original failure signature under its own heading. Ported from #1871, which landed on `perf/hbg-orch` rather than `main`. The teardown-budget reference is respelled as `_CLOSE_CHILD_REAP_TIMEOUT_S`, whose branch-local commit id does not exist on `main`. * Remove the unbuilt non-Graph HBG DSv4 orchestration `decode_fwd_hostbuild.cpp` was never a build input: the case points at `decode_fwd_graph.cpp`, and nothing else read the file. Its investigation value is spent now that the tail fault it was used to isolate is root-caused and fixed in `hc_head_linear`. The README loses the stall narrative that only described this form — the per-task dump, the ruled-out table and the two-orchestration provenance — and keeps the Graph-activation blocker, the reason the kernel carries a row-tail bound, and the `get_tensor_data` runtime gap.
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
2 participants
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.
What
Replaces the six orchestration-side
set_initial_value(0)calls in the DeepSeek-V4 FLASH decode cases with device-side initialization, so the TMR and HBG orchestrations are now identical here and the host never writes a GM-heap device address (previously a segfault under HBG, worked around by dropping the calls and leavingmixes_rawundefined).h_tile_i8padding rows: each of the fivesh_gate_up_act_q*AIV kernels now clears the two padded rows owned by its logical block (zero_h_tile_i8_padding) before producing its output.mixes_rawsplit-K destination: a newhc_head_mixes_zeroAIV kernel (func_id 367) clears one up-to-16-row chunk per logical block; an explicit task dependency orders everyhc_head_linearAtomicAddstore after the seed task. All three orchestrations (decode_fwd.cpp,decode_fwd_hostbuild.cpp,decode_fwd_graph.cpp) submit it in place of the plainalloc_tensors+set_initial_value.This closes the "AtomicAdd destinations cannot currently be initialized correctly by HBG" runtime gap recorded in the HBG README.
Both full-network cases remain
manual(368-kernel compile); READMEs and docstrings are updated for the new kernel count and status.