docs/04-real-render-walls: SESSION 131b section 11 - the A/B that names the frontier: the CUDA client's uploads fill the emulated vidmem (~450k non-zero dwords across many 1MB blocks) while the Vulkan client's leave only the 14 baseline dwords, so the Vulkan (NVN/GL) upload path is not among the writes the emulation can see; next steps recorded

1 files changed, 28 insertions, 0 deletions

diff --git a/docs/04-implementation/04-real-render-walls.md b/docs/04-implementation/04-real-render-walls.md
index 3b14a10..56b5e11 100644
--- a/docs/04-implementation/04-real-render-walls.md
+++ b/docs/04-implementation/04-real-render-walls.md
@@ -306,3 +306,31 @@ high vidmem family, and the CUDA battery passes.
 3. `sema_util_dec_log` (96/boot) and `svc_gr_util_log` (24/boot) budgets
    were exhausted early in multi-client boots, hiding later rows; make
    them per-session for diagnosis.
+
+## 11. UPDATE 2026-10-26 (SESSION 131b): the A/B that names the frontier - CUDA's uploads land in the emulated vidmem, the Vulkan client's do not
+
+`dump_vidmem map` (new: one line per 1 MB block with non-zero content,
+`nz` = non-zero dwords) on a fresh boot, same module:
+
+* **CUDA client (`victory_mail`, STATUS OK)** - the shadow fills up:
+  `blk 0x200000 nz=40811`, `blk 0x1400000 nz=178868`,
+  `blk 0x1500000 nz=96346`, `blk 0x2a00000 nz=22880`,
+  `blk 0x7800000 nz=98257`, ... (~450k dwords total). The CUDA driver's
+  uploads (LID i2m writes with real payloads + CE copies) materialize in
+  the emulated vidmem.
+* **Vulkan client (`vk_frame120`)** - the shadow stays at the 14
+  baseline dwords (the fence/counter words at 0xfee88, the GR param bank
+  at 0x385e08, one word at 0x4d0b10). **Nothing the Vulkan client uploads
+  reaches the emulated vidmem at all.**
+
+That is the frontier in one measurement: the Vulkan (NVN/GL) driver's
+upload path is not among the writes the emulation can see. Combined with
+section 10 (the utility ring lives in vidmem via the learned map but the
+sweep can read a stale RAM page for it; the live ring holds a single
+`0x120100000/40` entry, not the 14-entry LID ring), the next session must:
+(1) capture the LIVE ring through the same source the pump uses while the
+client is up and decode its entries (the 14-entry LID ring is a
+stale-session page); (2) trace where the live client's upload writes go
+(the map shows they are NOT in the first 256 MB of the shadow - check the
+guest's own view of the client's staging BOs during the upload window);
+(3) the descriptor/operand wiring (`n_data=0`) after that.