vgsp-sema: SESSION 127 C5C0 TRANSLATOR v1 - the Vulkan compute launch 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.

0 files changed, 0 insertions, 0 deletions