summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* vgsp-sema: SESSION 140 the n_data wiring - QMD-page note, qmd-ptr candidate ↵Arthur Hanson Rasmusson14 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | seed, pin-aware scan reads Three corrections that take the GR fill from 'no candidates' to the launch's real pointer set: 1. Note the QMD page itself into the request's page list (word 34) so the 32..48-even bank scan covers it - the pointer VALUES live inside the QMD (r790: word 34 = 0xdff0febc00) and were never scanned. 2. Seed the fill's candidate set directly from the launch's own QMD pointer pairs (gr_qmd words 34..47, decoded from the push's inline-QMD run): r793 'sema-gr: qmd-ptr seed va=0xdff0feb000 (word 34)' - the values need no page scan (the pages' shadows read empty; the invisible -vidmem-write class). 3. Read the scanned pages pin-aware (svc_read_va first, host mapping of pp->pa as fallback): the push-buffer discovery's pinned staging copy holds the content the decode reads; a raw mapping of the vidmem pa sees zeros. Verified r793/r794: candidates now appear (fill cand n=1 with the QMD window page seeded); the page is correctly classified launch-internal by the R3 hygiene filter (n_data stays 0 - nothing external to relocate for this launch). With the r564 degenerate-set guard bypassed (min_data=0), the forward ENTERS the backend and oopses in gsp_phys_backend_guest_gr_submit+0x4394 ('Oops: 0000 [#2]', workqueue gsp-phys-work svc_fwd_work_fn, NULL-base table walk CR2=0x1e93c R14=0) - the empty-set path needs that guard before min_data=0 can be used. This launch's QMD declares exactly one pointer pair, and it names its own QMD window: a launch with no external data is legitimate and the refusal class must not treat it as degenerate.
* docs/04-real-render-walls: SESSION 139 section 18 - 0x43f00000 is the float ↵Arthur Hanson Rasmusson14 hours
| | | | 480.0f; the float-shape filter empties the false candidate set; the wall is content (i2m never queued / forward refused first)
* vgsp-sema: SESSION 139 GR fill: reject float-shaped scan words + scan the ↵Arthur Hanson Rasmusson14 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | deduped word-48 page Two evidence-based corrections to the launch-data candidate scan: 1. Float-shape filter at all four scan sites (the three page scans and svc_gr_scan_cand): a word whose f32 exponent byte is in ~[0x6c..0x8f] (2^-19..2^16) is a plausible float scalar, not a device VA - device VAs (2^28..2^47) as f32 land in subnormal/tiny exponents. Root evidence (r789): the launch param page carries the kernel's scalar arguments (0.2f, 640.0f, 480.0f at +0x630 - the 640x480 viewport) and 0x43f00000 = 480.0f was the fill's ONLY candidate - an unresolvable "arg base=0x43f00000" that drove the fail-closed diagnostic and the demand-loop noise for days. After the filter: 'fill cand n=0' (r790) - no false candidates, no false demands. 2. The bank-page scan now covers word 48: the QMD pointer-region pair can name a 4K page that also carries the program pair (r788: ptr[0] 0xdff0febc00 word 34 shares its page with prog 0xdff0feb900), and svc_gr_page_note dedupes the first note (the program's, word 48), so the old 32..47-even filter left that page unscanned. The remaining wall is content, not wiring: with the false candidates removed the launch still refuses (n_data=0 vs min 16) because no scanned source holds real device pointers - the param page holds scalars, the QMD window page reads zero (its content would arrive via the driver's i2m/LOAD_INLINE_DATA writes whose payloads are not in the push), and the inline payload is the driver's zero stub. This matches the SESSION 130 zero-buffer finding and leaves the never-queued i2m copies (or the real GPU path) as the only content sources.
* docs/04-real-render-walls: SESSION 138 section 17 - the GR launch wiring ↵Arthur Hanson Rasmusson15 hours
| | | | 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
* vgsp-sema: SESSION 138 GR request-builder page-list + fill-candidate witness ↵Arthur Hanson Rasmusson15 hours
| | | | | | | | | | | | | | | | | | | | (sema_dbg-gated, bounded) The dstpend/n_data frontier needed the launch's actual wiring. Prints, once per launch within a bounded budget: the candidate handle, param_va, prog_va, n_pointer + the QMD pointer pairs, the inline-rec count, and the resolved gr_pages list (va/pa/ap/qmd_word); then in the fill, the built candidate set with the arg flag. First capture (r788, Vulkan launch h=0xbeec0100): param=0x4b86000 -> page pa=0x386000 ap=2 qmd_word=32; prog=0xdff0feb900 -> page pa=0x56b000 ap=2 qmd_word=48; ptr[0]=0xdff0febc00 word=34 (DEDUPED into the qmd_word=48 page - same 4K page - and that page is never scanned by the fill's word-32/32..47-even passes); the fill's only candidate is 0x43f00000 (arg=1, from the inline bytes) which resolves in NO vaspace (rc=-2 in all four) -> n_data=0 -> the backend's min_data=2 refusal. The param/prog/QMD-window pages read all-zero in the vidmem shadow on this boot, so the launch's data/code bytes exist in no host-visible source.
* docs/04-real-render-walls: SESSION 137 section 16 - the CE-ring hypothesis ↵Arthur Hanson Rasmusson15 hours
| | | | 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 Rasmusson15 hours
| | | | 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)
* vgsp-sema: SESSION 135 CE first-submission capture: reject a consumed-state ↵Arthur Hanson Rasmusson15 hours
| | | | | | | | | | | | | | | | | | | | | | | | USERD candidate (get >= put > 0) At the first-submission instant the channel's own submission is by definition unconsumed - the notifier clear this capture runs before is what would let the driver treat it as consumed. A candidate whose USERD reads a consumed state (put == get > 0) cannot be this channel's live just-submitted work. Observed r785 (CUDA-first boot, three Vulkan runs): the capture latched fb 0x80000 / userd 0x90000 for beef0101 (rank 0) with put=1 get=1 - the dead CUDA client's caf00012 block surviving in VRAM after its session ended. The decoded entry (va=0x120000000 len=40) was the old session's, the expectations seeded from the stale pool word (want=2/3 vs pay=1) and the Vulkan client stalled into its fence timeout on every run. All genuine first-submission latches on record read put=1 get=0 at the capture instant (r779 caf00012 rank0, r785 caf00012 rank0, r781/run1 beef0101). Idle 0/0 stays acceptable per svc_userd_probe's own rule. Session-scoped rank ownership (svc_ce_firstsub_off) does not cover this class: the stale block belongs to a previous CLIENT, and its consumed state is the only local signal that it is not this submission.
* docs/04-real-render-walls: SESSION 134/135 section 14 - the rank-blind ↵Arthur Hanson Rasmusson16 hours
| | | | | | | | | | | 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.
* vgsp-sema: SESSION 134c rank-aware CE first-submission capture - the ↵Arthur Hanson Rasmusson16 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rank-blind first-hit latched rank 0's block for rank 1 The SESSION 134 first-submission capture scanned the shadow from offset 0 and took the first ring-shaped page for EVERY CE channel. On the r779 boot that latched rank 0's block (fb 0x80000, userd 0x90000) for rank 1 as well (both rows scan_hits=1 latch=1 off=0x80000), so caf0001d's first release was decoded from rank 0's ring/page (sem word +0 instead of +4) and stale-dropped (cur=1 already from rank 0's applied release). The client's rank-1 tracker wait never completed: victory_mail spun at 100% CPU with pub_calls=0 on three consecutive boots (r777/r778/r779), while the r746-era module (25523f84) passed the same run on a fresh boot (VADDs OK, STATUS OK). Fix: try the rank's convention offset (0x80000 + 0x20000 * rank) first, scan the rest bounded as before, and never accept an offset another CE rank already latched this session (svc_ce_firstsub_off[], reset per session). A rank whose block is not in the shadow at the instant stays unlatched for the regular per-pass CE latch instead of stealing a foreign block. Verified on r781 (fresh boot, same params xlate=1/util_scan=0/vas_cand_ms =5000/ce_grace=20000): caf00012 rank0 -> fb 0x80000 upa 0x90000; caf00001d rank1 -> fb 0xa0000 upa 0xb0000 (correct block, sem +4 applied: pool-wr va=0x121000004 cur=0 -> val=1 ok); ranks 2-5 -> 0xc0000/0xe0000/ 0x100000/0x120000 each +0x10000; r780 (r746 module) control run: same client PASSED (VADD n=32768 bad=0 checksum=12204516.000000, STATUS OK); r781 client progressed with pub_calls=185132+ (no spin stall). Also the Vulkan client's CE channel latched via the classic autopin on r781 (beef0101 -> fb 0x80000, live entry0) - first time in the SESSION 131-134 window - confirming the latch machinery works once the wrong-block mis-latch no longer poisons the channel.
* vgsp-sema: SESSION 134b fix the CE first-submission scan's entry decode (u32 ↵Arthur Hanson Rasmusson17 hours
| | | | | | | | | | | | hva truncated the 40-bit VA so no CE-window entry could ever match) hva must hold the 40-bit push VA (bit 32 set for the CE window) but was declared u32 in the scan, so ((h1 & 0xff) << 32) truncated to the low dword and hva < 0x120000000ULL was always true - scan_hits stayed 0 by construction. Same decode as svc_chan_userd/svc_gr_ring_candidate (u64). Verified building; the FB-convention latch itself (auto-pinned ring h=0xcaf00012 -> fb 0x80000, userd 0x90000, entry decode + push decode, ops_runs=1) was observed independently on r776.
* vgsp-sema: SESSION 134 CE first-submission capture + bounded completion hold ↵Arthur Hanson Rasmusson18 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - the CE ring latch instrument The CE-class ring (the SASS-delivery channel's GPFIFO, registered at gpfifo=0x4100000 on every boot) only ever latched on one boot (r763, the FB convention matched shadow 0x80000 and the sweep decoded the inline LAUNCH_DMA entry). On r765-r775 every deterministic source reads a zero page (the page tables genuinely map the ring VA to an all-zero RAM page - proven by the per-level walk trace) and the ring never appears in the shadow (scan_hits=0 at the submission instant; dump_vidmem map shows only the USERD put words) nor in the guest RAM image (a full 4 GB scan for consecutive GPFIFO entry pairs around the CE push window finds none). New bounded instrument, default-inert: - svc_ce_firstsub_capture: on a CE channel's notifier clear (the one instant ring content and USERD are both live), before the clear write: reads entry0 through the channel translation and the trusted walk, then scans the shadow (0x100 step, 64 MB) for a CE-window ring page (1MB-aligned push VA in [0x120000000,0x121000000)) and latches via the standard USERD gate at +0x10000/+0x2000/+0x1000/+0x0. Budget 4/channel, 16 witness rows/boot, reset by svc_session_flush. - sema_ce_hold_ms (module param, default 0 = off): holds an unlatched CE channel's notifier busy for up to N ms so the guest keeps the submission in flight (and with it the ring content) while the VAS lands and the regular per-pass latch path retries; expires into the old clear behaviour. r774/r775 evidence (sema_ce_hold_ms=8000): sema-cefirst at the first submission shows rrc=-2 (no VAS yet at +0.2 s), wrc=-1 (walk unresolved), scan_hits=0 (no shadow ring); 30 s later the walk answers a zero page (rpa changing per boot, e0=0x0), the hold expires unlatched, and the client still completes (VKFRAME_DONE) - the hold is safe but the ring's write path is still not visible to the emulation. Remaining unknown is named: the driver's ring writes reach neither the shadow nor the PTE-mapped guest page.
* vgsp-sema: SESSION 133c USERD-shape-derived ring pass - find the channel ↵Arthur Hanson Rasmusson19 hours
| | | | USERD by its own shape (put@+0x8c, get@+0x88, the find_userd layout) and derive the ring at userd-{0x10000,0x2000,0x1000}, validating entry0 (shape + not provably dead) and the USERD probe; the USERD words appear at channel creation and stay while the ring entry may be written later, so this is the stabler trigger for the CE-family rings that the periodic ring-entry scan misses
* docs/04-real-render-walls: SESSION 133 section 13 - the SASS delivery shape ↵Arthur Hanson Rasmusson19 hours
| | | | 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
* vgsp-sema: SESSION 133b shadow ring scan - step 0x100 (the rings are ↵Arthur Hanson Rasmusson19 hours
| | | | unaligned: r767 USERD shape scan found the channel blocks at 0xfee00/0xff000/0xff200, so the rings sit at offsets like 0xefe00) and retry rate-limited (1.5s) instead of a consumed once-bit, because a first pass can run before the client has written the ring or its USERD
* vgsp-sema: SESSION 133 bounded shadow ring scan fallback - the CE-class ↵Arthur Hanson Rasmusson19 hours
| | | | rings live in VIDMEM and the FB convention only matches when the guest VRAM allocator happens to place them at the conventional offsets (r763: matched fb 0x80000/0xa0000 and the CE channel decoded its inline SASS copies; r765: read zeros, the ring VA resolved to a stale RAM page whose entry0 was dead, the CE channel never latched - black frames). When every deterministic candidate fails, scan the first 64 MB of the shadow for a ring-shaped page (entry0 names a 1 MB aligned push VA in the client window with a sane length, not provably dead via svc_ring_entry_dead) whose USERD at the observed deltas (+0x10000 CE family, +0x2000 GR, +0x1000) reads a coherent put/get; one scan per rank per boot, re-armed per client session. A false candidate still costs only a failed probe.
* docs/04-real-render-walls: SESSION 132 section 12 - the live utility ring is ↵Arthur Hanson Rasmusson19 hours
| | | | 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
* vgsp-sema: SESSION 132 ring-latch truth + per-client util witnesses - the ↵Arthur Hanson Rasmusson20 hours
| | | | r759 false positive is fixed at three points: (1) a ring candidate whose entry0 push provably reads all-zero through the client's own page tables is rejected when the VAS walk resolves the ring VA to a page with a live entry (svc_ring_entry_dead + svc_ring_walk_live, applied at the userd-derived, FB-convention and existing-pin paths; the walk cannot vote for itself); (2) svc_gr_ring_candidate now rejects dead-entry candidates too and accepts the channel's known USERD cross-aperture (r759: ring in guest RAM 0x11623d000, USERD in vidmem 0xb0000, so the walk-resolved ring failed the same-aperture USERD probe); (3) the util sweep arbitrates a dead channel-path ring entry against the direct VAS walk per slot. Also: util-dec/util-sweep witness budgets and their dedup keys become per-client (reset in svc_session_flush) and the sema-copyent witness logs once per copy op instead of per row (a 480-row frame copy alone exhausted the 128/session budget and hid every later copy, including any SASS upload)
* docs/04-real-render-walls: SESSION 131b section 11 - the A/B that names the ↵Arthur Hanson Rasmusson20 hours
| | | | 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
* vgsp: dump_vidmem map mode - one line per 1 MB block with non-zero content ↵Arthur Hanson Rasmusson20 hours
| | | | (nz count + first offset) to locate the live client's uploaded regions in the 256 MB aperture without 65536 range dumps
* docs/04-real-render-walls: SESSION 131 section 10 - the utility ring lives ↵Arthur Hanson Rasmusson20 hours
| | | | 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 Rasmusson21 hours
| | | | 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
* vgsp-sema: SESSION 130 xlate regression bisect - the r727 translator ↵Arthur Hanson Rasmusson21 hours
| | | | regressions were re-tested on a fresh boot: with the translator ON and the utility sweep OFF, victory_saxpy and victory_math PASS with checksums identical to the gate-off baseline (saxpy csum=981440890.500000), so the SESSION 129/130 sweep changes fixed the saxpy/math half; the remaining xlate-on regression is victory_multikernel, whose physical forward times out repeatedly (GR LAUNCH FAILED ... qmd_rel=0xc0ffee01, hold active), so the default stays 0 until that forward path is fixed. The UTILITY SWEEP is the other regression source (util_scan=24 broke saxpy bad=1047527 and hung math) and stays opt-in until its channel reads prefer the direct walk
* vgsp-sema: SESSION 130 zero-payload application + tail-arbitration witness - ↵Arthur Hanson Rasmusson21 hours
| | | | a zero-headed tail-served payload is now applied under a variant once-key (h | 1) instead of being refused forever (the destination is empty, so authoring zeros is idempotent and correct for the driver's internal zero buffer, whose 256 B i2m equals GF100_ZERO_BUFFER_SIZE exactly), while a later non-zero payload for the same entry still matches its own (h) key and lands; the utildec witness now carries alt=success/tries so a walk-read that fails is distinguishable from one that returns zero
* vgsp-sema: SESSION 130 util-channel LOAD_INLINE_DATA arm FIXED - the subch-2 ↵Arthur Hanson Rasmusson22 hours
| | | | GRCE operand group was swallowed by the TURING-copy branch (its `subch >= 2` guard also matches subchannel 2, leaving have_out/line_len unset so the LID arm never fired: r739 witness `lidn=1 subch=2 saw=0 dst=0 ll=0`); the 0x180..0x18c group now parses FIRST for subch 1|2, plus tail-content arbitration (a zero-headed channel tail is re-read through the direct registered-VAS walk before the arm's zero-refusal can stall the upload) and the witness now carries the served tail's first two words + the alt-read counter
* STATE-CURRENT: refresh snapshot - the guest's real Vulkan pipeline renders ↵Arthur Hanson Rasmusson22 hours
| | | | end-to-end (VKFRAME seq/DONE/IDLE, three PPMs); the full fix chain (push-parse shapes, fence fold sema_gr_ahead, VAS pdb anchoring, COMPR downgrade, scrub-author, 9096/ZCULL, C5C0 translator); non-black frames (MME/i2m LOAD_INLINE_DATA arm) is the frontier; CUDA 8/3/1 fresh-boot battery; video v1 on files.vgpu.io
* vgsp-sema: SESSION 129 util-channel LOAD_INLINE_DATA arbitration + witness - ↵Arthur Hanson Rasmusson30 hours
| | | | the subchannel-2 arm never fired (r737 writes=0) because the utility channel's read path could not produce a parseable methods entry (the tail-served split shape); the util sweep now arbitrates attempt A (channel path, unchanged) against attempt B (direct registered-VAS walk, the walk_probe-proven path) and lets the strict parse choose the stream, a still-zero tail-served payload is refused (no once-store, retried every pass; in-push payloads untouched), and a bounded deduplicated sema-utildec witness names per distinct entry: winning attempt, both parses, tail VA/length, LID header count/subch and the arm's saw/fired/zero state
* vgsp-sema: SESSION 128 utility/copy-channel inline-download sweep ↵Arthur Hanson Rasmusson31 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (sema_gr_util_scan, default 0) - decode the driver's engine-side MME/i2m upload path and materialize LOAD_INLINE_DATA downloads and pitch copy-ins from channels the put-bounded entry loop never decodes The Vulkan client's code/constant uploads leave the utility channels (the MEM2MEM/A140 composite at h=0xbeef0100 and the eng=11/12 copy channels) and were invisible to the emulation: with an unresolved USERD the put-bounded entry loop skips those channels entirely (the !userd_ok branch continues), and with a resolved USERD the main decode's operand group and LOAD_INLINE_DATA arms only accept subchannel 1 while the uploads ride the mem2mem/copy subchannels (2/4). svc_gr_util_sweep scans up to sema_gr_util_scan (default 0 = off; requires sema_gr_xlate) GPFIFO entries of every channel directly, reads each push plus its successor as the tail (the driver's source-view GPFIFO call carries the payload of a trailing LOAD_INLINE_DATA run - observed beef0100 idx00->idx01 and idx08->idx09), and feeds them through svc_gr_ahead_push in a new inline-only mode: the GRCE/INLINE_TO_MEMORY operand group now also accepts the mem2mem subchannel, the QMD window, release and copy-pend arms are skipped, and a TURING_DMA_COPY_A launch on the copy subchannels materializes the engine copy-in (src from the client's staging buffer through the trusted read, dst through the same svc_grce_inline_write the GR sweep uses) instead of queueing a launch copy-out. Every materialization is once-only keyed by (push_va, content hash, dst, bytes); SVC_AHEAD_TAIL_INLINE_MAX rises 4 KB -> 32 KB so the 12 KB code-staging payload is not truncated. Verified on r737 (gated): the sweep runs for all ten channels (utility, CE and GR) with bounded reads and no release/QMD state changes; the utility channel is swept 14 entries per pass. The LOAD_INLINE_DATA arm on the utility channel's subchannel-2 runs still does not fire (payload/parse witness is the next debug item, see Handoff SESSION 128).
* vgsp-sema: SESSION 127 follow-up - gate the C5C0 translator behind ↵Arthur Hanson Rasmusson32 hours
| | | | | | | | | | | | | | | | | | | | | | | | sema_gr_xlate (default 0) The r727 full battery with the translator active but ungated regressed three clients (saxpy bad=1047527, math sums=0, multikernel hang) while r729 with the translator's semantics gated off is clean on the same subset (mail, saxpy, math OK; multikernel still stalls in its pre-existing flaky class). All translator behaviour is now behind sema_gr_xlate (default 0 = exactly the historical sweep): - the tail-aware method parse (tail passed only when enabled), - the sweep's inline-QMD accumulation, LOAD_INLINE_DATA materialization, C5B5 copy capture and candidate-owned release withholding, - the client-VAS walk fallbacks in svc_gr_page_note / svc_gr_req_fill, - the inline-rec filter at capture (keeps resolvable or QMD-named recs when enabled; historical keep-all when off), - the pump's sweep-captured-launch request and copy fallback. sema_gr_xlate=1 restores the full translator (r730 re-verified: launch captured, page-notes, copy pend/done, submit refused n_data=0, release authored, client completes). Flip the default once the two CUDA-side hazards (stale-VAS resolution widening, rec-filter interaction) are eliminated and the battery is proven clean with it on.
* vgsp-sema: SESSION 127 C5C0 TRANSLATOR v1 - the Vulkan compute launch ↵Arthur Hanson Rasmusson33 hours
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | captured, filled and forwarded (and its copy-out executed) through the CUDA QMD machinery The Vulkan client's compute dispatch is an inline-QMD launch that lives in the PRE-BUILT ring continuation beyond GP_PUT (the earlier analysis only inspected the put-bounded pushes' idx7/idx12 and concluded 'no inline QMD'): beec0100 idx23 carries SET_INLINE_QMD_ADDRESS_B (0x31c = 0x4b85f, the upper half absent) plus the 64-word LOAD_INLINE_QMD_DATA (0x320) run - grid 40x30, prog=0xdfd8feb900 (the SASS page), param=0x4b86000, release0=0x4b85e08/1 - and idx24 carries the TURING_DMA_COPY_A (0xC5B5, subch 4) image->buffer copy-out (src=0xdfd8d60000 dst=0x050b0000, 640x480 RGBA rows) plus the SEND_PCAS schedule (0x2b4 = qmd>>8, 0x2bc = SCHEDULE). Pieces landed (all service-thread, all bounded/logged): - svc_gr_ahead_push (the sema_gr_ahead sweep parser) is now a strict tail-aware translated decode of one continuation entry: it accepts a method stream whose final inline run is completed from the NEXT ring entry (the driver splits big LOAD_INLINE_DATA payloads into a dedicated data slot entry: beef0100 idx00->idx01 256 B, idx08->idx09 12288 B), feeds the C5C0 inline-QMD window to svc_qmd_accum (capture via the standard CUDA QMD candidate), materializes GRCE/KEPLER_INLINE_TO_MEMORY_B LOAD_INLINE_DATA writes into the VA shadow exactly like the main decode (once-only keyed; recorded in the dst ring for the fill's inline-served pages), parses the C5B5 copy operands (0x400/0x404/0x408/0x40c/0x410/0x414/0x418/0x41c, 0x300 LAUNCH_DMA, 0x700/0x708 remap) into a pending copy list, and queues the release groups minus a release a live launch candidate owns (that word belongs to the completion edge, so the client's fence can never clear on a pre-render image). - The parser reads the run data words correctly (w3 fix; the GRCE 0x18c operand was being read from the next run's header word, which sent the 1568 B parameter-bank write to a bogus destination). - svc_qmd_accum: accept the ADDRESS_B-only inline-QMD form (implicit zero upper half) so qmd_dev_va is real for the Vulkan launch. - svc_gr_page_note + svc_gr_req_fill: resolve a client-VAS page through the registered-VAS walk when the trusted sources do not carry it (the Vulkan QMD's program/parameter/descriptor pages are client-managed vidmem; the fill refused the whole launch with -ENOENT before this). - The QMD capture's inline recs are filtered to the pages the captured QMD names (a stale session-wide rec destination made the fill refuse with ENOENT va=0x80412000 qmd_word=NONE). - Pending GRCE copy-out list executed on the launch completion edge (svc_fwd_hold_gr_release and svc_fwd_outcome_check) before the guest release is authored, with a bounded no-forward fallback at the sweep; the copy itself runs through the standard svc_copy executor (observed: 'copy done h=0xbeec0100 dst=0x50b0000 bytes=0x12c000 rows=480 rc=0'). - The pump offers a sweep-captured launch every pass (svc_gr_request) - the continuation launch's only dispatch path - and retires pending copies when no forward is owed. - gsp_phys_gr_min_data (module param, default 16): the degenerate-data-set refusal threshold is now tunable; the Vulkan dispatch's operand set is a handful of records, not the CUDA-era 968. - Bounded witnesses for the request paths (first-N/periodic: no-candidate, backend-not-ready, hold-busy, inflight-busy, fill-ENOENT) and the capture tail dump is now sema_dbg-gated with a 4/boot budget (it flooded dmesg). Live status (r726, cycles r719..r726): the client runs green through the fence (VKFRAME seq/DONE/IDLE, 3 PPMs) with no in-flight client assist; the sweep captures the launch ('launch captured ... qmd=0x4b85f00 prog=0xdfd8feb900 param=0x4b86000'); the fill resolves the QMD pages (page-note src=walk) and now passes its ENOENT gate; the copy-out executes for every frame. The physical launch itself is still refused: the fill yields n_data=0 because the launch's operand CONTENT (the SASS at prog=0xdfd8feb900, the descriptor data) is delivered by the driver through the MME / inline-to-memory engine upload stream (beec0100 idx7/idx12, beef0100 idx08), which the emulation does not execute - the pages the QMD names stay zero in the emulated vidmem. That engine-side upload path is the next work item; sessions r719..r726, evidence in the handoff. No host reboots; 0 oopses; the fetch of the CUDA battery on a fresh boot follows separately.
* docs/04-real-render-walls: SESSION 126 update - the fence fold landed ↵Arthur Hanson Rasmusson34 hours
| | | | (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
* tools/guest-diag: fenceword_assist.py marked SUPERSEDED (SESSION 126 fence ↵Arthur Hanson Rasmusson35 hours
| | | | fold, 95e7f57e) - the service now authors the Vulkan fence releases itself via the sema_gr_ahead ring-continuation sweep (r717 evidence: sema-ahead h=0xbeec0100 put=11 swept=10 rels=4 -> sema-svc: deferred release va=0x45ba090 payload=1 (was cur=0) x3, VKFRAME seq/DONE with NO assist); keep as A/B fallback for boots without the fold (sema_gr_ahead=0); evidence in backups/evidence-20261002-victory/r717-fencefold/ (gitignored)
* vgsp-sema: SESSION 126 FENCE FOLD - channel-anchored sweep of a GR channel's ↵Arthur Hanson Rasmusson35 hours
| | | | PRE-BUILT ring continuation beyond GP_PUT (sema_gr_ahead, default 64): the live Vulkan client's fence waits never clear because the driver's kick boundary stops at the first batch (put=11) while the ring already carries the continuation entries (12..47) whose INC-5 RELEASE groups target the fence words - r716 ring dumps: beec0100 idx17 0x49035b0 len=1020 (group at +0x374 -> 0x45ba080), idx25/33/41/46 at 0x4903f5c/0x4904594/0x4904bb4/0x49051d4 (len 136/112 -> 0x45ba090), all beyond the GP_PUT-bounded walk; the sweep walks entries beyond put through the ring's validated GPFIFO translation, accepts only entries passing the strict method-stream gate (all fence entries parse), extracts addr-0x5c count>=5 RELEASE/REDUCTION groups and queues them forward-only via the standard pending ledger - no consumption bookkeeping touched, idempotent, gated by gr_pub_armed (live epoch) and rrc==0; also: sema-pushdec budget 512->2048/client (boot-time driver-init reads exhausted it before the client's first submit on r716) and chan_dump gains armed=%d
* tools/guest-diag: fenceword_assist.py - host assist that releases the live ↵open-iov35 hours
| | | | vk_frame120 Vulkan fence wait word (session 125): the fence word is the +0x90 slot of the same 16 KB /dev/nvidiactl BO whose +0x80 slot carries the t122 BW init wait word; the assist finds the BO in the client's rw-s mappings (init word 1, fence word 0) and writes 1 to +0x90 per submit. With it, the t122 client reaches VKFRAME seq=1..3/DONE and writes real PPMs to /tmp/vkout (r715: vk-0001..0003.ppm, content still black - the GR shader work is the next gate, not the fence). This tool is the direct predecessor of the service-side fold: the submit push carries an INC-5 group targeting the same slot (observed [2005c017][0x45ba090][0][payload 1][0][0x02100001]) and the service's translation for that VA is correct (verified against the client pagemap), but the group sits in a push region the decoded entry windows do not cover - next: dump the full 11-entry rings and find/cover that entry.
* vgsp-sema: THE CONSUME-WITHOUT-DECODE BRANCH FIXED - the strict ↵open-iov35 hours
| | | | | | | | method-stream parser rejected the real driver's push shapes (op 0 = NVC06F_DMA_SEC_OP_GRP0_USE_TERT, observed 0x0001fff0 SET_SUBDEVICE_MASK; zero NOP padding mid-stream), so every large GR submit push read implausible and was skipped unread; plus the sema-pushdec branch witness (va/src/pa/plausible/injected/ipin/zero_nop/displaced/unreadable/first8, 512/client), the injected flag now follows the source that ACTUALLY answered the read (src 0 only - a page-granularity ipin lookup could take the injected branch while the read used the trusted walk src 4), the PA of the winning read source is recorded (svc_read_last_pa), and svc_push_prefix_ok accepts the same header-only ops r715 in-run validation (mdev b4ccb179, t122 recipe + content-located PDB anchor via pdbtick + rewind): the 1432/976/17316-byte GR pushes now reach svc_decode_stream (sema-pushall rows) and decode with releases: 'sema-push: h=0xbeec0100 va=0x4ca0f1c len=17316 rel=0x4b17c30 pay=3 have_rel=1', 'va=0x4ca0000 len=1432 rel=0x4923000 pay=1 have_rel=1', 'va=0x4ca059c len=976 rel=0x4b17bb0 pay=3 have_rel=1', CE 'va=0x4d00000 len=204 rel=0x4b19b10', plus the same shape on h=0xbeee0100; service applied=29 miss=0; the release words read back 1 in guest RAM (sema_probe 0x4923000..0x49230a0, 0x4b17xxx, 0x4213xxx all advanced). The sema-pushdec rows name the branch and content on every read (e.g. 'va=0x4ca097c len=4 ... plausible=0 zero_nop=0 unreadable=1 first8=00000000 00000000' for the all-zero 4-byte kicks). REMAINING GATE (session 125): vkWaitForFences still times out (~70 s of the client's 120 s bound, UMD-internal cap) even with all push releases applied - the fence wait word is NOT among the eleven released semaphores (released words verified 1 in RAM; the client's wait does not go through the eglcore+0xDCEBD9 device-wait-word chaser that carries the init wait at +0x80 of a 16 KB nvidiactl BO; 16 blind writes to zero wait-slots did not flip it). Next: enumerate the UMD wait-check helper via the vtable at the 0xDCEBD9 site (checkfn=*(*(void**)rbx+0x18)) and breakpoint it for every wait word, or trace the guest kernel poll(NV_DEVICE) handler for the fence object.
* vgsp-sema: raise the sema-rdw witness budget to 6000/client and log the ↵Arthur Hanson Rasmusson36 hours
| | | | viawalk retry outcome (walk rc, pa, plausibility) - session 124 evidence: for the GR submit push 0x4ca0000 the read returns rc=0 src=4 (trusted) even AFTER the user VAS registers and walk_probe rc=0, yet NO viawalk row and NO decode row appear and the entry skips after ~250 rescues: the entry is consumed between the read and the decode (plausibility passed but the decode never ran, or an earlier branch took it) - next: witness the branch taken after the read (plausibility verdict, injected/zero_nop/displaced flags)
* vgsp-sema: per-client unconditional push-read attempt witness - sema-rdw ↵Arthur Hanson Rasmusson36 hours
| | | | (h/va/len/rc/winning-src, budget 400/client, reset in svc_session_flush) at the pump read site plus the r707x src out-param (svc_read_last_src) inside svc_read_va_push_ex; also per-client reset of the sema-pushfail budget. r713: the run reproduced VKDEVICE+flips+VKFAIL but the witness rows scrolled out of the 2 KB dmesg ring before capture - the next run must read dmesg immediately after the first skips (or raise the ring buffer)
* vgsp-sema: on an implausible primary push read for a GR entry, retry via the ↵Arthur Hanson Rasmusson36 hours
| | | | DIRECT registered-VAS walk (svc_walk_vaspaces + svc_read_ap, the exact path walk_probe proves) instead of svc_lookup_trusted - whose pin/lat hits would answer with the same wrong page again; r711/r712 evidence: the user VAS registers and walk_probe rc=0, the rewind replays, but the retry/log never appears and the entries still skip after ~250 failed rescues (the sema-pushfail witness budget is per-boot and was exhausted earlier, so the read-failure detail was invisible this boot)
* vgsp-sema: every-pass VAS candidate verify with the last-good ring pair ↵Arthur Hanson Rasmusson36 hours
| | | | (r707e) - the r710 boot shows the host content-located trigger registers the user VAS and the walk resolves (walk_probe va=0x4ca0000: vas[3] h=0xfade0002 pdb=0x101d63000 -> rc=0 pa=0x11fa20000), while the pump's own svc_lookup pair only registered the three internal VASes (all rc=-2); the working order is: content-located trigger FIRST (registers the user VAS), then sema_chan_rewind so the replay re-reads the entries with the working VAS
* vgsp-sema (FOLD): verify the parked COPY_SERVER_PDES VAS candidates the ↵Arthur Hanson Rasmusson37 hours
| | | | moment any channel's ring resolves through the channel object, so the user-VAS page directory can register BEFORE the submit's first push reads (the host-triggered path could not win that window: a failed GR entry read is never retried with the fresh VAS); r709 evidence: three VASes registered (h=0xc/0xbaba0042/0xcaf00000, pdb=0x11b8db000/0x11b8e6000/0x11b8ef000) and walk_probe still rc=-2 for the client's push VAs - the registered directories do not cover the user VAS, so the content-pair verify against the ring must still land for that one
* vgsp-sema: bounded channel rewind (sema_chan_rewind: hex h_object or 'all' ↵Arthur Hanson Rasmusson37 hours
| | | | -> clears slot_done_epoch + last_get + the per-entry rescue state so entries skipped before the VAS pdb anchor re-decode) + bounded per-chunk push-read failure witness (sema-pushfail: va/chunk/page/last_rc/trusted_rc/ipin/alt/win per failed chunk); wall2: runbook.py (trigger the anchor then rewind). Session 118: the anchor+rewind path is wired; the automated rewind scheduler missed (dmesg churn) and the pushfail trace still needs one clean capture
* wall2: pdbtick.py loops (retry content-location + trigger every 1 s); ↵Arthur Hanson Rasmusson37 hours
| | | | session 117 evidence: the host-triggered pdb anchoring WORKS end-to-end (sema-pdb-disc -> 'VAS 0xfade0002 page directory registered after verified ring walk (pdb=0x109277000 entries=4 ap=1)'), the small GR pushes decode after the anchor (sema-push: h=0xbeec0100 va=0x4ca096c/0x4ca52c0), but the large ones (976/1432/17316 B) still skip after 210-275 rescues and the fence never releases - next: why the multi-page push reads/plausibility fail for the big pushes (the compute dispatch and the tracker), and give the pump a rewind/replay so already-skipped entries re-decode
* vgsp-sema: host-triggered VAS pdb discovery (sema_pdb_discover va,pa -> ↵Arthur Hanson Rasmusson37 hours
| | | | verify the parked COPY_SERVER_PDES candidates against a content-verified ring pair, then fall back to the vidmem walk-root sweep) + runtime-tunable candidate age-out (sema_vas_cand_ms; the default 15 s ages the client's VAS candidate out exactly when its channels first register, so the verified walk can never anchor it by itself)
* vgsp-sema/wall2: host-triggered VAS pdb discovery (sema_pdb_discover va,pa ↵Arthur Hanson Rasmusson37 hours
| | | | -> verify the parked COPY_SERVER_PDES candidates against a content-verified ring pair, then fall back to the vidmem walk-root sweep) and a runtime-tunable candidate age-out (sema_vas_cand_ms; the default 15 s ages the client's candidate out exactly when its channels first register); tools: fasttick.py (triggers on the GR0 ring resolution line) and pdbtick.py (content-locates the ring page and triggers) - r706/r707 evidence: three parked candidates (0x11cd3d000/0x11cd48000/0x11cd50000 entries=4), the ring pair appears only at channel registration (the same second as the age-out), ring resolution is racy across runs (r706 rc=0 / r707 rc=-2), the skip starts 145-194 rescues (~8-10 s) after the submit; next run: keep candidates parked + trigger within the window
* wall2 session 115: decompose the first-fence wall - the sema service cannot ↵Arthur Hanson Rasmusson37 hours
| | | | decode the submit's GR pushes because the client VAS page directory is undiscoverable (walk_probe: discovered pdb=0x0; the COPY_SERVER_PDES candidate is garbage; the r496f vidmem discovery never runs) and the pushbuffer is noncontiguous; the RAM ring scan gives up after 12 slices before the pushes exist; ring pages ARE content-locatable by their GPFIFO entries and injectable via sema_map_add (fence_assist.py) but the ring pair alone does not unlock the push decode; next = extract the pdb from the guest kernel's RM objects (PDB injection) or scan vidmem with the ring pair as verifier
* wall2 session 114: the COMPR+2MB VidHeap class (attr&0xF000==0x2000, owner ↵Arthur Hanson Rasmusson38 hours
| | | | 0x474C0000) is the last allocation gate - a live attr flip (COMPR_ANY->NONE at the ioctl) lets vkAllocateMemory through and the client runs the whole pipeline to the FIRST vkQueueSubmit, then times out on the FIRST fence (30 s, the new wall); the zero-touch create recipe is BC (eglcore+0xB33D30 marker clears) + BW (eglcore+0xDCEBD9 device wait-word chaser, the missing piece) + the a8clear count gate; the fence release (push-page readability/completion after the submit) is the only remaining gate to VKFRAME
* tools/vk: vk_frame gains an optional 7th arg (tiling: 0=optimal default, ↵Arthur Hanson Rasmusson38 hours
| | | | 1=linear) and a buffer-allocation type-retry loop; wall2: the QEMU-gdbstub kernel-breakpoint script (module VAs insert+patch but never fire - the stub's memory context does not resolve module VAs) and the kcore symbol dumper; session findings: the vkAllocateMemory -2 = the image's internal COMPR 2MB-page 64KB sub-allocation failing NV_ERR_NO_MEMORY after the image data alloc succeeds (both tilings)
* vgsp-rm: FB_GET_INFO_V2 COMPRESSION_SIZE reports a comptag pool ↵Arthur Hanson Rasmusson39 hours
| | | | (wall2_fb_compr_mb, default 128 MiB) - the guest driver attempts a COMPR-enabled 64 KB-aligned comptag allocation (vendor VidHeap alloc attr COMPR=2, r703 live: the last vidheap call returns NV_ERR_NO_MEMORY 0x51) and libcuda maps that to VK_ERROR_OUT_OF_DEVICE_MEMORY (the vkAllocateMemory -2 that gates the first Vulkan frame); 0 restores the historic no-compression reply for A/B
* vgsp-rm: answer the NV04_VID_HEAP_CONTROL enumeration pair ↵Arthur Hanson Rasmusson39 hours
| | | | 0x90960106/0x90960107 (legacy NVOS32 VidHeap API) - libnvidia-eglcore walks three heaps and treats an all-zero reply as 'no memory' (the flag byte at entry+0x30 == 0 skips every heap), so vkAllocateMemory failed -2 without any alloc reaching the emulation; replies are runtime-tunable (wall2_9096_lo/hi/ent_addr/ent_size/ent_type/ent_flag) for a one-boot sweep
* vgsp-sema: bind the scrub slot to the EXACT 4096-entry channel ↵Arthur Hanson Rasmusson39 hours
| | | | (NUM_COPY_BLOCKS) - the >=4096 test also matched every client channel (32768 entries in this driver version), so the pass authored for whichever client channel registered last while the real scrubber's finish payload stayed zero (the vkAllocateMemory -2 gate, r701 live evidence: slot held h=0xbeee0102/entries=32768 and the pass logged 'scrub author put=0')
generated by cgit v1.2.3 (git 2.39.1) at 2026-10-27 10:53:00 +0000