我真的需要使用图形API吗？

是否需要使用图形API来在3D游戏中获得硬件加速？在何种程度上可以摆脱对图形卡API（如OpenGL，DirectX ，CUDA，OpenCL或其他任何东西）的依赖？

我可以为自己的游戏制作自己的图形API或库吗？即使很难，从理论上讲，我的3D应用程序是否有可能独立联系图形驱动程序并在GPU上渲染所有内容？

我认为许多答案都遗漏了一个重要点：您可以编写可直接访问硬件的应用程序，但不能在现代操作系统上使用。这不仅是时间问题，而且是“您别无选择”的问题。

Windows，Linux，OSX等均禁止直接硬件访问任意应用程序。出于安全原因，这很重要：出于不希望任何随机应用程序能够读取系统内存的相同原因，您不希望任何随机应用程序能够读取任意GPU内存。诸如银行帐户的帧缓冲区之类的东西或GPU内存中没有的东西。您希望这些东西被隔离和保护，并由您的操作系统控制访问。

只有驱动程序可以直接与大多数硬件对话，而与驱动程序对话的唯一方法是通过操作系统的公开HAL和每个驱动程序的专有且不兼容的接口。该驱动程序接口不仅对于每个供应商都是不同的，甚至在驱动程序本身的版本之间也将有所不同，从而几乎不可能直接与消费者应用程序中的接口进行通信。这些层通常由访问控制覆盖，这些访问控制进一步限制了应用程序访问它们的能力。

因此，不，您的游戏不能直接使用硬件，除非您当然只针对不安全的操作系统（例如DOS），并且在现代消费者操作系统上游戏的唯一可行选择是针对公共API（例如DirectX，OpenGL或Vulkan。

实际上，这是必须的，是的。这是必要的，因为除非您想花费数年时间编写用于各种不同硬件配置的基本驱动程序代码，否则您需要使用一个API，该API与GPU厂商为所有流行的操作系统和硬件编写的现有驱动程序统一。

唯一现实的选择是，您不使用3D加速，而是进行软件渲染，只要它是用C等真正可移植的语言编写的，就可以在几乎所有系统/设备上运行。这对于较小的游戏来说是很好的……像SDL这样的东西适合于此目的……还有其他一些东西。但这缺乏固有的3D功能，因此您必须自己构建它们……这不是一件容易的事。

还请记住，与GPU相比，CPU渲染效率低下并且性能不佳。

像OpenGL或DirectX这样的API部分由操作系统实现，部分由图形驱动程序本身实现。

这意味着当您想创建自己的使用现代GPU功能的低级API时，您实际上需要编写自己的图形驱动程序。确保您的驱动程序可以与所有常见的图形卡一起使用将是一个很大的挑战，特别是因为供应商通常对其规格并不十分开放。

将您的PC引导到MS-DOS。然后，使用PC游戏程序员百科全书的副本，您可以直接写入卡的VESA寄存器和视频存储器。我仍然有20年前编写的代码，可以执行此操作，并在软件中渲染基本的3D。

另外，您也可以只使用DirectX。这是一个非常薄的抽象层，还可以让您直接写入视频缓冲区，然后将它们交换到屏幕上。

还有一种极端的方法来构建自己的视频硬件。

其他答案很好地回答了您的主要问题：从技术上讲，这是可能的，但实际上，如果您的目标是扩大客户群，那么您实际上是在做相反的事情。在浪费大量工作来支持您需要支持的数千种不同的硬件和操作系统配置时。

但是，这并不意味着您必须100％依赖一种特定的API。您始终可以编写自己的抽象层，然后再交换进出特定的实现（例如DirectX实现，OpenGL实现等）。

即使那样，这也不值得。只需选择适合您目的的足够好的东西，然后完成即可。您是独立游戏开发商-您需要专注于创造游戏的事物，而不是游戏细节。制作游戏！

总结：从理论上讲您可以，但是这是不可行的，您将不会获得任何好处。今天，API的限制每天都在减少，您拥有CUDA，OpenCL和着色器。因此，完全控制不再是问题。

更充分的解释：

回答这是一个无聊的肯定。真正的问题是为什么？

我几乎无法想象，除了学习目的之外，您为什么还要这样做呢？您必须知道，在某个时候，开发人员可以使用其CPU渲染实现自由执行任何操作，每个人都有自己的API，他们可以控制“管道”中的所有内容。随着固定管线和GPU的引入，每个人都切换了。

使用GPU，您可以获得“更好”的性能，但失去了很多自由。图形开发人员正在努力恢复这种自由。因此，每天都有更多的定制管道。使用CUDA / OpenCL甚至着色器，几乎可以执行任何操作，而无需触摸驱动程序。

您想与硬件对话。您需要使用一种与硬件对话的方法。这样就是硬件的接口。那就是OpenGL，DirectX，CUDA，OpenCL等。

如果您处于较低级别，那么您只是在使用较低级别的界面，但仍在使用一种界面，只有这样一种界面不能与较高级别的卡片一起使用。

要在不使用传统API的情况下获得3D硬件加速，本质上您需要编写自己的代码来复制图形驱动程序的功能。因此，了解如何执行此操作的最佳方法是查看图形驱动程序的代码。

对于NVIDIA卡，您应该查看开源的nouveau项目。他们在这里拥有大量资源。

对于其他品牌的图形卡，您可以找到类似的项目和文档。

请注意，正如在其他答案中提到的那样，大多数现代操作系统都将阻止用户空间程序直接访问硬件，因此您将需要编写代码并将其作为操作系统驱动程序进行安装。或者，您可以使用没有这种限制的FreeDOS操作系统，并且应该（理论上）应允许您直接访问硬件，并允许您编写渲染3D硬件加速图形的常规程序。请注意，即使利用现有开放源代码图形驱动程序中的代码，这也将是大量的琐碎工作（据我所知，这从未完成过，并且由于各种原因，实际上可能并非如此）技术上可行）。

摆脱DirectX或OpenGl不会删除依赖关系，而是会引入更多依赖关系。其他答案已经包含了几个优点，为什么甚至不能直接与图形硬件对话（至少不可行），但是我的第一个答案是：如果您确实编写了一个抽象所有常见3d的库，将图形硬件集成到单个API中，您将有效地重写了DirectX / OpenGl。如果要使用代码编写游戏，则应该将新库添加为新的依赖项，就像现在将DirectX / OpenGl作为依赖项一样。

通过使用DirectX或OpenGl，您的依赖关系基本上是在说“此代码依赖于库来提供说明如何在不同图形卡上运行某些命令的代码”。如果没有这样的库，则会引入依赖项“此代码取决于图形硬件，其行为与构建游戏时存在的硬件完全相同。”

诸如OpenGl或DirectX之类的抽象允许硬件制造商提供自己的（驱动程序）代码，这些代码可导致通用代码库，因此游戏更有可能在编写游戏时甚至不存在的硬件上运行。

首先，CUDA和OpenCL都不是图形API。它们是计算API。

编写自己的图形API的问题在于它非常复杂。您可以直接与硬件交互，但是不能保证如果它在具有X CPU，X GPU，X数量的ram和X操作系统的系统上运行，那么它将在具有Y CPU，Y GPU等的系统上运行。优点之一是DirectX可与内核模式驱动程序一起使用。它植根于内核。此外，图形API并未构建为支持GPU。GPU（及其驱动程序）旨在支持它们。因此，除非您构建自己的操作系统并使用x86提供的VGA中断，否则您几乎无法构建图形API。但是您仍然无法与GPU正确连接，并且会陷入低分辨率状态。

我了解您想自己构建所有内容，而不要使用引擎或类似的东西。但是制作自己的图形API只会给用户带来不便。

您可以编写自己的驱动程序和API，但是没有什么可以阻止您的，只有您的能力和知识水平。如果没有别的东西，那将是一个很好的学习经验，那么真正的问题是，如果没有很多以前的图形经验，那么即使您是一个优秀的程序员，您也可能会茫然无措……甚至开始。

但是，与不断更新的东西相比，您自己创建的界面将更易于使用和稳定。因此，令我惊讶的是，更多的人没有走这条路，但是现实是，只有很少的人拥有技术敏锐性，没有人愿意多年付钱去学习如何做所有事情，然后可能他们离开公司，陷入困境。对他们来说，标准化的好处是，它使员工的工作更省钱，并且降低了风险。