OpenGL兼容性，命名约定以及ARB与EXT

我以为我对OpenGL命名约定和扩展的工作方式已经形成了大致的了解，直到偶然发现一个令我困惑的案例。

到目前为止，这是我的理解：

没有后缀 -例如glGenBuffers()。此功能是核心配置文件的一部分。该wiki页面告诉我，这是添加到从1.5版本开始核心简档。

ARB-例如glGenBuffersARB()。此功能是标准化GL_ARB_vertex_buffer_object扩展的一部分。此扩展的规范GenBuffersARB()在“新过程和函数”部分中明确声明。“依赖关系”部分告诉我，如果硬件支持扩展，则可以从1.4+上下文访问此文件。

EXT-这些是特定于供应商的扩展和功能，只有某些供应商可以支持。顶点缓冲区对象在注册表中似乎没有EXT扩展名。

这是我的理解破裂的地方：

glGenFramebuffers正如Wiki所示，在3.0中已添加到核心。

现在，我想以低于3.0的核心配置文件版本访问帧缓冲区功能。因此，我想将其用作扩展。规范注册表告诉我，有两个可用的扩展名-ARB和EXT。

问题1-如果存在ARB扩展名，为什么存在EXT扩展名？您是否总会选择标准化的而不是特定于供应商的一种？

查看“新过程和函数”部分中的ARB规范可知，该扩展定义了该GenRenderbuffers()函数。这次没有ARB后缀。GLEW根本没有功能原型glGenRenderbuffersARB()。奇怪的。

EXT规范GenRenderbuffersEXT()在新功能部分中确实具有功能，而GLEW也具有glGenRenderbuffersEXT()。

问题2-如果有EXT后缀，为什么没有ARB后缀？假设ARB函数的名称和核心函数的名称相同，这对ARB如何起作用？

问题3-我最终希望使用1.4配置文件中的Framebuffer功能。我应该使用哪个扩展名和哪个功能集，以便获得最大的硬件兼容性覆盖？

问题1-通常EXT版本首先是两个或多个供应商之间的协作。ARB扩展需要Khronos的有投票权的成员进行更多讨论，并且可以在获得批准之前对EXT版本进行更改。请参阅GL_ARB_direct_state_access扩展，与GL_EXT_direct_state_access相比，它具有许多更改。

问题2 -GL_ARB_framebuffer_object扩展的问题部分说明了为什么函数没有ARB后缀的原因：

（8）为什么此扩展中的新令牌和入口点没有像其他ARB扩展那样的后缀？

   RESOLVED: Unlike most ARB extensions, this is a strict subset of
   functionality already approved in OpenGL 3.0. This extension
   exists only to support that functionality on older hardware that
   cannot implement a full OpenGL 3.0 driver. Since there are no
   possible behavior changes between the ARB extension and core
   features, source code compatibility is improved by not using
   suffixes on the extension.

问题3-如果要在GL版本小于3.0的上下文中使用帧缓冲区对象，则需要查看扩展字符串：

1. 如果支持GL_ARB_framebuffer_object，请使用非ARB函数。
2. 如果仅支持GL_EXT_framebuffer_object，请使用EXT函数。
3. 如果两个扩展都不支持，则需要回退到OS级别的屏幕外渲染，例如pbuffers。