summaryrefslogtreecommitdiffstats
path: root/docs/04-implementation/04-real-render-walls.md
Commit message (Collapse)AuthorAge
* vgsp-gr: deliver empty FB fetch pages from real FBMEM, discover the CB per ↵Arthur Hanson Rasmusson10 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | boot, clear the DS latch after each window The active indexed draw's vertex/index buffers resolve through the client's page tables to vidmem pages whose emulated BAR1 shadow is empty (no emulated upload path ever populated it), so the engine fetched zeros and the draw stored nothing. Three delivery paths now cover the page: a real-FB VID leaf for launch fetch pages (QMD pointers, never the data-fill surface) and for vertex streams when every shadow byte is zero; a sysmem-backing copy when the same VA also has a nonzero SYS mapping; otherwise the existing shadow page is used untouched. Render-target pages keep their shadow identity so the copy-out can still ship stores back to the guest. The fixed constant buffer is discovered per boot: the captured SET_MME_SHADOW_SCRATCH(0x18) value is authoritative, the historically observed base is a gated fallback, and a resolved real page is remembered for later misses. The DS HWW ESR latch is now also cleared (W1C) after each replayed window, so a failed window cannot poison the next window's entry state. Validated with three supervised cycles (r1497-r1499): the active streams read the client's real vertex floats, the real MVP resolves, poison stays at 0-1 per run, and the engine clears the render target to opaque black (dump_vidmem 0x200000 = ff000000) with the guest window still all black - the remaining wall is geometry coverage, not data delivery.
* vgsp-gr: keep the validated fixed CB across launches and map each VTG stream ↵Arthur Hanson Rasmusson11 hours
| | | | | | | | | | | | | | | | | | | | | | | contiguously - Remember the last fixed-CB page that resolved through a SYS source and passed the matrix gate; a later resolution miss (or a method-page answer) reuses it instead of zeroing the seed page with the synthetic identity. Only a boot with no validated read ever uses the identity fallback. Do not skip the write on an unchanged hash: the seed page lives in the client's screen allocation and the guest can rewrite it between launches. - Treat the CALL_MME_MACRO(2) vertex stream as one range: map [base,end) into a fresh contiguous fetch line and rewrite both ends from it, preserving the client's stream length across 4 KB boundaries. Unresolvable pages map the module zero page (a zero vertex, never a fault). The generic per-word pass remains the fallback. - Diagnostics: cb-copy logs the first 8 seed-page words and the cached flag; MME-VSTREAM-LINE dumps the resolved base page (client VA, HPA, page count, first 8 words). - Evidence: r1494 (poison 11/17 -> 1/16, real vertex floats at the stream bases, CB cache verified live with src=vaswalk -> src=cached-real) and r1495/r1496 (the active draw's vertex/index page is an all-zero vidmem shadow page while the data exists in guest sysmem - the new wall).
* docs: session-154c - real driver shader images recovered and disassembled ↵Arthur Hanson Rasmusson26 hours
| | | | (PS 384B IPA/MUFU/EXIT, VS 1408/1536B ALD/FFMA transform); with the PS delivered and raw viewport mode 6 the engine writes render-target pages and copy-out pages for the first time (3/900 pages, 1 vidmem page, a few non-black pixels), leaving viewport coverage and guest-side VS delivery
* docs: session-154c - viewport/clip/RT0 closure with driver semantics and the ↵Arthur Hanson Rasmusson28 hours
| | | | shader-crutch finding: the 144-byte vs_hex/ps_hex test image overwrote the client SASS and writes no position; removing it lets real SASS survive but stores remain zero, so the next checks are the VS position/attribute fetch and the client upload path
* docs: session-154c - whole-shadow page-hash bracket proves the no-pixel wall ↵Arthur Hanson Rasmusson31 hours
| | | | is an execution gap (11 launches, zero data pages changed), window decode names the missing viewport family; next = gated viewport prelude
* docs: session-154b - run-bit red herring (completion latch), ↵Arthur Hanson Rasmusson2 days
| | | | sema_gl_sph_bind lever (first slot-34 execution), DS SPH validation wall decode (a2040800/a2040a00, region=0/0) + variant results
* docs: session-154 findings - F1 client-formation protocol, IRAM-gate ↵Arthur Hanson Rasmusson3 days
| | | | regression (gates off restores macro execution), golden+gates-off first engine-final stores
* docs/04-real-render-walls: SESSION 143b section 21 - the Vulkan copy-class ↵Arthur Hanson Rasmusson10 days
| | | | 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)
* docs/04-real-render-walls: SESSION 143 section 20 - the r800 guard holds and ↵Arthur Hanson Rasmusson10 days
| | | | min_data=0 reaches the real engine, which MMU-faults (FAULT_PDE) at the guest program VA; the wall is now the program page's mapping and content (SASS upload), not the data-set gate
* docs/04-real-render-walls: SESSION 140 section 19 - the n_data wiring ↵Arthur Hanson Rasmusson10 days
| | | | (QMD-page note + qmd-ptr seed + pin-aware reads) reaches the launch's data set; the empty-set forward reaches the backend and oopses at gsp_phys_backend_guest_gr_submit+0x4394 - guard first
* docs/04-real-render-walls: SESSION 139 section 18 - 0x43f00000 is the float ↵Arthur Hanson Rasmusson10 days
| | | | 480.0f; the float-shape filter empties the false candidate set; the wall is content (i2m never queued / forward refused first)
* docs/04-real-render-walls: SESSION 138 section 17 - the GR launch wiring ↵Arthur Hanson Rasmusson10 days
| | | | printed (param/prog pages, deduped QMD window, single inline candidate, n_data=0 min 16 refusal); the window content exists in no host-visible source
* docs/04-real-render-walls: SESSION 137 section 16 - the CE-ring hypothesis ↵Arthur Hanson Rasmusson10 days
| | | | 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
* docs/04-real-render-walls: SESSION 135b section 15 - every Vulkan CE ring ↵Arthur Hanson Rasmusson10 days
| | | | latch on record was a stale CUDA block; the ring content is in no shadow, no RAM, and not at the PTE target (BAR1 write path verified working; client-side write watch is the frontier)
* docs/04-real-render-walls: SESSION 134/135 section 14 - the rank-blind ↵Arthur Hanson Rasmusson10 days
| | | | | | | | | | | first-submission capture caused the CUDA stall regression (fixed, a674c21c); the Vulkan CE rings live at 0x4020000/0x4100000/0x4160000 (above the 64 MB capture bound) and the frame chain reduces to the un-latched ring (copy pend -> dstpend -> black) Records the instrument, the regression A/B (r746-era module passes, SESSION 133/134 code spins), the rank-aware fix and its r781 verification, the Vulkan client's actual ring allocations from its own vidheap ioctl log, the failed 4 GB RAM entry search, and the live frame dependency (GR launch inline=8 + copy pend src 0xdff0d60000 -> vidmem 0x570000, dst framebuffer 0x50b0000) with ranked next steps.
* docs/04-real-render-walls: SESSION 133 section 13 - the SASS delivery shape ↵Arthur Hanson Rasmusson11 days
| | | | is FOUND (the driver embeds the program bytes INLINE in a CE LAUNCH_DMA push: in=0x120a00004 -> out=0x205000, 4096 B/run; the Vulkan CE channels carry the same-shaped entries) and the three gates that keep the copies from running are named: the CE ring/USERD boot-lottery (FB convention matched r763 only; the real USERDs sit at 0xfee00/0xff000/0xff200 so the rings are at unaligned offsets like 0xefe00), the VAS age-out vs CE grace race (sema_vas_cand_ms=5000 registers at +5s), and the volatile ring/USERD content that a periodic shadow scan misses; next steps: USERD-shape-derived ring resolution or first-submission latch, then the inline copies and the n_data wiring
* docs/04-real-render-walls: SESSION 132 section 12 - the live utility ring is ↵Arthur Hanson Rasmusson11 days
| | | | PROVEN in guest RAM (walk-confirmed per-run pages 0x11623d000/0x104b55000 with the 14-entry content the sweep decodes; the vidmem 0xa0000 'ring' was a false-positive autopin whose entry0 push reads all-zero and which the pump skipped after 39 rescues); the fixes (dead-entry guard + cross-aperture USERD + per-client util witnesses + op-level copyent) and their verification (r760: ring rc=0 on the live RAM page, live entry reads, VKFRAME_DONE 3 frames); the two LID uploads are the driver's zero buffers by design (256 B zero buffer + 12288 B CE fault buffer) while the GR channel's LID carries the real param bank; the code VA (prog=0xdfd8feb900) maps to a ROTATING code pool (0x62b900 -> 0xc8b000) whose lat entry can go stale and whose pages are empty - the SASS delivery shape (C5C0 0x3800/0x39C8 runs) and the walk-first code-VA resolution are the next two gates
* docs/04-real-render-walls: SESSION 131b section 11 - the A/B that names the ↵Arthur Hanson Rasmusson11 days
| | | | 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
* docs/04-real-render-walls: SESSION 131 section 10 - the utility ring lives ↵Arthur Hanson Rasmusson11 days
| | | | in vidmem (map PA 0xa0000, live entry 0x120100000/40) and the decoded 14-entry LID ring is a STALE page from a dead session, which is why its payload chunks read zero through every path (four reads + BO poller + gdb write-watchpoint); the CUDA contrast proves the LID arm works with real contiguous payloads; next step is reading the live ring through the map and decoding its entries
* docs/04-real-render-walls: SESSION 130 section 9 - the utility-channel ↵Arthur Hanson Rasmusson11 days
| | | | LOAD_INLINE_DATA arm fires (branch-order fix), the payloads are the driver's zero buffer (four-read proof + full-run BO poller + gdb write-watchpoint), the SASS delivery is the remaining non-black gate (prog page 0x62b000 empty; NVN download path targets the pitch-pool allocation), plus the xlate/util_scan regression bisect result
* docs/04-real-render-walls: SESSION 126 update - the fence fold landed ↵Arthur Hanson Rasmusson11 days
| | | | (sema_gr_ahead sweeps the pre-built GPFIFO continuation beyond GP_PUT and applies the submit pushes' INC-5 RELEASE groups forward-only through the pending ledger; VKFRAME seq/DONE with no host assist) and the compute-dispatch shape decoded: a direct C5C0 method stream (SET_OBJECT + 0x7b4/0x2a4/0x270 windows + 0x3800/0x39C8 code runs + a subchannel-0 data-port stream), NO inline-QMD write, so the existing launch capture/physical forward never fires - the translator that builds the vendor launch from the C5C0 section is the execution gate
* docs: SESSION 66 - the 0x56 pinned to the guest RS alloc path ↵Arthur Hanson Rasmusson12 days
| | | | (rmapiAllocWithSecInfo enters with class 0xc57e, serverAllocResourceUnderLock returns 0x56 before the GSP-RM RPC at under-lock+0x447; _rpcAllocObjectPrologue exonerated); the guest's not-stripped nvidia.ko is a new live-debug instrument; gdb-stub hazards recorded (kill wedges the VM - detach-only recovery; stepi loops wedge the guest - prefer conditional breakpoints)
* docs + nvkmstrace: the GL/Vulkan wall fully bisected (SESSION 65) - ↵Arthur Hanson Rasmusson12 days
| | | | ALLOC_DEVICE reply status 5 (CORE_CHANNEL_ALLOC_FAILED) decoded by the LD_PRELOAD nvKms logger with a widened reply scan; the empty display capability notifier is the first missing piece (a live-gdb fill of SYS_CAP/SYS_CAPB flips the driver to the window path, proving numWindows>0 unblocks it); the residual wall is the vGPU-guest display-class rejection: nvRmApiAlloc(0xc57e) returns NV_ERR_NOT_SUPPORTED inside the guest kernel and never reaches the emulated GSP - the guest runs in vGPU mode where display/modeset classes are host-service-provided by design
* docs: record the real-render walls measured this session (Vulkan ICD ↵Arthur Hanson Rasmusson12 days
enumerates on the emulated vGPU; vkCreateDevice fails in nvidia-modeset's ALLOC_DEVICE past the new NV0073 head/connector shim, residual wall = the display core/modeset channel objects; Xorg ScreenInit fails in nvidia-push's 10 s channel test with submissions=0 and unresolved X-channel VAs - the guest scanner serves CUDA clients only - plus a rank-0 counter-slot collision with a live CUDA client; EGL/glsi unchanged) and link the page from the README
generated by cgit v1.2.3 (git 2.39.1) at 2026-11-06 06:14:16 +0000