我热衷于为基于 *nix 的系统编写“模拟 GPU 驱动程序”。我的意思是，我只是想编写一个驱动程序（显然是在 X 服务器后面）来用一些调试消息来应答 X 的 API 调用。
换句话说，我想欺骗 *nix 系统拥有实际的 GPU。因此，我可以在基于控制台的系统中为 GUI 加速包创建一个测试平台。
现在，如果我在 *nix 基于控制台的系统中执行 GUI 加速包；它会因为缺乏真正的 GPU（或者我认为更好的 GPU 驱动程序）而死掉。
所以我想知道：
- 有可能吗？ （编写 GPU 驱动程序来欺骗 *nix 拥有实际的 GPU）
- 在我开始编写代码之前，您推荐哪些资源？
- 网上有类似的项目吗？
PS：我是一名经验丰富的 ANSI-C 程序员，但我对 *nix 下真正的内核/驱动程序开发没有任何线索（不过请阅读一些有关 USB 驱动程序开发的教程），因此有关这些领域的任何资源将非常感激出色地。提前致谢。
答案1
鉴于您的要求，在我看来您可能不需要编写自己的驱动程序。您也许可以使用LLVM管道，我相信符合您的要求。特别是，它是一个“真正的司机”一些该词的含义，并且不需要 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”实现。）