显示呈现 — Wu Chenfeng

GPU帧时间稳定，不代表按键很快出现在屏幕上。显示呈现还包含交换链、Present与扫描节奏，CPU-GPU排队增加吞吐也可能增加延迟。VSync与VRR分别约束不同等待关系。

CPU-GPU 并行和帧延迟

CPU 可以在 GPU 渲染第 $N$ 帧时准备第 $N+1$ 帧。好处是吞吐量高，代价是输入到显示的延迟可能增加。

当 CPU 过快时，Fence、Swapchain 帧数或引擎的最大排队帧会限制它。调用会等待 GPU 的 Readback、资源重用或同步点时，CPU-GPU 并行会被打断。

Swapchain 与显示呈现

Swapchain 保存一组可轮换的显示图像。GPU 渲染 Back Buffer，Present 再把完成的图像交给显示系统。双缓冲或三缓冲影响等待方式、吞吐和额外延迟。

没有同步时，显示器可能在一次扫描过程中读到两帧，形成 Screen Tearing。VSync 让显示切换遵循刷新边界，从而避免这类撕裂；GPU 错过刷新窗口时可能需要等待，增加输入延迟。Present 通常只是排队请求，是否允许撕裂由呈现模式及窗口系统配置决定。可变刷新率（VRR）让显示器在支持范围内跟随帧完成时间，减少固定刷新下的重复帧和等待。它仍需要帧率上限、排队帧和低延迟策略配合。

帧率稳定不等于低延迟。分析呈现问题要同时记录 CPU 提交、GPU 完成、Present Mode、Swapchain 队列和显示刷新时间。

呈现时间线

流程示意分别记录CPU提交、GPU完成与显示扫描，不把Present返回当作全部图像已经显示。

text

input -> CPU simulation -> command submit -> GPU complete
      -> present queue -> display scan

在简化60Hz FIFO模型里，刷新起点为0、16.67、33.33、50毫秒，假设图像在刷新起点已完成就能被选中。A于5毫秒完成，B于13毫秒完成，C于21毫秒完成。16.67毫秒显示队首A，33.33显示B，50显示C；C的GPU工作即便只有8毫秒，完成后还等待约29毫秒。若采用允许替换待显示旧图的模式，16.67时可能选B，结果取决于呈现模式。真实扫描还从上到下进行，不同像素的出现时刻不同，因此这里算的是扫描开始，不能直接当作整屏输入延迟。

队列与缓冲的区别

交换链图像数决定可轮换的图像资源，CPU允许提前准备的帧数决定工作排队上限，两者不必相同。假设显示器固定60Hz，一次刷新约16.67毫秒。某帧即使只需8毫秒GPU工作，前面若还有两帧等待显示，输入仍可能多等待约两个刷新周期。这只是FIFO且无丢帧的时间线例子，邮箱模式、桌面合成器及VRR会改变等待关系。

Vulkan中等待一次提交的fence，只证明该批命令完成，不能据此断定Present已消费它等待的信号量。常用做法是按在途帧索引管理命令缓冲和提交fence，按交换链图像索引管理供Present等待的二进制信号量。重新获取同一图像并等待获取信号后，才能利用这条顺序关系安全复用对应呈现信号量。

text

等待 frameFence[frameIndex]，回收该帧命令与临时资源
获取 imageIndex，并得到 imageAvailable 信号
提交命令：等待 imageAvailable，写图像，发出 renderFinished[imageIndex]
呈现 imageIndex：等待 renderFinished[imageIndex]
推进 frameIndex；下一次获取的 imageIndex 由交换链返回

这是资源归属伪代码，接入时还需处理获取失败、交换链重建、布局转换、队列族和fence重置时机。获取失败而未提交工作时，不能把尚未重新关联提交的fence留在永久未完成状态。

验证方法

记录帧限流、交换链与显示模式，比较提交至完成和完成至显示延迟。GPU积压、错过刷新与VRR范围外行为分别测试，性能与输入延迟各使用实际测量。

验证范围：时间线是60Hz FIFO模型，信号量寿命已对照Vulkan Guide；未执行显示延迟测量或交换链工程。验收需分别观察提交完成、图像获取和呈现事件。

参考资料

Khronos Vulkan Guide，Swapchain Semaphore Reuse：2026-10-22核读Problem Statement和Discussion of Solution，支持提交fence与呈现消费的区别，以及按图像索引管理信号量。