C++ OpenGL客户端等待使用哪种：glGetSynciv与glClientWaitSync？

根据上的OpenGL规范，我不清楚是使用

glGetSynciv

还是

glClientWaitSync

，以便在不等待的情况下检查同步对象的信令。以下两个命令在行为和性能方面如何比较：

GLint syncStatus;
glGetSynciv(*sync, GL_SYNC_STATUS, sizeof(GLint), NULL, &syncStatus);
bool finished = syncStatus == GL_SIGNALED;

vs

问题的一些细节：

• glGetSynciv

  是否执行到总账服务器的往返
• 在驱动程序支持/缺陷方面，是否有任何方法是首选的
• 方法是否可以死锁或不立即返回

一些背景：

• 这适用于视频播放器，它将图像从物理源流式传输到GPU进行渲染
• 一个线程正在流式/连续上传纹理，另一个线程在完成上传后渲染纹理。我们正在检查每个渲染帧的下一个纹理是否已完成上载。如果有，则开始渲染此新纹理，否则继续使用旧纹理
• 这个决定只是客户端的，我根本不想等待，但要快速继续渲染正确的纹理

这两种方法都有人们为了不等待而使用它们的例子，但似乎没有人讨论使用其中一种方法的优点。

引用红皮书

无效glGetSynciv（GLsync sync、GLenum pname、GLsizei bufSize、GLsizei*长度、GLint*值）

检索同步对象的属性。sync从wich指定同步对象的句柄，以读取pname指定的属性。bufSize是以字节为单位的缓冲区大小，其地址以值为单位。lenght是一个整数变量的地址，该变量将接收写入值中的字节数

而对于

glClientWaitSync

：

GLenum glClientWaitSync（GLsync同步，GLbitfields标志，GLuint64超时）

使客户端等待同步对象发出信号。 glClientWaitSync（）在生成超时之前，将最多等待超时纳秒，以便对象发出信号。flags参数可用于控制命令的刷新行为。指定GL\u SYNC\u FLUSH\u命令\u位相当于在执行wait之前调用glFlush（）

因此，基本上glGetSynciv（）用于知道围栏对象是否已发出信号，而glClientWaitSync（）用于等待围栏对象发出信号

如果您只想知道围栏对象是否已发出信号，我建议使用glGetSynciv（）。 显然glClientWaitSync（）的执行时间应该比glGetSynciv（）长，但我猜。

---

希望我能帮到你。

很有趣，尽管我怀疑这两种用法之间会有多大区别。第一次测试似乎表明glGetSynciv需要0.01毫秒，glClientWaitSync需要0.001毫秒（在NVIDIA、YMMV上）。是的，但是计时数据缺少一些基本信息，例如你是如何测量的以及差异是什么。您不希望只测量前后的时间戳，因为它没有考虑函数可能对整个帧性能的影响（特别是在本例中涉及多线程性能时），您也不希望报告没有样本方差的时间，因为这可能是一个侥幸，要真正挑剔，请记住，如果没有

glWaitSync

——而不是

客户端

！——和对象的重新绑定，您可能看不到共享上下文中的更改。参考规范中的§5.3.1……不幸的是，我没有。到目前为止，关于这个主题的文章很少，但这是整个“接近零驱动开销”计划中的一个非常关键的概念。它实际上是第二层平铺资源，与D3D相当。我敢打赌D3D概念会有更多的内容，但它仍然是非常新的。重要的一点是，超时为0的glClientSyncWait与glGetSynciv（）相比如何。我的测试似乎表明，在NVIDIA上更快的是glClientWaitSync。这让我好奇glGetSynciv（）是否有更多的缺点。是的，我发现有趣的是，应该“等待”的函数实际上比只应该检索OpenGL状态的函数运行得更快。@MatthUnderpants如果指定了0的超时，它就不会等待。这就是问题的重点。我理解你的意思，但这是一个不好的文件化的东西，而且它总是依赖于实现。

bool finished = glClientWaitSync(*sync, 0 /*flags*/, 0 /*timeout*/) == ALREADY_SIGNALED;