[jamesbraid]

Adds the Octane's VPro (Odyssey) graphics boards, ported from my sgi-origami QEMU branch. An Octane2 with a V12 boots IRIX 6.5.30 to the 4Dwm desktop on one or two CPUs, and OpenGL works: Smoke & Mirrors, OpenGL Performer's truck demo, Inventor's ivview, SGI Quake and the gltest suites all draw.

To use one, pick the board in the machine's config:

[graphics]
board = "v12"   # or "v6", "v8", "v10"

IMPACT stays the default, and other machines refuse these values. IRIX needs an install with the VPro kernel driver and X module; an IMPACT install finds no screen.

Speed

The first port drew under a board lock on the CPU thread. Most of the work since has been making it fast without that lock. Frames per second on an Octane2 V12 with IRIX 6.5.30:

	first port	this PR
Smoke & Mirrors	0.4	5.9
Performer truck	13.5	36.7
SGI Quake timedemo (640x480 window)	didn't run	3.8
SGI Doom timedemo	didn't run	71.8

Design

• No lock around the board. Four threads touch it: the processors, the front end (decodes the command FIFO and owns the board's state), the raster unit (owns the planes) and the display (reads the frame through its own reader). Command stores queue in the shared GFifo at the board's real depth. Waiting reads and swaps keep the order the driver relies on, and two processors may store to the FIFO. gfifo gains peek_nth_at, peek_run_at and consume_n_at so the front end can take a run of stores with one head publish. clanker/odyssey has the thread and ordering notes, and HACKING.md lists the new threads.
• Shared GL core. Transform and lighting are the existing gl code, now generic over a compile-time Geometry. Frustum is today's pipeline for GR2 and IMPACT. NearW is the VPro's: a nearest-rounded reciprocal and a multiply for the divide, truncation onto the 1/256 subpixel grid, and clipping on x, y and a near-w plane only, with near and far left to a per-fragment depth kill. The existing methods are the Frustum instantiation and monomorphise to the same arithmetic. A randomised differential of 200,000 polygons and lines hashed identically before and after, so IMPACT output is unchanged. Lighting also gets a Default.
• Typed texture sampler in the board's texturing path, rather than raw word access.
• The rest of the board is arranged by function: widget registers and identity, memory and DMA, the FIFO interpreter, integer drawing, off-screen objects, pixel DMA and scanout.

The Octane2 parts

The board sits on widget 11, where IMPACT otherwise goes. The V10 and V12 only shipped in the Octane2, so choosing one makes the machine an Octane2: Crossbow revision code 5 and a revision 4 Bridge (the Octane's are code 4 and revision 3), which the PROM's board detection reads. There is no separate machine option. The Bridge revision is now settable and survives a reset. iris warns at start-up if the PROM image is older than the board needs (4.5 for V10/V12, 4.0 for V6/V8, from SGI's upgrade-kit notes).

These registers and the board's bus-visible behaviour follow what the PROM and driver read and write. Where the hardware is not known, the board makes a stated model choice. The Crossbow reset fences, for instance, hold their values but gate nothing, because no warm reset travels through the modelled switch.

Testing

• Octane2 V12, IRIX 6.5.30: boots to 4Dwm on one and two CPUs; mirrors, perfly, ivview and gltest draw.
• pixtest passes 323 of 380 cases and glstate 410 of 415. The failures are colour-index mode, pixel scale-bias and maps, and RGBA8 textures from byte, short and int data; they're the same before and after this rework. The VPro expectations follow established library behaviour (raster distance, the depth range's 2S factor, the RGB short-read row stride), with no expected-failure entries.
• The points, lines, triangle and alpha frames of the board diagnostic's expected output match exactly at 1280x1024.
• cargo test --release --lib --features jitv2: 2795 passed.
• Draw-level golden frames (91, bit-exact by default) drive Board::gl_draw the way the GL context does and hash colour, depth and stencil, with a vertex golden for eye, clip and window positions and lit colours. scripts/vpro-goldens.sh has the commands, and testdata/README.md says when re-taking is right.
• Headless replay feeds an IRIS_ODSY_REC recording through a fresh board and hashes the planes and object memory. Recordings stay out of git, so without one the test prints SKIPPED.
• The vpro monitor command counts bus refusals and display work.

Not in this PR

• The Octane IOC3 and 16550 changes are in misc fixes: Octane IOC3, 16550 loopback, idle CPU, SEEQ drop count #367.
• The rest of the QEMU Crossbow work (illegal destinations, link tracking), beyond the code-5 registers the V10 and V12 need.

[jamesbraid]

don't merge; still working on refactoring :)

[techomancer]

in actual hardware the display and rendering engine talk to memory at the same time and there is are not mut borrows or locks.
the safety and synchronization are guaranteed by software programming the hardware to do buffer swapping or syncing using fences, synchronization bits and such. trying to be more safe than that doesn't buy us anything besides slowing the implementation down.
if we see synchronization problems it means we didnt implement the behavior correctly.
as a corollary we often see flashes of wrong planes and colors on other boards. funnily enough they do happen on real hardware too.

[Samueltgg12]

@techomancer review time. it's gonna be big.