docs/04-real-render-walls: SESSION 137 section 16 - the CE-ring hypothesis for the Vulkan client is disproven by direct write watches (channelFillGpFifo is notrace; the entry store never executes; the client's ring mapping watchpoint catches zero writes); the frontier moves to the GR launch's dstpend/n_data page dependency

1 files changed, 44 insertions, 0 deletions

diff --git a/docs/04-implementation/04-real-render-walls.md b/docs/04-implementation/04-real-render-walls.md
index 2de379d..6a29f6c 100644
--- a/docs/04-implementation/04-real-render-walls.md
+++ b/docs/04-implementation/04-real-render-walls.md
@@ -602,3 +602,47 @@ pointer the guest driver writes GPFIFO entries through, its PA via the
 guest pagemap, and why neither the GPU page table target nor any shadow
 holds the result (guest-kernel gdb via the QEMU gdbstub or a kprobe on
 the driver's ring-write helper).
+
+## 16. UPDATE 2026-10-26 (SESSION 137): THE CE-RING HYPOTHESIS FOR THE VULKAN CLIENT IS DISPROVEN BY DIRECT WRITE WATCHES - no kernel and no client writer ever touches the ring page
+
+**The write-watch toolchain (all three instrument classes).** (1) kprobes:
+`channelFillGpFifo` (the kernel's GPFIFO-entry writer, called from the CE
+and SEC2 submission paths per the open driver sources) is marked
+`notrace` - `trace_kprobe: Could not probe notrace function
+channelFillGpFifo [nvidia]` - so kprobes and ftrace can never attach
+(this is why the named helpers "never fired" in earlier sessions: they
+could never register). (2) QEMU-gdbstub hardware breakpoints work: a
+verification `hbreak *__x64_sys_ioctl` fired on guest ioctls
+(`IOCTL#1 pc=0xffffffffbc316160`). An `hbreak` on the exact entry store
+(`channelFillGpFifo+0xb5`, `mov %edi,(%rdx)`, where `%rdx =
+pbCpuVA + channelPbSize + lastSubmittedEntry*8` per the disassembly and
+the source) stayed silent across a complete Vulkan run - even though that
+same run produced the CE channel's notifier clear
+(`sema-chan: notifier cleared h=0xbeef0101 info32=0x5`) and the
+first-submission capture (`sema-cefirst: h=0xbeef0101 rank=1 ...
+scan_hits=0 latch=0`). (3) A client-side hardware watchpoint: the ring
+VA resolves through the guest page tables to a guest-RAM page that is
+mapped into the client process (`/dev/nvidiactl` mapping; e.g. PA
+`0x101021000` -> client VA `0x7fffee69b000`; a later run PA
+`0x10087b000` -> VA `0x7fffee7d8000`), and the walk and the emulation's
+own read agree the page is ZERO. An in-client gdb (the t122 recipe plus
+a file-fed watchpoint) armed `watch *(unsigned long*)0x7fffee7d8000`
+from the client's FIRST ioctl (`Hardware watchpoint 2` + `RGWATCH-SET`
+logged before `GLBASE`) caught ZERO writes across the whole run
+(3 frames, `VKFRAME_DONE`, IDLE).
+
+**Consequences.** On vk-first boots the client creates its CE channel but
+never submits CE work: no GPFIFO entry is written by the kernel
+(`channelFillGpFifo` never executes), nor by the client (hardware watch,
+zero hits), nor is any content found in any BAR shadow or in RAM. The
+historical "Vulkan CE ring latches" were the dead CUDA client's stale
+blocks (section 15). The image/upload path for the Vulkan client rides
+its GR channels (`launch captured ... inline=8`; the frame copy held as
+`sema-gr: copy pend ... src=0xdff0d60000 dst=0x50b0000 rows=480`), and
+the non-black gate must be attacked on that path - the data/code pages
+those launches depend on are never filled because no CE i2m copies are
+ever queued, and the launch is held on their absence (dstpend/n_data).
+Next: instrument the GR launch's dependency resolution (which pages the
+dstpend gate waits for, and whether the inline records the capture holds
+are sufficient to fill them) instead of hunting a CE ring that nothing
+writes.