OpenGL实际上需要多长时间来更新屏幕？

我在C中有一个简单的OpenGL测试应用程序，它根据按键输入绘制不同的内容。（Mesa 8.0.4，在配备NVIDIA GTX650的PC上与Mesa-EGL和GLFW，Ubuntu 12.04LTS一起尝试过）。绘制非常简单/快速（旋转三角形类型的东西）。我的测试代码没有以任何方式故意限制帧速率，它看起来像这样：

while (true)
{
    draw();
    swap_buffers();
}

我对此进行了非常仔细的计时，发现从一个eglSwapBuffers()（或glfwSwapBuffers相同的东西）调用到下一个调用的时间约为16.6毫秒。eglSwapBuffers()即使画出的内容非常简单，从通话后到下次通话前的时间也仅比该时间少一点。交换缓冲区调用花费的时间不到1ms。

但是，从应用程序响应按键更改其绘画到实际在屏幕上显示更改的时间> 150ms（价值约8-9帧）。这是通过以60fps的屏幕和键盘的摄像机记录来测量的。

因此，问题是：

1. 在调用交换缓冲区与实际显示在屏幕之间的绘制在哪里缓冲？为什么要延迟？看起来该应用始终都在屏幕前绘制许多帧。

2. OpenGL应用程序可以做什么以立即绘制屏幕？（即：无缓冲，仅阻塞直到绘制完成；我不需要高吞吐量，我需要低延迟）

3. 应用程序可以做些什么来使上述立即抽奖尽快发生？

4. 应用程序如何知道当前屏幕上实际显示的内容？（或者，当前缓冲延迟是几帧/几帧？）

从CPU调用的所有绘图API函数都将提交到GPU 命令环缓冲区，以供GPU稍后执行。这意味着OpenGL函数主要是非阻塞函数。因此，CPU和GPU将并行工作。

需要注意的最重要的事情是您的应用程序可以绑定CPU或GPU。一旦调用glFinish，CPU应该等待GPU完成绘制命令，如果GPU花费更多时间并且可能/导致CPU停止运行，则您的应用程序受GPU约束。如果GPU完成绘制命令，而CPU花费的时间太长，无法完成glFinish，则您的应用程序受CPU限制。

请注意，glFlush和之间有区别glFinish。

glFlush：表示先前已发送到GL的所有命令必须在有限时间内完成。

glFinish：强制所有先前的GL命令完成。在完全实现以前发出的命令对GL客户端和服务器状态以及帧缓冲区的所有影响之前，Finish不会返回。”

glXSwapBuffers在返回之前执行隐式的glFlush。后续的OpenGL命令可以在调用glXSwapBuffers之后立即发出，但是直到缓冲区交换完成后才执行。

实际帧时间很可能由两个CPU / GPU中的哪个花费更多时间来完成工作来确定。

从技术上讲，OpenGL从不更新屏幕。

有一个与GL（例如GLX，WGL，CGL，EGL）分开的窗口系统API可以执行此操作。使用这些API的缓冲区交换通常会隐式调用，glFlush (...)但在某些实现中（例如Windows上的GDI光栅化器），它会执行完整操作glFinish (...)：

    ^{*左侧是穿过的ICD（硬件）路径SwapBuffers (...)。在右侧，是GDI（软件）路径。}

如果启用了VSYNC和双缓冲，则任何在挂起交换发生之前修改后备缓冲区的命令都必须停滞直到交换。命令队列的深度有限，因此该停止的命令最终将导致管道阻塞。这可能意味着在SwapBuffers (...)VBLANK出现之前，不是阻塞应用程序而是阻塞一些无关的GL命令。真正归结为交换链中有多少个后备缓冲区。

只要所有的后缓冲区都充满了尚未完成的帧，但仍要移到前，交换缓冲区将隐式导致阻塞。可悲的是，没有办法显式控制大多数GL窗口系统API使用的反向缓冲区的数量（除了0个单缓冲或1个双缓冲）。如果需要，驱动程序可以自由使用2个后备缓冲区（三重缓冲），但是您不能在应用程序级别使用GLX或WGL之类的请求。

我以为您熟悉这个实验？

本质上，约翰·卡马克（John Carmack）在做类似的事情，记录屏幕并计时发送到屏幕的像素。他发现很多延迟都来自屏幕。其他因素是键盘，视频驱动程序的输入延迟和/或程序本身的执行过程。