c++ - 多线程环境中的 XSetWMProtocols 和 glXCreateContext 调用顺序

Question

编辑:我在下面发布了一个很好的解决整个渲染器分离问题的方法。

我最近在多线程 X11 环境中使用 OpenGL。我发现以下 tutorial ，编译、链接和运行良好。

然后我在尝试根据自己的需要调整代码后遇到了一个奇怪的问题。

教程中XCreateWindow、glXCreateContext、XSelectInput、XSetWMProtocols的调用顺序如下:

param[i].win = XCreateWindow(param[i].d_, root, 200,200, 
                   300,200, 0, visInfo->depth, InputOutput, visInfo->visual,
                   CWColormap,
                   &windowAttr);
param[i].ctx = glXCreateContext(param[i].d_, visInfo,  NULL, True);
XSelectInput(d, param[i].win, StructureNotifyMask);
XSetWMProtocols(d, param[i].win, &(delMsg), 1);

请注意，XCreateWindow 和 XSelectInput/XSetWMProtocols 使用不同的显示连接。

但是，当更改调用顺序时

param[i].win = XCreateWindow(param[i].d_, root, 200,200, 
                   300,200, 0, visInfo->depth, InputOutput, visInfo->visual,
                   CWColormap,
                   &windowAttr);
XSelectInput(d, param[i].win, StructureNotifyMask);
XSetWMProtocols(d, param[i].win, &(delMsg), 1);
param[i].ctx = glXCreateContext(param[i].d_, visInfo,  NULL, True);

程序失败

X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0x5000002 Serial number of failed request: 17 Current serial number in output stream: 18

这似乎是由 XSetWMProtocols 引起的。

由于使用了不同的显示连接，如果整个事情一开始就不起作用，我也不会感到惊讶。但不知何故，在调用 glXCreateContext 之后，一切似乎都神奇地好起来了。

我是 X11/GLX 编程的新手，我错过了什么吗？ glXCreateContext 有什么魔力？还是发生了其他事情？或者我应该继续前进，因为 OpenGL 和多线程似乎总是会导致问题。

我的解决方案:

我很懒，只是使用教程中的方法。这一直有效，直到将 freetype 添加到我的项目中，这突然让我再次崩溃。因此，即使一切看起来都很好，当您在不同的线程中工作时，X11 会在您不在的时候严重占用一些内存。 (不是我干的，我用valgrind查了一下)

我目前的解决方案是 n.m.评论:我将所有内容放入 GUI 线程(X11 和 GL/GLX 调用)，其他线程永远无法使用其资源。但是，必须牢记两点，因为它可能会减慢您的渲染循环:

• 缓慢的消息处理会延迟呈现(如下 ilmale 所述)
• 缓慢的呈现会延迟消息处理(我的担忧)

第一个问题很容易解决。创建一个 STL 双端队列或列表或任何容器，您可以在其中为您的应用程序逻辑排队相关的 XEvent，然后从另一个线程中获取它们。只需确保您的 STL 是线程安全的并且有疑问实现您自己的队列。通过在容器大小上设置等待条件，您甚至可以模拟像 XNextEvent 这样的阻塞调用。

第二个问题很棘手。您可能会争辩说，如果渲染器的速度为 1 fps 或更慢，那么游戏或应用程序无论如何都是无用的。那是真实的。但是，如果您能够处理一些终止信号(例如销毁窗口原子)，即使您处于 0.1 fps，那也很好。我能想到的唯一解决方案是在渲染每千个 Sprite 后检查新消息。将它们发送到您的容器并继续渲染。当然，那样的话你永远不能让渲染线程随时运行用户脚本或其他未知代码。但我想，无论如何，这会使将渲染与其他线程分开的想法变得毫无意义。

希望这对您有所帮助。

:

Answer 1

我在跨平台项目中基本上经历了多线程 X11 和 Win32 的相同尝试。

我注意到的一件事是 X11 并没有像上面的帖子所指出的那样修改内存。当然，各种命令的顺序有些奇怪，但一旦正确处理，它似乎就相当稳定了。

特别是 几乎 让我认输的一项是后台 GPU 处理!这种非常奇怪且难以捕获的运行时竞争条件让我认为应该归咎于操作系统。

在将纹理发送到显示列表内的卡片后(咳咳，在实现 freetype 时也是如此)，立即绘制资源有时会导致字体显示列表轻微损坏，即使是在以后的绘制中也是如此。显示列表本身已损坏，我什至求助于实现全局 OpenGL 锁只是为了证明线程不是罪魁祸首。但是为什么它会损坏？操作系统？不，GPU。

我相信共享的 GLX 上下文会在某些卡上强制执行不同的行为，尤其是我系统上的 nvidia。不是其他线程导致了我的问题，而是 createContext 调用上的共享标志加上在使用资源之前缺少 glFinish()。这和我将在下面解释的一些最佳实践。

在 99% 的运行中，没有 glFinish() 即使使用多线程也能正常工作。只有在加载时才会出现这种情况，因此不断停止/重新启动应用程序最终会暴露它。如果它加载所有内容都没有问题，应用程序将从此运行良好。如果出现问题，在我重新加载图像之前图像会一直损坏。

通过遵守这些简单的规则，所有问题都得到了解决。

1. 在非 main() 线程中创建第二个 GLContext。 (不要在同一个线程中创建两个上下文并为第二个线程提供指针，那样不稳定)
2. 在第二个线程中加载资源时，添加 glFinish() prior 以将结果放入要使用的队列中。 (简单的说，glFinish()在使用资源之前)
3. 在第二个线程中的第二个上下文中调用 makeCurrent() 后，调用 getCurrentContext() 函数并等待它为非 NULL，然后让任一线程执行其他 OpenGL 资源加载或电话。有时在第二个线程上，它 (makeCurrent) 返回，但 getCurrentContext() 在某些视频卡上可能仍为 NULL 一段时间。不确定驱动程序为什么或如何让这种情况发生，但检查可以避免应用程序崩溃。

我在我的 6-Thread+ 应用程序中实现了这些做法，奇怪的一次性损坏问题消失了，再也没有出现。

事实证明，根据我的经验，X11 并不是那么刻薄……视频卡是，但它真的比任何东西都更挑剔。在我的例子中，我什至使用 typedef 来使用非特定函数编写 Linux/Windows 代码，这使事情变得更加复杂，但如果采取适当的预防措施，这仍然是一个可管理的野兽:)。

如果您问我，这很古怪，但不是“不惜一切代价避免”的问题。我希望这篇文章有所帮助，祝你好运!