例如，在整个ARM马里系列中，许多GPU支持OpenGL ES 3+、Direct3D 9+(有些支持11/12(，有些支持Vulkan，但没有一个支持OpenGL，甚至不支持支持固定管道的OpenGL的新版本。阿德里诺也是如此。
硬件是否无法支持完整的GL(如果是，为什么？(，或者驱动程序开发人员只是没有实现它？
在Desktop 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都被取代了(并且被一个API取代，该API在设计上可以通过使用功能在两组硬件上运行(为什么要花精力在很快变得无关紧要的事情上？
因为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 2.1(+FBO(|OpenGL ES 2|Direct3D 9
- OpenGL 3.3 | OpenGL ES 3.0/3.1| Direct3D 10
- OpenGL 4 | OpenGL ES 3.2 | Direct3D 11
再加上一行，看起来像"OpenGL 4.5|Vulkan|Direct3D 12"。
(是的，OpenGL ES的版本号甚至没有意义，也与OpenGL的版本号不匹配，我认为这样供应商就不会害怕不得不跳过一个主要的数字，而是将其视为"增量"更改，尽管ES 3.2需要比3.0更多的硅(
在实践中，魔鬼在于细节，所以在OpenGL ES 3.2中有f.i.镶嵌，但在OpenGL 4.0中有，但计算着色器已经在OpenGL ES 3.1中了，但在后来引入的OpenGL中——4.3——以及其他级别的疯狂。