sep*_*hrl 5 linux drivers kernel x11
我正在为基于 *nix 的系统编写“模拟 GPU 驱动程序”。我的意思是，我只想编写一个驱动程序（显然在 X-server 后面）来用一些调试消息来回答 X 的 API 调用。
换句话说，我想欺骗 *nix 系统拥有一个实际的 GPU。所以我可以在基于控制台的系统中为 GUI 加速包做一个试验台。
现在，如果我在基于 *nix 控制台的系统中执行 GUI 加速包；由于缺乏真正的 GPU（或者我想说的更好的 GPU 驱动程序），它只会死掉。
所以我想知道：
PS：我是一位经验丰富的 ANSI-C 程序员，但我对 *nix 下真正的内核/驱动程序开发一无所知（尽管阅读了一些有关 USB 驱动程序开发的教程），因此将非常感谢有关这些领域的任何资源好。提前致谢。
鉴于您的要求，在我看来您可能不需要编写自己的驱动程序。您可以使用llvmpipe，我相信它符合您的要求。特别是，从某种意义上说，它是一个“真正的驱动程序” ，它不需要运行 X11。
llvmpipe 创建了可能被称为虚拟 GPU 的东西，它通过将 OpenGL 着色器即时转换为 CPU 的机器语言并运行它来解释它们。它使用部分LLVM基础架构来实现这一点。
但是，它可能无法满足您的需求，因为实际发生的是 llvmpipe 是由调用它的二进制文件链接的。换句话说，这不是一个真正的、实时的、在内核中运行的驱动程序。相反，它创建了一个替代方案libGL.so来解释您的 OpenGL 着色器。
如果您无法从源代码编译 3D 图形加速程序，则可能无法使用 llvmpipe 达到良好效果。（但您希望这有助于调试您自己的程序，所以这应该不是问题。）
您可能想在问题中提供有关您需要的更多信息。特别是：为什么你需要从驱动程序端调试你的代码? 为什么不能将必要的调试代码放在程序本身（或程序本身）中？当调用失败时，X 库和 OpenGL 库都提供了有关出错的信息。为什么不能在程序中使用这些信息——加上内核消息——来促进调试？为什么您会期望您在驱动程序端获得的调试信息（在内核中实现虚拟驱动程序）与真实计算机上实际发生的情况相对应？更重要的是，为什么您会假设如果您的程序产生低级问题，那么当它在现实世界中运行时，这些问题对于不同的 GPU 和驱动程序是相同的？你可能对这些问题有很好的答案（而且我可能遗漏了一些东西），但是如果您对此进行了解释，我认为回答您的问题会更容易。
（顺便说一句，llvmpipe 的一个有趣的应用是使图形用户界面只能在 3D 加速版本中编写，但仍然可以在没有 3D 加速的计算机上运行。理论上这应该有助于运行没有 3D 加速的 GNOME Shell，尽管一些开发工作可能需要使其实际工作；我认为 GNOME Shell 做出了一些与合成相关的假设，这些假设可能不会自动实现。此外，显然存在一些性能问题。实际工作的真实世界实例是 Unity，其中Ubuntu 12.10将只有一个版本，并且能够在 llvmpipe 之上运行，而不是有一个单独的“Unity 2D”实现。）