例如，在整个 ARM Mali 系列中，许多 GPU 支持 OpenGL ES 3+、Direct3D 9+（有些支持高达 11/12），有些支持 Vulkan，但没有一个支持 OpenGL，甚至更新版本的不推荐使用固定管道的 OpenGL。与 Adreno 相同。
是硬件无法支持完整的 GL（如果是，为什么？），还是驱动程序开发人员没有实现它？
【问题讨论】：
标签： android opengl opengl-es gpu
因为 OpenGL ES 正是针对“嵌入式”硬件而创建的。
另一方面，将 OpenGL ES 创建为一个单独的标准，而不仅仅是 OpenGL 的“子集”（如果您愿意，今天我们将其称为“配置文件”）的想法非常、非常、非常，非常，非常，非常，非常，非常，非常糟糕的主意。
您在这里面临的主要含义是，为了实现除 OpenGL ES 之外的 OpenGL 支持，供应商需要开发另一个相似但略有不同的 GL 库。这意味着额外的开发工作、测试和认证。因此，对他们来说，将这项工作推给开发人员并要求他们创建不同的渲染器，针对桌面上的 OpenGL 和嵌入式上的 OpenGL ES，要容易得多。
（幸运的是，如果你有 OpenGL，GL_ARB_ESx_compatibility 扩展以某种方式“简化”了这个混乱，它允许你拥有一些 OpenGL ES 数据类型/调用/功能，所以你可以重用更多代码.)
除此之外，您是对的——如果硬件支持 Vulkan，那么它将支持 OpenGL 4.5 / DX12。粗略地说，这条线的每一条都针对不同的硬件一代：
加上一条看起来像“OpenGL 4.5 | Vulkan | Direct3D 12”的行。
（是的，OpenGL ES 版本号甚至没有意义，并且与 OpenGL 的版本号不匹配，我假设这样供应商就不必害怕跳过主要版本号，而是将它们视为“增量”更改，尽管 ES 3.2 比 3.0 需要更多的硅）
在实践中，魔鬼在细节中，所以你有 f.i.曲面细分在 OpenGL ES 3.2 但在 OpenGL 4.0 中，但计算着色器已经在 OpenGL ES 3.1 中，但在 OpenGL 中是后来引入的 - 4.3 - 以及其他级别的这种疯狂。
【讨论】：
在桌面 OpenGL 抛弃 GL 3.1 的固定功能废话之前，IHV 实施它是不合理的。即使在这之后，还有一个更大的问题：他们无法处理。
例如，GL 3.1 需要对统一缓冲区对象的支持。那是在 2009 年初。在 2014 年的 ES 3.0 之前，没有任何版本的 ES 提供这样的东西；那时，桌面 GL 是 4.5 版。
您必须了解的是，移动和桌面硬件的发展速度和时间不同。 OpenGL 的版本旨在展示那个时代桌面 GPU 上可用的硬件功能。同样，OpenGL ES 版本暴露了那个时代移动硬件可以做的一些常见子集。 ES 2.0 的长期主导地位主要是因为对于主要硬件提供商实际支持的内容缺乏共识。
因此，每个 API 都旨在在一组特定的硬件上实现，因此对超出该关注领域的硬件需求视而不见。直到最近，任何移动 GPU 都可以支持桌面 GL 版本的所有功能。即便如此，它们仍然以非常不同的方式进化。
例如，GL 3.2 需要对几何着色器的支持。那是在 2009 年。直到 2015 年 ES 3.2 发布，OpenGL ES 才看到该功能成为一个要求。不仅如此，镶嵌着色器（以及更多功能）成为 ES 3.2 的核心，它在桌面 GL 中为 4.0。
相比之下，ES 3.1 需要计算着色器和图像加载/存储功能。这些仅分别在 4.3 和 4.2 的桌面 GL 中出现。
这意味着如果仅限于 ES 3.1 功能的移动硬件想要通过桌面 GL 公开其硬件......他们怎么能做到呢？他们不能使用任何桌面 GL 版本 3.2 或更高版本，因为那些需要 GS 而他们的 GPU 没有这些。但他们的 GPU 可以处理计算着色器和图像加载/存储，这只是更高 GL 版本中的核心。
它们将仅限于桌面 GL 3.1 + 扩展。
为了满足其特定平台的需求，这两个 API 发生了分歧。它们各自的硬件进化路线最近才开始融合为一个合理的公共子集。
这就是为什么现在我们发现两个 API 都被替换了（并且被设计为可以通过使用特性在两组硬件上运行的 API）为什么要打扰把精力花在很快就会变得无关紧要的事情上？
【讨论】：