iris-hostgl, mgras: colour-index windows' frames composited as indices

[atomchild411]

iris-hostgl, mgras: colour-index windows' frames composited as indices

Under host GL, a colour-index window reached the screen only through the guest. This is IRIS GL's usual kind of window: flight's main window, and every overlay and pop-up window. The guest library read each frame back, turned it into indices on the emulated CPU, and put it to the X server with XPutImage. SGI's IRIS GL running on host OpenGL showed flight's full-screen 8-bit window at a frame every few seconds.

The change

• New OP_SWAP bits. OP_SWAP's seventh slot gains bit 2 (a colour-index window's frame) and bit 3 (an overlay window's). Such a frame goes to the display through a new Display::present_index_at. Its default is "not taken", so the guest puts the frame up as before on any display that doesn't implement it.

• On IMPACT, disp::composite_index writes each pixel's index where the board keeps that window's indices:

  • the low 8 or 12 main planes, by the window ID's display mode;
  • the high 12, when the ID shows buffer B;
  • or the overlay planes.

  The colour map then shows them as on the board. The index comes from red's byte and green's low nibble, which is how the host draws index contexts.

• Only where the window ID covers it. The frame is composited only where its window's ID covers at least three quarters of the window's samples on screen; otherwise it goes back to the guest. Just after a window is mapped, its ID may not be in the VC3's tables yet. Taking the commonest ID around then wrote into another window, and gltest's overlay check read 0s about one run in three.

• OP_INDEX_FRAMES (0x1_0013) answers 1, so a library can ask first. On an IRIS without this change it gets EINVAL and keeps putting colour-index frames up itself. Without the probe, such a host would composite the encoded RGBA as colours and report the frame as shown.

This touches src/dev/mgras/disp.rs and mod.rs (no overlap with #241), plus iris-hostcall's Display trait and iris-hostgl.

Tests

• Unit test: index_frames_are_asked_for.

• cargo test --manifest-path iris-hostgl/Cargo.toml: 33 passed on macOS.

• cargo test --lib mgras (features hostgl,jitv2,tcache,lightning,rex-jit,gr4-jit): 177 passed, on this branch with iris-hostgl: flush presents don't wait, and come at most once a frame #248 on top.

• On IRIX 6.5.22m, Indigo2 Max IMPACT, macOS host, with the guest tools release v20261017-proto2 (atomchild411/iris-guest-tools), which asks with OP_INDEX_FRAMES:

  • gltest all ok (n32, o32), including its overlay checks;
  • irisgltest's colour-index and overlay windows read back their indices: "1000 in the rectangle, 7 around it", "index 3 in the overlay";
  • its other 12 failures are the same 12 as under SGI's own libraries on the emulated board.

• The same release on upstream IRIS without this change asks, gets EINVAL, and passes the same checks the old way.

• On Linux (Debian 12 arm64 VM, Mesa 22.3.6), with this branch and the flush-presents one on top:

  • cargo test --manifest-path iris-hostgl/Cargo.toml: 33 passed;
  • gltest all ok (n32, o32), glcheck PASSED;
  • irisgltest's colour-index and overlay windows read back their indices.

  SGI's own IRIS GL on a Linux host also needs iris-hostgl: SGI_color_matrix's state on a host without a colour matrix (Linux) #246, which fixes a crash that exists without these changes too.

🤖 Generated with Claude Code