ARB_sync和适当的测试

ARB_sync and proper testing

本文关键字：测试 sync ARB      更新时间：2023-10-16

我遇到了同步对象的概念，并决定对其进行测试。它们似乎按预期工作，但我目前的测试用例有限。

什么是

适当的测试，以确保这些同步对象按预期执行，作为将 CPU 呈现线程与 GPU 同步的一种方式？

这方面的一个示例用例是视频捕获程序，这些程序"挂钩"到视频游戏的OpenGL上下文中，或使用OpenGL的其他应用程序。

您的示例用例对我来说似乎很可疑。

FRAPS是一个程序的例子，它"挂钩"到OpenGL应用程序中以捕获视频，它的做法非常不同。FRAPS 不是强制 CPU-GPU 同步，而是在调用 SwapBuffers (...) 之前插入异步像素缓冲区读取。然后，它将尝试在下次调用SwapBuffers (...)时读回结果，而不是在结果第一次可用时停滞不前。延迟对于 FRAPS 无关紧要。

但是，即使没有异步 PBO 读取，FRAPS 也没有理由使用同步对象。 glReadPixels (...)和类似的命令将隐式等待所有挂起的命令完成，然后再读取结果并将控制权返回给 CPU。这确实会损害性能，但 GL 会自动进行同步。

同步对象的最简单用例是同时运行两个或多个渲染上下文。

在 OpenGL 中，您可以跨上下文共享某些资源（包括同步对象），但每个上下文的命令流是完全独立的，并且不会强制执行任何类型的同步。因此，如果要将数据上传到一个上下文中的顶点缓冲区并在另一个上下文中使用它，则需要在生产者（上传上下文）中插入栅栏同步，并等待它在使用者（绘制上下文）中发出信号。这将确保在上传完成之前不会发生 draw 命令 - 如果命令都是从同一上下文发出的，GL 实际上可以在不使用同步对象的情况下保证这一点。

我刚刚给出的示例不需要 CPU-GPU 同步（仅 GPU-GPU），但如果遇到 CPU-GPU 有意义的情况，您可以使用glClientWaitSync (...)来阻止调用线程，直到上传完成。

下面是一些用于评估同步对象有效性的伪代码：

线程 1：

glBindBuffer    (GL_ARRAY_BUFFER, vbo);
glBufferSubData (GL_ARRAY_BUFFER, 0, 4096*4096, foo); // Upload a 16 MiB buffer
GLsync ready =
   glFenceSync  (GL_SYNC_GPU_COMMANDS_COMPLETE​, 0);

线程 0：

glBindBuffer (GL_ARRAY_BUFFER, vbo);
// Try with and without synchronization
if (sync) {
  // Wait up to 1 second for the upload to finish
  glClientWaitSync (ready, GL_SYNC_FLUSH_COMMANDS_BIT, 1000000000UL);
}
// Ordinarily mapping a buffer would wait for everything else to finish,
//   we need to eliminate that behavior (GL_MAP_UNSYNCHRONIZED_BIT) for this test.
void* bar = 
  glMapBufferRange (GL_ARRAY_BUFFER, 0, 4096*4096, GL_MAP_UNSYNCHRONIZED_BIT​);
// When `sync` is true and the sync object is working, bar should be identical to foo
相关文章：