好的，我的实际问题是：
当我开始一个自写的简单OpenGL应用程序时，我的粉丝都快疯了。首先，我认为我的图形卡对于这样的东西来说太糟糕了。但是当我注意到我的笔记本电脑的硬件更差时，它运行该程序没有任何问题，我开始怀疑。所以我现在在两台不同的笔记本电脑上运行我的程序。其中一个是带有板载显卡的 intelcore I7 的 Fedora 笔记本电脑，另一个是带有板载显卡的 intelcore I5 的 Debian。出乎我的意料，我的软呢帽迷完全疯了，所以我开始做一些研究来找出问题所在。我阅读了有关GLX渲染和direct renderinglinux 的信息。所以我接下来要做的是检查输出
glxinfo |grep render
输出告诉我direct rendering在两台机器上都启用了。唯一的区别是OpenGL renderer string.
在我的 debian 上，它包含类似
mesa dri
或类似的东西。在我的软呢帽上它说
Gallium 0.4 on llvmpipe (LLVM 3.5, 256 bits)
顺便说一句……他们都在运行 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 结果在两台机器上看起来都一样。但我真的很想知道如何解决这个问题。