Linux-图形驱动程序与Mesa之间的关系

当我安装nvidia专有驱动程序时，使用nvidia OpenGL实现（我不需要Mesa）。哪种OpenGL实现可以与开源nvidia驱动程序-Nouveau一起使用？Nouveau是否也提供OpenGL实现，还是必须使用Mesa OpenGL实现？我可以在Mesa OpenGL实现中使用nvidia驱动程序吗？有哪些可能性？

第一件事：开源图形驱动程序都使用Mesa作为前端OpenGL界面和状态跟踪

让我们来分析一下：理论上，OpenGL实现可以直接与硬件对话。这就是英伟达和AMD专有驱动程序所做的。

但是在开源世界，代码重用是非常受欢迎的。因此，典型的开源图形驱动程序如下所示：

用户API前端（OpenGL+状态跟踪器）→ 抽象层（Gallum3D或特定于设备的内部层）→ 内核后端

Mesa项目实际上包含了整个链。Mesa的OpenGL部分（前端）可以连接到不同的抽象层（例如，软件光栅化器、软件管道/llvm）。但Mesa项目也是其他部分的保护伞：userland图形驱动程序（nouveau、radeon、intel等），允许用户空间进程直接与图形驱动程序对话的基础设施，绕过显示服务器（DRI）和内核接口（DRM），以及内核模块

几周前，AMD发布了一个新的内核模块（amdgpu），它使用DRMAPI，是开源的，将被合并到Linux内核中。这个新的内核模块将被专有的AMD OpenGL驱动程序和开源的Mesa驱动程序使用。AMD正在推动开源一段时间，合乎逻辑的下一步是，AMD放弃自己的OpenGL前端，转而支持Mesa，并提供其专有的驱动程序作为插入Mesa的中间端

---

我可以在Mesa OpenGL实现中使用nvidia驱动程序吗

那要看情况。如果你在X11上做了间接OpenGL，那么实际上你可以使用Masa LIGBL。所以，对于你的程序，通过X11服务器到英伟达后端驱动程序进行对话。然而，以这种方式使用libGL.so仅充当GLX管道。顺便说一句，它也可以反过来工作

然而，由于缺乏“直接GL上下文”功能，您将无法使用未定义间接操作码的OpenGL功能；遗憾的是，这将是OpenGL-3或更高版本的任何东西。此外，如果您的数据是高度动态的，那么由于序列化命令流（理论上使用vmplice之类的系统调用，大多数开销都可以减轻），会出现一些严重的瓶颈