例如，在整个ARM Mali系列中，许多GPU支持OpenGL ES 3 +，Direct3D 9+（一些支持高达11/12），有些支持Vulkan，但没有一个支持OpenGL，甚至没有支持OpenGL的更新版本弃用固定管道的OpenGL。与Adreno一样。
硬件是否无法支持完整的GL（如果是，为什么？），或者驱动程序开发人员是否没有实现它？
答案 0 :(得分：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年.OpenGL ES没有看到该功能成为要求，直到2015年发布ES 3.2。不仅如此，曲面细分着色器（以及更多功能）成为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都被替换了。为什么要花费精力去做一些很快变得无关紧要的事情呢？
答案 1 :(得分：2)
因为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 - 以及其他级别的疯狂。