perf(llama32_1b): batched dispatch + sibling fusion on the dual-hart … - #225
Open
karabambus wants to merge 1 commit into
Open
perf(llama32_1b): batched dispatch + sibling fusion on the dual-hart …#225karabambus wants to merge 1 commit into
karabambus wants to merge 1 commit into
Conversation
…K-split decode kernel
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
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.
Board result —
ivan@aifoundry2, trusted harness, runtimeef15baf34[17.5732, 17.5237, 17.5318], CV 0.12%OK OK OK…, 96 tokensPrevious best passing run on this harness was 13.9664 tok/s, so +25.5% at unchanged quality.
Note: #228 supersedes this PR — same stack plus a log-depth barrier release, measured at
17.8109 tok/s at the same PPL.
What changed
Three layers, all on the decode path:
Dual-hart K-split Q8_0 kernel unchanged from our previously validated revision. mul_mat_Q8_0.c and platform.h are byte-identical to 635ef76b2; this PR does not touch the dot product.
Sibling mul_mat fusion. The decode graph emits two sets of independent Q8_0 mul_mats per layer that share one activation and write disjoint outputs. The Q/K/V projections and the FFN gate/up pair. They need no barrier between them, so each set is issued as a single instruction: 32 groups, 48 of 347 launches removed per token.
Batched dispatch with a cross-shire publish protocol. The graph runs as one launch instead of ~347, with an on-device barrier between ops rather than a host round-trip.
This is not correct on its own. Batching removes the per-launch chip-wide L1+L2 evict that firmware performs after every launch, and on ET-SoC-1 that evict is the only thing publishing a kernel's output across shires. The kernels store dst with plain fsw.ps, which is not visible cross-shire.
So the host now decodes each op's source and destination ranges and, when a later instruction reads an earlier one's output, marks that producer. The dispatcher fences and evicts only those ranges past L2 after the producing instruction. It reuses the barrier already at the top of the next iteration to separate the publish from the consumer's read, so no barrier is added. Weights and any output nobody re-reads cost nothing.
Two defects in the barrier were fixed along the way, both on the path executed before every instruction: the chip-wide counter lived in .bss, which the linker script marks NOLOAD so its zeros are never written to the device; and the release credited a hardcoded 33 shires regardless of the launch mask, which leaks credits into shires the launch does not own.
Provenance
The batched-dispatch mechanism is from the upstream ET backend (llama.cpp #24179, Martin Chang). The K-split kernel, the sibling fusion, the graph reordering, the cross-shire publish protocol and the barrier fixes are ours.