我正在考虑开始学习OpenGL（当然是核心配置文件），直到我阅读了一本书的预览，在那里我找到了附图。
当我第一次看到这个时，我有点震惊。一开始我的课程不会是庞大而复杂的，但随着时间的推移，他们会这样做。现在我正在考虑学习Vulkan（我发现了一本非常易于理解的书）或者切换到DirectX 11或者12（我在windows下编程）。
这里有一些问题：这里有没有人用OpenGL编写的程序如此广泛和复杂，以至于在某些时候它们在时间和精力方面已不再可行？
与DirectX一样，随着程序规模的增加，所需的时间会增加，在某些时候不再可行吗？
关于附加图形，游戏是用DirectX而不是OpenGL编写的原因是什么？
作为制作游戏引擎的人，我可以告诉你现代的openGL是一个绝对可以运行游戏的强大工具。它不是一个玩具，可以驱使你基本上三A级。 Windows游戏使用DirectX的原因是因为DirectX是微软制造的windows的图形API。
当您创建游戏引擎时，渲染API不是您将要处理的东西。
你大部分时间都会把它包装成你的东西，所以打电话给OpenGL并不是你要做的那么多。事实上，您可能希望实现DirectX渲染和OpenGL渲染以及Vulkan渲染以便为用户提供选择，您只需实现它并在引擎核心的某处忘记它。
从三者中选择哪一个，无论您的项目规模如何，都可以完成工作。有些可能会针对您的系统进行更优化，并为您提供更好的整体性能。 OpenGL不会限制你。我建议从openGL和cpp开始。你可以用它完成真正的工作并且是跨平台的（忘记了mac）。如果您只关心Windows而不是应该使用DirectX，那么Windows和Xbox的API将会很愉快。
我没有你所指的那本书，但我会说这个图表通常是正确的，只要：
二分法不是Vulkan与其他一切。它是即时API（OpenGL / D3D11）与命令缓冲API（Vulkan / D3D12）。使即时API难以处理的事情不是你的程序所做的事情;这是你的程序与GPU交互的方式。
直接API隐藏了抽象背后的内存管理的许多方面。因此，如果您需要使用内存执行非常具体的操作（您只需要在涉及大型复杂场景的高性能方案中执行此操作），那么这些API往往会妨碍您。
命令缓冲区API倾向于暴露更多内存管理的低级细节。它们直接向您呈现原始内存块与该内存的特定用途（缓冲区和纹理）之间的二分法。它们公开了特定的内存池以及分配实现支持的内存的方法，它们强迫您询问哪些内存对象可以进入哪些池。等等。
但是你可以更好地控制正在发生的事情。如果您正在做一些需要控制的事情，那么这种控制才真正重要。
如果你正在制作像Civilization IV这样的高度复杂的程序......你实际上通常不关心这种控制。为什么？因为CivIV的复杂性与它的渲染系统无关;它的复杂性在于实际的游戏玩法，人工智能等等。当然，命令缓冲区API可能仍然有助于提高性能，但渲染性能不太可能成为瓶颈。
有没有人在这里用OpenGL编写的程序如此广泛和复杂，以至于在某些时候它们在时间和精力方面已不再可行？
这是对图表的错误解释。
“不可能做”的领域本质上意味着你可以获得更好的渲染性能，但OpenGL / D3D11不允许你访问它。也就是说，无论您如何优化代码，对获得的速度都有一个严格的限制。
该域主要是因为即时API没有有效的线程渲染方式。他们所有的渲染内容都必须在同一个线程上发生。这意味着您的渲染性能将受到CPU的时钟速度和指令吞吐量（以及缓存架构和其他一些东西）的速度的限制。
因此，如果您的场景足够复杂，无法完全饱和CPU的单个线程，那么立即API可以做的更多事情可以使您的场景渲染速度更快。有一些优化可以提高吞吐量，但是一旦你使用了所有这些......你就没有技巧了。
命令缓冲区API专为线程呈现而设计。单个线程提交命令，但可以在任何线程上生成命令。这使得理论上可以在命令缓冲区API中实现更高的命令吞吐量，这是直接API所允许的。