From 92a84f638e1cad9cdcccdf59ccfdbe9d33051dae Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Fri, 13 Nov 2026 13:03:18 -0500 Subject: vgsp: RM-record 3D attach + inside-run C597 openers for the direct-GL channel (eng23, mechanism validated) The direct-GL (GZDoom/glx) channel family 0xbeef01xx never opened a C597 section because its class bind is channel-side: the client allocates TURING_A (0xc597) with hParent = its own channel (measured: alloc 0xc597 h=0xbeef9097 parent=0xbeef0100 client=0xc1d00013) and never re-emits a SET_OBJECT push, so the section recognizer's sticky-attachment gate (svc_gl_att_accept_run) dropped every push. The X lane binds inline in its init push and was unaffected. - gsp_rm_emulation.c: report the 0xc597 allocation's hParent to the sema service (gsp_sema_service_gl_attach), which applies it as the sticky 3D attach on its own thread (pending-slot queue; no cross-thread writes to the attachment tables). - gsp_sema_service.[ch]: the queue + drain (svc_thread pass), and accept the inside-run opener shapes on attached channels: the direct-GL client emits NVC597_BEGIN (0x1618) and the RT-setup family (0x840) as methods INSIDE multi-method INC runs (measured: run addr=0x80c count=256 covers 0x840..0xc0c; census decoded method=0x1618 op=1 from a run payload), not as the one-word IMMD form the X lane emits. - Also carries the eng22-rescue scan-cap widening (0x4000000 -> full 2 GiB shadow; observed live: "no content-gated window in 0x80000000 shadow"). Validated live (c335/c337/c338, receipts /tmp/opencode/eng23-receipts-c331.txt): - RM-record attach fires and applies for 0xbeef0100 (c335 12:49:04, c338). - sections now open (c337) and capture (c338) on 0xbeef0100 incl. the 59556-B setup push and the 6400-B draw push (src=draw-synth). - first GR LAUNCH submitted for 0xbeef0100 (c338 13:01:58) - fails at the physical QMD release (qmd_rel=0xc0ffee01 want=0x600df00d); new frontier. - px0 still 00000000; mission not launched. A/B control: the same X-lane lottery behaviour was reproduced with the pre-change module (c333), so no X-lane regression is attributable here. --- kernel/gsp_rm_emulation.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'kernel/gsp_rm_emulation.c') diff --git a/kernel/gsp_rm_emulation.c b/kernel/gsp_rm_emulation.c index 957729b..b928faf 100644 --- a/kernel/gsp_rm_emulation.c +++ b/kernel/gsp_rm_emulation.c @@ -4273,6 +4273,25 @@ static void gsp_rm_handle_rm_alloc(struct gsp_emu_context *ctx, memcpy(&rp[3], reply + GSPRM_ALLOC_HDR_SIZE + 12, 4); gsp_rm_grobj_note(ho, class_id); + /* + * eng23 (CONT.483): the RM record is the direct-GL lane's + * class bind. The X lane carries its C597 SET_OBJECT inline + * in the init push (hw class bind, sticky); the direct-GL + * client's channel (0xbeef01xx family) binds the class + * channel-side - it allocates TURING_A (0xc597) with + * hParent = its own channel (measured: alloc 0xc597 + * h=0xbeef9097 parent=0xbeef0100 client=0xc1d0001a, twice, + * while 0xbeef0100 was a registered channel with engine 0) + * and never re-emits a bind push. Without the note the + * section recognizer's sticky-attachment gate drops every + * one of that channel's pushes and no C597 section is ever + * opened (CONT.481/482: 0 sections for 0xbeef0100 on a boot + * where the whole setup push was readable). Report hParent + * to the sema service, which applies it as the sticky 3D + * bind on its own thread. + */ + if (hp && hp != hc) + gsp_sema_service_gl_attach(hp, 0); if (rm->gr3d_alloc_log < GSPRM_GR3D_LOG_MAX) { rm->gr3d_alloc_log++; nv_vgpu_info(ctx->vgpu, -- cgit v1.2.3