| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
| |
(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
|
| |
|
|
| |
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
|
| |
|
|
| |
is an execution gap (11 launches, zero data pages changed), window decode names the missing viewport family; next = gated viewport prelude
|
| |
|
|
| |
sema_gl_sph_bind lever (first slot-34 execution), DS SPH validation wall decode (a2040800/a2040a00, region=0/0) + variant results
|
| |
|
|
| |
regression (gates off restores macro execution), golden+gates-off first engine-final stores
|
| |
|
|
| |
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)
|
| |
|
|
| |
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
|
| |
|
|
| |
(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
|
| |
|
|
| |
480.0f; the float-shape filter empties the false candidate set; the wall is content (i2m never queued / forward refused first)
|
| |
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
|
| |
(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
|
| |
|
|
| |
(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)
|
| |
|
|
| |
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
|
|
|
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
|