windows glGenFramebuffers 还是 glGenFramebuffersEXT？

glGenFramebuffers or glGenFramebuffersEXT?

提问by AshleysBrain

I'm confused. To use the Framebuffer Object extension (FBO) in OpenGL 1.x on Windows, which of these do I use?:

我糊涂了。要在 Windows 上的 OpenGL 1.x 中使用帧缓冲对象扩展 (FBO)，我应该使用哪些？：

wglGetProcAddress("glGenFramebuffers");
// or
wglGetProcAddress("glGenFramebuffersEXT");

As far as I can tell from reports from users with different hardware, some drivers support all combinations of neither, one of the two, or both.

据我从使用不同硬件的用户的报告中可以看出，一些驱动程序支持两者之一、两者之一或两者的所有组合。

Which is the right one to use? Do some drivers really support one but not the other? Is it correct to try to fall back from one to the other if not found?

哪个是正确使用的？有些驱动程序真的支持一种而不支持另一种吗？如果找不到，尝试从一个退回到另一个是否正确？

---

---

Edit:I'm still having serious problems with ATI Radeon cards and the code around this. We just launched a commercial editor using this code (www.scirra.com). It seems no matter what combination of code I use to use FBOs, some different combination of users reports they cannot see anything at all (i.e. nothing renders).

编辑：我仍然在使用 ATI Radeon 卡和相关代码时遇到严重问题。我们刚刚使用此代码启动了一个商业编辑器 (www.scirra.com)。似乎无论我使用什么代码组合来使用 FBO，一些不同的用户组合报告说他们根本看不到任何东西（即没有任何东西呈现）。

Here's the code where I detect whether to use the ARB functions (no suffix) or the EXT-suffixed functions. This runs on startup:

这是我检测是使用 ARB 函数（无后缀）还是 EXT 后缀函数的代码。这在启动时运行：

gl_extensions = reinterpret_cast<const char*>(glGetString(GL_EXTENSIONS));
gl_vendor = reinterpret_cast<const char*>(glGetString(GL_VENDOR));
gl_renderer = reinterpret_cast<const char*>(glGetString(GL_RENDERER));
gl_version = reinterpret_cast<const char*>(glGetString(GL_VERSION));
gl_shading_language = reinterpret_cast<const char*>(glGetString(GL_SHADING_LANGUAGE_VERSION));

// If OpenGL version >= 3, framebuffer objects are core - enable regardless of extension
// (the flags are initialised to false)
if (atof(gl_version) >= 3.0)
{
    support_framebuffer_object = true;
    support_framebuffer_via_ext = false;
}
else
{
    // Detect framebuffer object support via ARB (for OpenGL version < 3) - also uses non-EXT names
    if (strstr(gl_extensions, "ARB_framebuffer_object") != 0)
    {
        support_framebuffer_object = true;
        support_framebuffer_via_ext = false;
    }
    // Detect framebuffer object support via EXT (for OpenGL version < 3) - uses the EXT names
    else if (strstr(gl_extensions, "EXT_framebuffer_object") != 0)
    {
        support_framebuffer_object = true;
        support_framebuffer_via_ext = true;
    }
}

Then later on during startup it creates a FBO in anticipation of rendering to texture:

然后在启动期间它会创建一个 FBO 以期待渲染到纹理：

// Render-to-texture support: create a frame buffer object (FBO)
if (support_framebuffer_object)
{
    // If support is via EXT (OpenGL version < 3), add the EXT suffix; otherwise functions are core (OpenGL version >= 3)
    // or ARB without the EXT suffix, so just get the functions on their own.
    std::string suffix = (support_framebuffer_via_ext ? "EXT" : "");

    glGenFramebuffers = (glGenFramebuffers_t)wglGetProcAddress((std::string("glGenFramebuffers") + suffix).c_str());
    glDeleteFramebuffers = (glDeleteFramebuffers_t)wglGetProcAddress((std::string("glDeleteFramebuffers") + suffix).c_str());
    glBindFramebuffer = (glBindFramebuffer_t)wglGetProcAddress((std::string("glBindFramebuffer") + suffix).c_str());
    glFramebufferTexture2D = (glFramebufferTexture2D_t)wglGetProcAddress((std::string("glFramebufferTexture2D") + suffix).c_str());
    glCheckFramebufferStatus = (glCheckFramebufferStatus_t)wglGetProcAddress((std::string("glCheckFramebufferStatus") + suffix).c_str());
    glGenerateMipmap = (glGenerateMipmap_t)wglGetProcAddress((std::string("glGenerateMipmap") + suffix).c_str());

    // Create a FBO in anticipation of render-to-texture
    glGenFramebuffers(1, &fbo);
}

I have been through many variations of this code, and I simply cannot get it to work for everyone. There is always a group of users who report nothing renders at all. ATI Radeon HD cards seem to be particularly problematic. I'm not sure if there's a driver bug involved, but I guess it's more likely my above code is making an incorrect assumption.

我已经经历了这段代码的许多变体，我根本无法让它对每个人都有效。总是有一群用户报告根本没有渲染。ATI Radeon HD 卡似乎特别成问题。我不确定是否涉及驱动程序错误，但我想我上面的代码更有可能做出了不正确的假设。

500 rep bounty and I'll send a free Business license to anyone who knows what's wrong! (Worth ￡99)

500 代表赏金，​​我会向任何知道出了什么问题的人发送免费的营业执照！(价值￡99)

---

---

Edit 2: some more details. Here is a list of cards that this is known to fail on:

编辑2：更多细节。以下是已知会失败的卡片列表：

ATI Mobility Radeon HD 5650

ATI Mobility Radeon HD 5650

ATI Radeon X1600 Pro

ATI Radeon X1600 Pro

ATI Mobility Radeon HD 4200

ATI Mobility Radeon HD 4200

No rendering to texture is actually done. It appears the glGenFramebufferscall alone stops rendering completely on these cards. I could defer creation of the FBO to the first time render-to-texture is actually done, but then presumably it will just stop rendering again.

实际上没有渲染到纹理。看来glGenFramebuffers仅调用就完全停止在这些卡上呈现。我可以将 FBO 的创建推迟到第一次实际完成渲染到纹理时，但大概它会再次停止渲染。

I could use GLEW, but what does it do that my code doesn't? I had a look through the source and it seems to use a similar list of wglGetProcAddress. Methods are being returned in my case, else glGenFramebufferswould be NULL and crash. Any ideas...?

我可以使用 GLEW，但是我的代码不能使用它有什么作用呢？我查看了源代码，它似乎使用了类似的wglGetProcAddress. 在我的情况下正在返回方法，否则glGenFramebuffers将是 NULL 并崩溃。有任何想法吗...？

回答by Tobi

If the extension GL_EXT_framebuffer_objectis present, then you can use wglGetProcAddress("glGenFramebuffersEXT");.

如果存在扩展名GL_EXT_framebuffer_object，则可以使用wglGetProcAddress("glGenFramebuffersEXT");.

If the OpenGL version is >= 3.0 (in this version the FBO extension was added to the core), then you can use wglGetProcAddress("glGenFramebuffers");.

如果 OpenGL 版本 >= 3.0（在这个版本中 FBO 扩展被添加到核心），那么你可以使用wglGetProcAddress("glGenFramebuffers");.

回答by Luca

The code you have included is not the problem. Of course, the binding points shall be obtained as you already do.

您包含的代码不是问题。当然，绑定点应该和你一样获得。

In the case ARB_framebuffer_objectis supported, uses the entry points without EXTsuffix. In the case EXT_framebuffer_objectis supported, uses the entry points with EXTsuffix. If both are supported, you can select the implementation by getting the right binding points.

在支持ARB_framebuffer_object的情况下，使用不带EXT后缀的入口点。在支持EXT_framebuffer_object的情况下，使用带有EXT后缀的入口点。如果两者都支持，您可以通过获取正确的绑定点来选择实现。

I am very interested on this issue (since I had a similar doubtbecause you).

我对这个问题很感兴趣（因为我有类似的疑问，因为你）。

If you compare the ARBspecification with the EXTspecification, you can notice a lot of differences.

如果将ARB规范与EXT规范进行比较，您会发现很多不同之处。

Here, I will quote the most interesting ARBspecification paragraphs on this topic.

在这里，我将引用有关此主题的最有趣的ARB规范段落。

The specification is the very long, but the ARBvariant contains many discussions on the EXTcompatibility issue. Since you're application run, the entry points are probably correct, and the error (as suggested by Nicolas Bolas) could be in the framebuffer completeness.

规范很长，但ARB变体包含许多关于EXT兼容性问题的讨论。由于您正在运行应用程序，因此入口点可能是正确的，并且错误（如 Nicolas Bolas 所建议的）可能在于帧缓冲区的完整性。

Introduce every check possible, and double-check the implementation twice (one taking ARBspec in mind, one taking EXTspec in mind).

引入所有可能的检查，并仔细检查实现两次（一次考虑ARB规范，一次考虑EXT规范）。

---

---

What additional functionality does this extension include over EXT_framebuffer_object?

此扩展程序在 EXT_framebuffer_object 上包含哪些附加功能？

   Currently we incorporate the following layered extensions:

     * EXT_framebuffer_multisample
     * EXT_framebuffer_blit
     * EXT_packed_depth_stencil

As well as the following features:

以及以下功能：

     * Permit attachments with different width and height (mixed
       dimensions)

     * Permit color attachments with different formats (mixed
       formats).

     * Render to 1 and 2 component R/RG formats that are provided
       via the ARB_texture_rg extension. L/A/LA/I will be
       left for a separate (trivial) extension.

     * Gen'ed names must be used for framebuffer objects and
       renderbuffers.

     * Added FramebufferTextureLayer.
  ...

---

---

What are the other differences from EXT_framebuffer_object.

与 EXT_framebuffer_object 的其他区别是什么。

     * Framebuffer completeness only considers the attachments named
       by DRAW_BUFFERi and READ_BUFFER.  Any other attachments do
       not affect framebuffer completeness.  (In
       EXT_framebuffer_object, all attachments affected framebuffer
       completeness, independent of the DRAW_BUFFERi and READ_BUFFER
       state.)
     * Added new queries for the sizes of the bit planes for color, 
       depth and stencil attachments at a framebuffer attachment point.
     * Added new queries for framebuffer attachment component type and
       color encoding.
     * Many other minor tweaks to synchronize with the GL3 framebuffer
       objects.
     * ARB FBOs are not shareable.

---

---

This extension and EXT_framebuffer_object both have "bind framebuffer" functions (BindFramebuffer and BindFramebufferEXT). Are there any differences in functionality between the two functions?

此扩展和 EXT_framebuffer_object 都具有“绑定帧缓冲区”功能（BindFramebuffer 和 BindFramebufferEXT）。这两个函数之间在功能上有什么区别吗？

    RESOLVED: Yes. Both extensions will create a new framebuffer object
    if called with an unused name. However, BindFramebuffer defined in
    this extension will generate an INVALID_OPERATION error if the name
    provided has not been generated by GenFramebuffer. That error did
    not exist in EXT_framebuffer_object, and this extension does not
    modify the behavior of BindFramebufferEXT. This difference also
    applies to BindRenderbuffer from this extension vs.
    BindRenderbufferEXT from EXT_framebuffer_object.