Card-rendered 3D in an X window (GXT120P -> Xvnc) - prediction log.
Author: Claude Opus 5.5 (claude-opus-5-5). Series letter: D.
Written after measuring direct framebuffer reads (64.4 ms per 640x480x16 frame, 9.5 MB/s, with
an idle machine) and reading the MGA-1064SG IDUMP section, before any IDUMP or X code ran.
Format: ID [confidence] claim.

--- round 1 ---
D01 [0.55] IDUMP (engine copies VRAM out through the 7 KB DMAWIN, read with incrementing
    addresses) reads a 640x480x16 frame at least 1.5x faster than direct framebuffer reads
    (i.e. in 43 ms or less).
D02 [0.25] IDUMP reaches 20 MB/s or more.
D03 [0.70] With OPMODE dmaDataSiz = 01 (16-bit B), the dumped words arrive in the 604e's
    byte order: a 565 pixel reads back as the same 16-bit value the engine wrote, unswapped.
D04 [0.85] The first IDUMP test (one 8-pixel line) neither hangs the engine nor the machine.
D05 [0.60] Xvnc 3.3.3 on :5 supports MIT-SHM, and XShmPutImage works from a program on obsidian.
D06 [0.65] End to end (render, read back, convert, put into an Xvnc window), the textured torus
    at 320x240 runs between 8 and 20 frames a second.
D07 [0.75] At 640x480 end to end it runs below 10 frames a second.
D08 [0.50] Converting one 320x240 565 frame to Xvnc's 32-bit pixels takes under 4 ms on the 604e.
Wed Oct 14 16:15:52 MDT 2026

=== OUTCOMES (scored 2026-10-14) ===
D01 MISS     [0.55] IDUMP reads a 640x480x16 frame in 53.2 ms with 64-bit loads (57.7 ms with 32-bit),
    against 64.4 ms for direct framebuffer reads: 1.21x, not 1.5x.
D02 MISS     [0.25] 11.7 MB/s at best.
D03 HIT      [0.70] First dwords 00001001h 20023003h ...: pixels 0000h 1001h 2002h 3003h in order, in
    the 604e's byte order, no swapping needed.
D04 HIT      [0.85] One 8-pixel line came back correctly and STATUS showed the engine idle.
D05 HIT      [0.60] XShmQueryExtension is true on Xvnc :5; XShmPutImage of 320x240 takes 7.7-8.1 ms,
    XPutImage 29.3 ms.
D06 MISS     [0.65] 21.3 fps at 320x240 (median frame 46.9 ms): just above the 8-20 I named.
D07 HIT      [0.75] 7.8 fps at 640x480 (128.2 ms).
D08 HIT      [0.50] 3.2-3.8 ms per 320x240 frame.

Calibration:  <0.50: 0/1   0.50-0.79: 4/6   >=0.80: 1/1
Not predicted: the engine can't draw at a pitch of 320 (PITCH must be a linearisable value: 512,
640, 768 ...); my first 320x240 frames were garbage, and my IDUMP test hadn't caught it because
IDUMP takes its stride from AR5. Xvnc's 24-bit visual is BGR (red mask 0000ffh). A Netscape left
on :5 since 03:23 had been taking most of the CPU: with it, direct reads took 171 ms, not 64.
Card time hardly changes with size (21.7 ms at 320x240, 24.5 at 640x480): register traffic and
setup dominate, not pixels.

--- round 2, after the hang (obsidian power-cycled), before the deliberate wedge test ---
D09 [0.70] A process killed (SIGKILL) partway through reading an IDUMP leaves the engine busy:
    the next owner of the card reads STATUS with the drawing-engine busy bit (bit 16) set.
D10 [0.75] tex3d's soft reset at t3_open (RST bit 0 held 200 us, then an OPMODE byte write)
    recovers it: t3dbg then draws, reads back all 240 rows correctly, and obsidian doesn't hang.
Wed Oct 14 17:55:24 MDT 2026

=== OUTCOMES (round 2, scored 2026-10-14) ===
D09 HIT      [0.70] After wedge (SIGKILL after 2000 of 38400 IDUMP dwords) the next owner read
    STATUS 00030004h (bit 16, engine busy), and OPMODE still had the dead process's dmaDataSiz (100h).
D10 HIT      [0.75] After the reset STATUS was 00020000h; t3dbg drew, read back all 240 rows
    correctly (after fixing t3dbg's own pitch, still 320 from before the 512 fix), and obsidian
    stayed up. Three wedge/recover cycles, all the same.

Calibration (rounds 1-2):  <0.50: 0/1   0.50-0.79: 6/8   >=0.80: 1/1

--- round 3, X sharing: before any probe with X running (2026-10-23) ---
Known: in series G, GSC_HANDLE on /dev/rcm0 failed with EBUSY while X ran; MAKE_GP was never
reached. Headers read: aixgsc.h (SHARE_ACCESS = 0), rcmioctl.h (RCM_QUERY, RCM_SET_DIAG_OWNER),
lft_ioctl.h (LFT_ACQ_DISP/LFT_REL_DISP), signal.h (SIGRETRACT 61, SIGGRANT). Console X on :0 is
at the dtlogin greeter, no one logged in.
D11 [0.85] GSC_HANDLE for "mga0" still fails with EBUSY while the console X runs.
D12 [0.70] GSC_HANDLE fails the same way (EBUSY) for any devname, including a nonexistent one:
     the RCM refuses a second graphics process before looking at the device name.
D13 [0.45] RCM_QUERY works as claude (0666 device) and returns something non-empty.
D14 [0.80] rcm_loadpin checks for root (or a privilege) on RCM_SET_DIAG_OWNER: there is a
     privilege-check call (privcheck/suser) somewhere in the RCM's ioctl path.
D15 [0.40] The console X server (or a module it loads) installs a handler for SIGRETRACT (61).
D16 [0.60] mgadd_pin has no RCX entry points (create_rcx, switch/give-up context): only
     make_gp/unmake_gp plus init, as the series G notes say.
Fri Oct 23 01:23:53 AM MDT 2026

=== OUTCOMES (round 3, scored 2026-10-23) ===
D11 HIT      [0.85] gscprobe: GSC_HANDLE "mga0" rc -1 errno 16. rcmioctl: the display entry's in-use bit is set
     and its owner pid (the X server) isn't ours.
D12 MISS     [0.70] other names fail with ENXIO (6): the RCM finds the device first; EBUSY is specific to an
     owned display.
D13 MISS     [0.45] returns 0 but writes nothing: RCM_QUERY's case in rcmioctl's jump table is the exit.
D14 MISS     [0.80] no privilege check anywhere on the path: rcmioctl copies the argument in, finds a display
     that already has a graphics process, and calls fp_ioctl(lft, LFT_SET_DIAG_OWNER) from the kernel;
     lft's handler refuses only if the lft itself is using the display (EBUSY), else sets flag bit 0.
     rcm_loadpin imports no privcheck/suser at all.
D15 UNPROVEN [0.40] no "retract" string or handler found in X or loadddx, but a signal number is just a
     constant; moot anyway: nothing in the RCM sends signal 61.
D16 HIT      [0.60] mgadd_pin exports mga_make_gp/unmake_gp, CRTC/RAMDAC setup, power management and the
     vtt* console text functions; no context switching.

Calibration (round 3):  <0.50: 0/2 (1 miss, 1 unproven)   0.50-0.79: 1/2   >=0.80: 1/2
Not predicted: the RCM's only "X, let go" mechanism is power management (signal_X_to_quiesce_dsp_devices
sends signal 31; X has pm_prepare/pm_activate, loadddx has sb_SaveState/sb_RestoreState), and X keeps
ownership through it. RCM_SET_DIAG_OWNER is open to any user through 0666 /dev/rcm0.