OpenGL向后兼容OpenGL ES吗？

Question

OpenGL ES声称是OpenGL的一个子集，理论上它意味着任何OpenGL ES程序都可以在PC上作为常规OpenGL运行; 然而，似乎OpenGL ES对某些函数（ glOrtho vs glOrthof ）的命名约定略有不同。 这有关系吗？ OpenGL ES应用程序是否仍可以使用开箱即用的OpenGL GPU /驱动程序或仅重新编译？

Answer 1

OpenGL ES应用程序是否仍可以使用开箱即用的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实际上在两种情况下的工作方式相同，因此更容易使用。 现在，互操作更多的是避免两者都无法使用的功能。

Answer 2

当前版本的OpenGL（4.x）和OpenGL ES（2.x）是相似的，尽管有足够的差异，移植代码只能通过重新编译才能工作。 正如@Nicol Bolas指出的那样，OpenGL中有许多功能甚至不存在于OpenGL ES中，而一些API的行为略有不同。 此外，平台支持非常不同（即设置渲染上下文等）。

OpenGL ES 2.0实际上并不向后兼容1.x，因为模型从旧的立即模式样式（如OpenGL 2.1和更早版本中所包含的）更改为更现代的基于着色器的模型。

OpenGL v3和v4弃用了许多不合时宜的2.x功能，尽管主要驱动程序保留了兼容模式以继续这种旧的支持。

OpenGL 4.x中的GL_ARB_ES2_compatibility扩展有助于将桌面和移动版本更紧密地结合在一起，以简化可移植性。

像glOrtho和glOrthof这样的细微差别显然很容易管理，但是你需要为其他功能编写包装器。