OpenGL和Vulkan的复杂性

我一直在考虑开始学习OpenGL（当然是核心配置文件），直到我读了一本书的预览，在那里我找到了附加的图形

当我第一次看到这个的时候，我有点震惊。开始时，我的程序不会太庞大和复杂，但随着时间的推移，它们会越来越复杂。现在我正在考虑学习Vulkan（我发现了一本非常容易理解的书）或切换到DirectX 11或12（我在windows下编程）

下面是一些问题： 这里有没有人曾经用OpenGL编写过如此广泛和复杂的程序，以至于在某些时候它们在时间和精力上不再可行

与DirectX相同的是，随着程序大小的增加，所需的时间会增加，并且在某些情况下不再可行吗

---

关于附带的图形，这就是为什么游戏用DirectX而不是OpenGL编写的原因吗？

作为一个制作游戏引擎的人，我可以告诉你，现代OpenGL是一个功能强大的工具，它绝对可以运行游戏。它不是玩具，基本上可以让你达到AAA水平。windows游戏之所以使用DirectX，是因为DirectX是microsoft为windows制作的图形API

创建游戏引擎时，渲染API并不是您一直要处理的事情

您通常会将其封装在您的on工具中，因此调用OpenGL并不是您要做的事情。事实上，您可能希望同时实现DirectX渲染、OpenGL渲染和Vulkan渲染，以便给用户一个选择，您只需实现它，然后将其忘在引擎核心的某个地方

不管你的项目有多大规模，你都可以从三个项目中选择哪一个来完成这项工作。有些可能更适合您的系统，并为您提供更好的整体性能。OpenGL不会限制你。

---

我建议从openGL和cpp开始。你可以用它完成真正的工作，并且可以跨平台（忘掉mac）。如果你只关心windows，而不应该使用DirectX，那么这是windows和Xbox的API，你会玩得很开心。

我没有你所指的书，但我想说，只要：

将“以前的图形API”替换为“OpenGL和Direct3D pre-12”

将“Vulkan”替换为“Vulkan和Direct3D 12”

您将“努力和时间消耗”替换为“优化所需的努力”

将“程序复杂性和大小”替换为“渲染场景复杂性和大小”

这种二分法不是Vulkan与其他任何事物的对立。它是即时API（OpenGL/D3D11）和命令缓冲区API（Vulkan/D3D12）。使即时API难以使用的不是您的程序所做的事情；这就是你的程序如何与GPU交互

即时API将内存管理的许多方面隐藏在抽象背后。因此，如果您需要使用内存执行非常特定的操作（仅在涉及大型复杂场景的高性能场景中需要这样做），那么这些API往往会妨碍您

命令缓冲区API倾向于公开更多内存管理的低级细节。它们直接向您展示了原始内存块和该内存的特定用途（缓冲区和纹理）之间的二分法。它们公开了特定的内存池以及实现支持的分配内存的方法，并迫使您询问哪些类型的内存对象可以进入哪些池。等等

但是你对发生的事情有了更多的控制权。只有当你在做需要控制的事情时，这种控制才真正重要

如果你正在制作一个非常复杂的程序，比如《文明四号》。。。实际上，你通常不关心这个控制。为什么？因为CivIV的复杂性与它的渲染系统无关；它的复杂性在于实际的游戏性、人工智能等等。当然，命令缓冲区API可能仍有助于提高性能，但渲染性能不太可能成为瓶颈

这里有没有人曾经用OpenGL编写过如此广泛和复杂的程序，以至于在某些时候它们在时间和精力上不再可行

这是对图表的错误解释

“不可能做到”的领域本质上意味着您可以获得更好的渲染性能，但OpenGL/D3D11不允许您访问它。也就是说，无论你如何优化你的代码，你的速度都有一个严格的限制

该领域主要是关于即时API没有有效的线程呈现方法这一事实。他们所有的渲染工作都必须在同一个线程上进行。这意味着您的渲染性能将受到CPU时钟速度和指令吞吐量（以及缓存体系结构和其他一些东西）的限制

因此，如果您的场景足够复杂，足以使CPU的一个线程完全饱和，那么立即API就无法使场景渲染更快。有一些优化可以提高吞吐量，但是一旦您使用了所有这些。。。你没有把戏了

命令缓冲区API是为线程渲染而设计的。单个线程提交命令，但可以在任何线程上生成命令。这使得理论上可以在命令缓冲区API中实现即时API所允许的更高的命令吞吐量