OpenGL ES声称是OpenGL的一个子集，这意味着任何OpenGL ES程序理论上都可以在PC上作为常规的OpenGL运行; 然而，似乎OpenGL ES对某些函数（glOrtho与glOrthof）有稍微不同的命名约定。这是否重要？一个OpenGL ES应用程序能否直接在OpenGL GPU /驱动程序上工作或仅需要重新编译？
2个回答
9
一个OpenGL ES应用程序能否直接使用OpenGL GPU/driver或仅重新编译即可正常工作？
不行。如果你提到了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硬件上运行的着色器是困难的。
当然，这并非不可克服。一些明智的#define，它们本身可以针对不同的语言进行#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 扩展可以提高兼容性）。现在，由于
不行。如果你提到了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硬件上运行的着色器是困难的。
当然，这并非不可克服。一些明智的#define，它们本身可以针对不同的语言进行#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 在两种情况下的工作方式相同，所以与之配合更加容易。现在，交互操作更多地是要避免功能不可用的情况。- Nicol Bolas
4
当前的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之类的小差异显然很容易管理，但您需要为其他功能编写包装器。
- gavinb
2
当前版本的OpenGL（4.x）和OpenGL ES（2.x）非常相似，并且在很大程度上是兼容的。当然，如果您实际上没有使用任何2.1版本之后的功能，比如整数纹理、统一缓冲对象、分离着色器对象、高级着色器（几何和细分），我可以继续列举，但我的观点已经很清楚了。只有在您“削弱”桌面GL代码时它们才会相似。 - Nicol Bolas
2谢谢您的纠正。我已经相应地更新了上面的内容，希望现在是正确的了。我也给您的答案点了赞。 - gavinb
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接