问题标签 [glx]

我正在尝试从静态编译的二进制文件中剥离一些 GLX 窗口/上下文创建代码并放入共享库中。glX在第一次调用任何带前缀的函数时，在静态版本中运行良好的相同代码在共享库版本中崩溃。作为一个最小（非）工作示例，这里是 miniglx.cpp：

当我编译为可执行文件时

并运行，它按预期./miniglx打印。glX version 1.4

但是，当我编译为共享库时

并尝试dlopen在另一个程序中调用 print_glx_version它，它崩溃了。运行中gdb显示崩溃发生在调用glXQueryVersion并打印消息

共享库编译和链接很好，并ldd显示它似乎链接到libGL.soand libX11.so：

两种情况（静态与动态）之间的一个可能区别是，在静态库的情况下，我没有dlopen在主线程上运行库（我无法控制这一点）。在其他线程上做 glX 窗口/上下文管理有什么问题吗？

我在带有NVIDIA Corporation GT200GL [Quadro FX 5800] (rev a1)GPU 的 Ubuntu 14.04 LTS 上。mesa 和 nvidia 图形驱动程序都存在这种行为。glxinfo | head返回

在尝试运行[executable]我在 Linux 下编写并尝试在 OSX 上的 XQuartz 下测试的程序时，我得到：

我能找到的唯一先例是this，但没有解决。我的程序使用此处设置的 GLEW 。显然，glXChooseVisual没有被发现，但我希望它在libX11, 所以 . . . 什么地方出了错？

我打电话glGetString(GL_VERSION)来获取我请求的上下文支持的 OpenGL 版本（我尝试请求 GL 2 和 GL 3 上下文、核心和兼容性）。但是，它不断返回 null。这应该适用于所有类型的上下文（参见例如GL 4 文档）。它在 Windows 上也可以正常工作。

在我发现的类似问题（例如foo、bar、baz、qux）中，问题普遍不在于首先设置 GL 上下文。为了确保我这样做，我记录了每个相关的 glX 调用以产生以下输出：

第 1 项是glXCreateContext。该上下文在虚拟窗口（第 2 项）上设置为当前 ( glXMakeCurrent)。第 3 项是使用该上下文创建一个带有glXCreateContextAttribsARB¹的上下文。第 4 项取消设置基本上下文（不必要）（glXMakeCurrent再次）。第 5 项是在窗口上设置属性上下文（glXMakeCurrent再次）。

在此之后立即glGetString调用并返回 null。根据文档，这意味着发生了错误。glGetError但是，检查 with不会产生错误。如果我没有得到字符串而只是继续绘图，那么一切都很好，表明属性上下文确实设置正确且合法。

我能想到的唯一因素可能会影响这一点：

1. Linux 在 VirtualBox VM 中运行。我还没有测试过真正的发行版，但现在会这样做。
2. 设置上下文的窗口是一个不显示的虚拟窗口。然而，它与/映射/取消映射，XMapWindowXUnmapWindow以便 X 服务器知道它。

问题：发生了什么事？

_{^{1这种间接创建一个虚拟上下文首先加载属性上下文扩展功能在 Windows 上是必要的。为简化代码，我在 Linux 上执行相同的过程。}}

我决定为 X 编写自己的窗口包装器类型的东西。我使用 opengl.org 中的示例来创建 OpenGL 3.0 上下文作为起点，我的一些代码是从那里纯粹复制粘贴. 我已经按原样尝试了这个示例并且它有效，但我真的不知道我在这里做错了什么。本质上发生的是这样的：

我连接到默认显示。

我初始化了一个 XVisualInfo 指针以用于创建窗口。

我使用帧缓冲区配置初始化 GLXContext 变量，该变量在调用 glXGetVisualFromConfig() 时返回所述视觉对象

我使用上述视觉效果和一些属性创建了一个窗口。

我调用 glXMakeCurrent() 并且它抛出一个 BadMatch（无效的参数属性）或者我使用我自己的错误处理程序，它说这是一个段错误。

我尝试跳过 glxMakeCurrent()，但它在 glXSwapBuffers() 上抛出相同的错误

确切的错误如下：

我在这里完全没有想法。据此， glXSwapBuffers 不应该抛出 BadMatch。

这是我的代码：

我正在尝试在树莓派（树莓派操作系统）上编译和运行一个简单的 SFML 代码。它确实编译没有任何错误。当我运行它时，出现以下错误。

我正在使用 SFML 1.6 版（sudo apt-get install libsfml-dev）

这是我的代码：

After creating a display, I make a window with XCreateWindow. Then, as described here, I call XMapWindow and then immediately XUnmapWindow; this lets the X server know about the window so that commands (e.g. XMoveWindow) don't silently fail.

The window is invisible at this point, as it should be. I can stop execution with e.g. getchar. Definitely invisible.

Then I call glXCreateContext, and the window appears, just as if I had called XMapWindow again! Sorcery! I have stopped execution immediately before and immediately after, so I know it's glXCreateContext.

This makes no sense. I skimmed the documentation, but there's really no way this could possibly happen. Any guesses?

EDIT: Here's a simple example:

Also demonstrates the failure of either XCreateWindow or XMoveWindow to set the window position before map/unmap.

我正在尝试使用 glX 函数 ( glXSwapIntervalMESA())，但编译器返回未定义的引用错误。

我试过用X11andXext和链接glx，虽然最后一个库显然不存在。libGL包括一些glx 的入口点，但我猜其他的（例如我正在尝试使用的）是平台相关的*。

我找不到任何地方，但它会告诉我如何找到这些平台相关库的名称。对于给定的系统，如何确定链接器设置以使用 glx？

（*我会猜到这是因为我看到了带有奇怪库名称的示例链接器设置。）

好的，我的实际问题是：

当我开始一个自写的简单OpenGL应用程序时，我的粉丝都快疯了。首先，我认为我的图形卡对于这样的东西来说太糟糕了。但是当我注意到我的笔记本电脑的硬件更差时，它运行该程序没有任何问题，我开始怀疑。所以我现在在两台不同的笔记本电脑上运行我的程序。其中一个是带有板载显卡的 intelcore I7 的 Fedora 笔记本电脑，另一个是带有板载显卡的 intelcore I5 的 Debian。出乎我的意料，我的软呢帽迷完全疯了，所以我开始做一些研究来找出问题所在。我阅读了有关GLX渲染和direct renderinglinux 的信息。所以我接下来要做的是检查输出

输出告诉我direct rendering在两台机器上都启用了。唯一的区别是OpenGL renderer string.

在我的 debian 上，它包含类似

或类似的东西。在我的软呢帽上它说

顺便说一句……他们都在运行 KDE。

好的，然后我检查了/dev文件系统。在我的 debian 上，正如我所期望的dri/card0那样，/dev文件系统中有一个设备文件，当然在我的 fedora 上它丢失了。

我还查看了 lsmod... 模块drm及其辅助模块都加载在两台机器上。两台机器的显卡都使用 i915 模块。

我的第一个想法是fedora 不使用直接渲染，因为没有'card0'。我使用 linux 工具strace来找出实际发生的情况。我得到的结果并不令人惊讶 Debian 加载drm library和其他一些东西。然后它检查是否有/dev/dri/card0使用stat系统调用。然后它打开它。并开始使用大量ioctl命令。这就是dri机制应该如何工作的方式。

因此，fedora 上的“strace”带来了以下结果。

它也打开了drm library。但它不检查是否有/dev/dri/card0它开始生成futex调用输出负载。我用谷歌搜索了它，futex 调用似乎提供了监视特定 RAM 地址或多个 RAM 地址变化的功能。所以我的fedora不想使用这个dri机制肯定是有原因的。

PS 结果在两台机器上看起来都一样。但我真的很想知道如何解决这个问题。

我正在尝试让 GTK+ 3.16 的新 GLArea 小部件工作。它旨在提供内置的 OpenGL 支持，而不依赖于过时的 GtkGLExt/GtkGLArea 项目。由于我还不愿意将我的工作发行版更新到 Gnome 3.16，所以我使用 Gnome Boxes 在虚拟机上安装了 Fedora 22 Alpha。

在ebassi 的博客文章之后，我在我的窗口 UI 文件中添加了一个 GLArea 子项：

并连接信号。我应该说我正在使用 Vala 作为我的 UI 代码。实际的 OpenGL 代码旨在进入我将从gl_drawVala 方法调用的 C 函数。目前，三个 Vala 函数只打印它们的名称。

确实，gl_init并被gl_fini调用。但 GLArea 小部件显示此错误消息：

创建核心配置文件所需的 GLX_ARB_create_context_profile 扩展不可用

我还尝试运行 ebassi 自己的示例程序（GitHub）。它甚至不显示 UI，而是输出

glarea：找不到当前的 GLX 或 EGL 上下文。

马上在终端上。

但是，运行glxinfo告诉我我安装了该扩展：

glxgears也运行没有问题。

此外，我在 Github 中克隆了GNOME/gtkglarea 存储库，自己编译并运行示例，没有任何问题。我知道这个项目在正式包含在 GTK 之前开发了 GLArea 小部件？（我错了。）

我在使用 expo 插件绘制桌面时检查了 Compiz 的性能。Compiz 和 nvidia-settings 中的 VSync 已启用。我这样测量时间：

当绘制命令需要 8 毫秒时，同步/交换时间大约等于 7 毫秒，因为当 vsync 开启时，在 glXSwapBuffers 之后使用 glFinish 应该会阻塞。当我在 expo 模式下运行更多 opengl 窗口时，paint 命令需要 18 毫秒，同步/交换时间约为 13 毫秒。怎么解释？为什么 glXSwapBuffers 这么慢？

此外，当我在 nvidia-settings 和 Compiz 中关闭 vsync 并生成需要 28 毫秒的绘图命令时，同步/交换时间约为 14 毫秒。