OpenGL ES声称是OpenGL的一个子集，理论上这意味着任何OpenGL ES程序都可以在PC上作为常规OpenGL运行;然而，OpenGL ES似乎对某些函数的命名约定略有不同(glOrtho与glOrthof(。这重要吗？OpenGL ES 应用程序是否仍然可以与开箱即用的 OpenGL GPU/驱动程序一起使用，或者只需重新编译即可使用？
OpenGLES 应用程序是否仍然可以与开箱即用的 OpenGL GPU/驱动程序一起使用，或者只需重新编译即可使用？
不。有点，但是既然您提出了glOrtho，这意味着您谈论的是ES 1.x而不是2.x，不适合您。ES 3.0 为组合添加了一些新内容;有关详细信息，请参阅底部。
OpenGL ES 1.x不是任何版本的OpenGL的子集。它们是一些非常显着的差异。您可能能够编写代码到一个公共子集，但为了做到这一点，您将浪费很多东西。在两个平台上。
ES 2.x与桌面GL 2.1有更多的相似之处，但它仍然不是一个合适的子集。例如，glTexImage2D具有完全不同的行为。在桌面 GL 下，最后三个参数不会影响纹理的实际格式。在 ES 2.0 下，它们定义了纹理的实际图像格式。你可以编写一个有效的glTexImage2D命令，在 ES 2.0 和桌面 GL 2.1 下做同样的事情，但你在桌面 GL 下会浪费很多东西来做到这一点(比如选择一个大小的内部格式(。
话虽如此，您通常可以通过抽象来屏蔽 API 差异。你在ES 2.0中会遇到的最大问题是GLSL。
GLSL ES添加了几个新关键字，特别是精度限定符。桌面 GLSL 1.20(与 GL 2.1 配对(没有这些关键字。台式机 GLSL 1.30 及更高版本可以，但这些绑定到 GL 3.0 硬件。因此，很难为 ES 2.0 编写一个可以在桌面 GL 2.1 硬件上未经修改运行的着色器。
当然，这并非不可逾越。一些明智的 #defines，它们本身可以针对不同的语言 #ifdef，可以使这变得相当简单。但是您仍然必须找到所有这些案例。
最近发布的OpenGL ES 3.0也不是OpenGL 3.3的适当子集，但它比ES 2.0更接近。真正重要的是，GLSL 3.30 几乎与 GLSL ES 3.00 相同。因此，您可以更轻松地在两者之间互换着色器。
ES 3.0 中有一些限制在3.3 中没有，但通常这些限制很容易避免(无论如何，使用其中大多数都是不好的做法(。ES 3.0 的一些功能在技术上不在 GL 3.3 中，但它们在 GL 3.3 的常用核心扩展中(例如 ARB_texture_storage，并且有ES3_compatibility扩展来增加兼容性(。但是现在使用起来要容易得多，因为glTexImage2D实际上在两种情况下以相同的方式工作。现在，互操作更多的是避免两者不可用的功能。
OpenGL (4.x( 和 OpenGL ES (2.x( 的当前版本是相似的，尽管存在足够的差异，仅通过重新编译来移植代码是行不通的。 正如@Nicol Bolas指出的那样，OpenGL中的许多功能甚至没有OpenGL ES，而某些API的行为略有不同。 此外，平台支持也非常不同(即设置渲染上下文等(。
OpenGLES 2.0实际上并不向后兼容1.x，因为模型从旧的即时模式样式(如OpenGL 2.1及更早版本所述(更改为更现代的基于着色器的模型。
OpenGL v3 和 v4 弃用了许多不合时宜的 2.x 功能，尽管主要驱动程序保留了兼容模式以继续这种较旧的支持。
OpenGL 4.x 中的GL_ARB_ES2_compatibility扩展有助于将桌面版和移动版更紧密地结合在一起，从而简化可移植性。
像glOrtho与glOrthof这样的微小差异显然很容易管理，但你需要为其他功能编写包装器。