Skip to content

Commit eeace57

Browse files
authored
Remove documentation that describes things that no longer exist (#2017)
Three kinds of stale documentation, all of it naming something the tree does not contain. `doc-consistency.md` §3: when a referent is gone, the reference goes too. **`problems.md`, deleted.** A personal working audit of `host_build_graph` — findings, their status, and notes on what to look at next. It was never meant to be here. It arrived in #1974 through a `git add -A` that swept it up with that change's 958 files, and #2012 then updated it rather than noticing it. Nothing references it (`git grep problems.md` is empty), it is absent from `mkdocs.yml`, and `wheel.packages` is `["simpler_setup", "python/simpler"]` so it never shipped. Its closed items name the PRs that closed them, each of which carries the reasoning in its own commit message. **`last_task_alive`, in hbg's `RUNTIME_LOGIC.md`.** The paragraph gives four reasons `SchedulerState` holds no per-run content, and the third was "hbg never advances `last_task_alive`". That was accurate when written — hbg inherited the field from `tensormap_and_ringbuffer` and did not advance it — but #1837 deleted the field with the rest of the reclamation paths, for exactly the reason the sentence gives, and #2004 then removed the ring that held it. The clause now names the one thing in that list that does not exist. It is replaced by the live fact from the same runtime: polling reserves no wiring or dependency pool, because readiness comes from the task table's `completion_flags`. **`ring 0`, in hbg's `SCALAR_DATA_ACCESS.md`.** Ownership validation was described as checking that "the task ID ... carries ring 0, the only ring HBG places tasks on". hbg has had no ring since #2004 (`git grep 'rings\['` over its tree is empty), and since #2012 the check is on the id *space*, not a ring index. The bullet now says what the code does and why a `GRAPH_NODE` id fails it. **`pto_runtime2_init`, in three `scheduler.h` files.** A comment credited it with reserving and wiring the early-dispatch queues. `git grep pto_runtime2_init` returned only those three comments — the symbol exists nowhere. The work is done by `SchedulerState::init_data_from_layout`, which the comment now names. Only three of the four runtime trees carried the line; `src/a5/runtime/tensormap_and_ringbuffer` words that member differently. **`run_from_blob`, in `docs/buffer-abi.md`.** A present-tense table row told the chip leaf to "hand the POD blob to `run_from_blob`", a name that has never existed (introduced with the row in #1599). The row now names the three functions that do the work — `read_args_from_blob`, `ImportRegistry.materialize_args`, `_submit_chip_run_materialized` — matching `worker.py`'s `submit_frame`. Deliberately untouched: `tensormap_and_ringbuffer`'s ring documentation. `current_task_index`, `task_window_mask`, `advance_lock` and `last_task_alive` are all live there (162 uses across 20 non-doc files); #2004 dropped the ring from `host_build_graph` only, and said so.
1 parent 0631f57 commit eeace57

9 files changed

Lines changed: 28 additions & 145 deletions

File tree

‎docs/buffer-abi.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -250,7 +250,7 @@ A `Tensor` on the wire is materialized differently by each consumer:
250250

251251
| Consumer | What it does |
252252
| -------- | ------------ |
253-
| **Chip leaf (L2 runtime)** | Materialize each one to a `ChipTensor` (map-once, keyed by identity), including **strided** views; hand the POD blob to `run_from_blob`. |
253+
| **Chip leaf (L2 runtime)** | Decode the POD blob with `read_args_from_blob`, then materialize each one to a `ChipTensor` (map-once, keyed by canonical identity) via `ImportRegistry.materialize_args`, including **strided** views, and submit with `_submit_chip_run_materialized`. |
254254
| **Python sub-worker** (compute) | Map each one into a `MappedArg`; the callable computes with `torch.frombuffer(arg.buffer, ...)`. No `ChipTensor`. |
255255
| **Nested L4→L3 orch** (forwarding) | **Re-export** each backing to a descriptor `H'` that keeps the source's canonical identity — no pass-through, no map on the forwarding hop. |
256256

‎problems.md‎

Lines changed: 0 additions & 123 deletions
This file was deleted.

‎src/a2a3/runtime/host_build_graph/docs/RUNTIME_LOGIC.md‎

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -124,8 +124,9 @@ scalar `rt_orchestration_done` publishes into the runtime header.
124124

125125
**Why the scheduler state is device-written.** `SchedulerState` holds no
126126
per-run content: `sm_header` and the task-header pointer derive from a pooled SM base,
127-
queue capacities are compile-time constants, hbg never advances
128-
`last_task_alive`, and it has no host-side entry point at all. So the host would
127+
queue capacities are compile-time constants, polling reserves no wiring or
128+
dependency pool (readiness comes from the task table's `completion_flags`, which
129+
the task header owns), and it has no host-side entry point at all. So the host would
129130
only be writing an initialization pattern — 203,392 bytes
130131
of it, dominated by `AsyncWaitList::entries` — for the device to receive and never
131132
read. `RuntimeContext` therefore holds a *pointer* to it, wired from

‎src/a2a3/runtime/host_build_graph/docs/SCALAR_DATA_ACCESS.md‎

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -70,7 +70,9 @@ it derives for itself, from a heap block whose prior contents it never reads.
7070
7171
Before a wait slot is used, the runtime verifies:
7272
73-
- the task ID is valid and carries ring 0, the only ring HBG places tasks on;
73+
- the task ID is valid and lies in the `RING` id space — a `GRAPH_NODE` id packs
74+
its outer task and node index into the low bits, so it indexes no task table
75+
slot (see `src/common/host_build_graph/task_id_encoding.h`);
7476
- the task table slot that ID indexes has a bound task descriptor; and
7577
- the descriptor's full task ID matches the tensor's owner/producer ID.
7678

‎src/a2a3/runtime/host_build_graph/runtime/scheduler/scheduler.h‎

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -689,11 +689,11 @@ struct SchedulerState {
689689
EarlyDispatchDoorbell early_dispatch_doorbell_table[EARLY_DISPATCH_CORE_MASK_WORDS * 64]{};
690690

691691
// Cross-thread early-dispatch work queues, one ChipReadyQueue MPMC instance per
692-
// resource shape (AIC/AIV/MIX) — arena-backed, reserved/wired in pto_runtime2_init
693-
// alongside the per-shape ready queues, and indexed the same way. A candidate is
694-
// pushed to the queue for its own shape (active_mask.to_shape()) so the drain can
695-
// pop per shape and size the pop to that shape's free cores, exactly as normal
696-
// dispatch pops ready_queues[shape].
692+
// resource shape (AIC/AIV/MIX) — arena-backed, reserved and wired by
693+
// SchedulerState::init_data_from_layout alongside the per-shape ready queues, and
694+
// indexed the same way. A candidate is pushed to the queue for its own shape
695+
// (active_mask.to_shape()) so the drain can pop per shape and size the pop to that
696+
// shape's free cores, exactly as normal dispatch pops ready_queues[shape].
697697
//
698698
// A consumer's SPMD blocks span cores owned by several AICPU threads, but only a
699699
// thread RUNNING the consumer's producer discovers it (via the producer's

‎src/a2a3/runtime/tensormap_and_ringbuffer/runtime/scheduler/scheduler.h‎

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -735,11 +735,11 @@ struct SchedulerState {
735735
EarlyDispatchDoorbell early_dispatch_doorbell_table[EARLY_DISPATCH_CORE_MASK_WORDS * 64]{};
736736

737737
// Cross-thread early-dispatch work queues, one ChipReadyQueue MPMC instance per
738-
// resource shape (AIC/AIV/MIX) — arena-backed, reserved/wired in pto_runtime2_init
739-
// alongside the per-shape ready queues, and indexed the same way. A candidate is
740-
// pushed to the queue for its own shape (active_mask.to_shape()) so the drain can
741-
// pop per shape and size the pop to that shape's free cores, exactly as normal
742-
// dispatch pops ready_queues[shape].
738+
// resource shape (AIC/AIV/MIX) — arena-backed, reserved and wired by
739+
// SchedulerState::init_data_from_layout alongside the per-shape ready queues, and
740+
// indexed the same way. A candidate is pushed to the queue for its own shape
741+
// (active_mask.to_shape()) so the drain can pop per shape and size the pop to that
742+
// shape's free cores, exactly as normal dispatch pops ready_queues[shape].
743743
//
744744
// A consumer's SPMD blocks span cores owned by several AICPU threads, but only a
745745
// thread RUNNING the consumer's producer discovers it (via the producer's

‎src/a5/runtime/host_build_graph/docs/RUNTIME_LOGIC.md‎

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -124,8 +124,9 @@ scalar `rt_orchestration_done` publishes into the runtime header.
124124

125125
**Why the scheduler state is device-written.** `SchedulerState` holds no
126126
per-run content: `sm_header` and the task-header pointer derive from a pooled SM base,
127-
queue capacities are compile-time constants, hbg never advances
128-
`last_task_alive`, and it has no host-side entry point at all. So the host would
127+
queue capacities are compile-time constants, polling reserves no wiring or
128+
dependency pool (readiness comes from the task table's `completion_flags`, which
129+
the task header owns), and it has no host-side entry point at all. So the host would
129130
only be writing an initialization pattern — 203,392 bytes
130131
of it, dominated by `AsyncWaitList::entries` — for the device to receive and never
131132
read. `RuntimeContext` therefore holds a *pointer* to it, wired from

‎src/a5/runtime/host_build_graph/docs/SCALAR_DATA_ACCESS.md‎

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -70,7 +70,9 @@ it derives for itself, from a heap block whose prior contents it never reads.
7070
7171
Before a wait slot is used, the runtime verifies:
7272
73-
- the task ID is valid and carries ring 0, the only ring HBG places tasks on;
73+
- the task ID is valid and lies in the `RING` id space — a `GRAPH_NODE` id packs
74+
its outer task and node index into the low bits, so it indexes no task table
75+
slot (see `src/common/host_build_graph/task_id_encoding.h`);
7476
- the task table slot that ID indexes has a bound task descriptor; and
7577
- the descriptor's full task ID matches the tensor's owner/producer ID.
7678

‎src/a5/runtime/host_build_graph/runtime/scheduler/scheduler.h‎

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -689,11 +689,11 @@ struct SchedulerState {
689689
EarlyDispatchDoorbell early_dispatch_doorbell_table[EARLY_DISPATCH_CORE_MASK_WORDS * 64]{};
690690

691691
// Cross-thread early-dispatch work queues, one ChipReadyQueue MPMC instance per
692-
// resource shape (AIC/AIV/MIX) — arena-backed, reserved/wired in pto_runtime2_init
693-
// alongside the per-shape ready queues, and indexed the same way. A candidate is
694-
// pushed to the queue for its own shape (active_mask.to_shape()) so the drain can
695-
// pop per shape and size the pop to that shape's free cores, exactly as normal
696-
// dispatch pops ready_queues[shape].
692+
// resource shape (AIC/AIV/MIX) — arena-backed, reserved and wired by
693+
// SchedulerState::init_data_from_layout alongside the per-shape ready queues, and
694+
// indexed the same way. A candidate is pushed to the queue for its own shape
695+
// (active_mask.to_shape()) so the drain can pop per shape and size the pop to that
696+
// shape's free cores, exactly as normal dispatch pops ready_queues[shape].
697697
//
698698
// A consumer's SPMD blocks span cores owned by several AICPU threads, but only a
699699
// thread RUNNING the consumer's producer discovers it (via the producer's

0 commit comments

Comments
 (0)