docs/04-real-render-walls: SESSION 143b section 21 - the Vulkan copy-class channels are registered/swept/never pushed; no channel carries program bytes or a LAUNCH_DMA; the code page never fills; the refusal path no longer reaches the black-frame baseline (SYNTH-FAULT vs completion ordering)

1 files changed, 76 insertions, 0 deletions

diff --git a/docs/04-implementation/04-real-render-walls.md b/docs/04-implementation/04-real-render-walls.md
index e02934b..f2ba0ab 100644
--- a/docs/04-implementation/04-real-render-walls.md
+++ b/docs/04-implementation/04-real-render-walls.md
@@ -831,3 +831,79 @@ frames -> Xorg/GZDOOM -> KVMFR/LG -> CUDA 15/15 + soak -> the 1.0.0
 video -> Windows. Until (1)/(2) land, keep `min_data` at its default 16:
 the bypass forwards a launch the engine cannot complete, which is worse
 for the client than the software-completion fallback.
+
+## 21. UPDATE 2026-10-26 (SESSION 143b): THE COPY-CLASS CHANNELS ARE REGISTERED, SWEPT AND NEVER PUSHED; NO CHANNEL CARRIES PROGRAM BYTES OR A LAUNCH_DMA; THE CODE PAGE NEVER FILLS - AND THE REFUSAL PATH NO LONGER PRODUCES THE BLACK-FRAME BASELINE
+
+**The instrument (commit `c5510744`).** The util sweep now logs one-shot
+`sema-utilsweep: begin|skip|read=none` for every channel plus a 128-row
+per-pass cap, so "absent from the log" can no longer be confused with
+"absent from the channel table".
+
+**Channel visibility (r803, full params, `util_scan=64`, `min_data=16`).**
+Ten channels in the table, all with gpfifo/entries, **all USERD
+unresolved** at first sight:
+```
+begin h=0xbeef0101 eng=11 gpfifo=0x4100000 entries=32768 userd=0
+begin h=0xbeef0100 eng=0  gpfifo=0x4020000 entries=32768 userd=0
+begin h=0xbeef0102 eng=12 gpfifo=0x4160000 entries=32768 userd=0
+begin h=0xbeee0101 eng=11 gpfifo=0x4500000 ...
+begin h=0xbeee0102 eng=12 gpfifo=0x4560000 ...
+begin h=0xbeed0101 eng=12 gpfifo=0x49c0000 ...
+begin h=0xbeee0100 eng=0  gpfifo=0x44a0000 ...
+begin h=0xbeec0104 eng=0  gpfifo=0x4d20000 ...
+begin h=0xbeec0100 eng=0  gpfifo=0x4cc0000 ...
+```
+The Vulkan client's copy-class channels **0xbeef0101 (eng 11) and
+0xbeef0102 (eng 12) are in the table and swept** - and their rings carry
+nothing all boot: `read=none` on first sight, `swept=0` on every pass, no
+`utildec`, no LID, no copy. The client posted one event on 0xbeef0101 at
+registration (`post_event hSrc=0xbeef0101`) and never pushed.
+
+**What did decode.** All boot: 3 LID writes only - the driver's two zero
+buffers (256 B -> vidmem 0x423f000, 12288 B -> 0x4448000, both
+`zero=1`) and the launch's own param bank (1568 B -> 0x4b86020,
+`zero=0`). No `sema-lda`/`sema-opadd` rows at all, no `copy-in` rows, no
+`utildec` on the two CE channels. Global swept=1652, writes=3.
+
+**The code page never fills.** `0x62b000` (the launch's program page for
+`prog=0xdfd8feb900`) and the rotating-pool page `0xc8b000` read ALL-ZERO
+before the client, after it, and at a final re-dump; the whole 256 MB
+aperture holds only 12 non-zero dwords boot-wide (the viewport scalars
+`0x44200000`/`0x43f00000` at 0x386634/0x386638, the releases, the
+baseline). Nothing anywhere writes program bytes.
+
+**Client outcome.** `VKDEVICE ok family=0` then
+`VKFAIL vkWaitForFences ... -> 2`; no frames, no PPMs. The service
+answered `GR-COMPLETE-SW` 10 347 times for the same refused push while
+the client kept waiting. This is the same outcome as the r801b forward
+test, and it differs from the earlier black-frame baseline
+(`VKFRAME seq=1..3`, three black PPMs): on a refused/failed forward the
+service authors a client-visible `SYNTH-FAULT` (commit `c6c152cc`,
+`sema_refusal_fault=1` since r618), and the current completion/release
+path does not get the client past its fence. `util_scan` is excluded as
+the cause (r801b failed with it off).
+
+**Reading.** The Vulkan client *believes* it uploaded its compute shader
+(it dispatches with a valid program VA), but no CPU write, no CE LID, no
+CE copy and no GR i2m in any observed channel ever delivers the program
+bytes to the emulated vidmem. The driver's upload path is a
+`staging ring -> code heap` copy (CPU memcpy into a staging BO, then a
+GPU copy to the code heap); the copy is not among the decoded pushes and
+the staging BO is not visible in the emulated vidmem. Two separate
+questions now stand:
+1. **Delivery** - where the driver queues that copy (a CE channel it
+   never pushes, a GR subchannel/method shape the parser does not
+   decode, or a sysmem staging BO that a different read path would
+   expose).
+2. **Completion regression** - restore the refusal-path software
+   completion (or gate the synthetic fault) so the client reaches the
+   fence-released black-frame baseline again; this is needed for every
+   downstream observation.
+
+**Next.** (a) Dump and decode the client's push method stream around the
+upload (the `staging ring -> code heap` copy) rather than more ring
+sweeps; the staging BO's CPU write is the most likely host-visible copy
+of the SASS. (b) Instrument the completion path for one refused Vulkan
+launch (release ordering vs the synth-fault) to restore the black-frame
+baseline. (c) Only then resume the mapping work (the r801b `FAULT_PDE` at
+the program VA).