All geek questions in one place

GlGenFramebuffers or glGenFramebuffersEXT?

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

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

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

What is the right option to use? Do some drivers really support one but not the other? Is it right to try to retreat from one to another, 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 that no matter what combination of code I use to use FBOs, some different combinations of user reports, they see nothing (i.e. nothing displays).

Here is the code in which I determine whether to use ARB functions (without suffix) or EXT-suffix functions. This starts at startup:

 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 during startup, it creates an FBO in anticipation of rendering the texture:

 // 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 went through many variations of this code, and I just can't get it to work for everyone. There is always a group of users who do not report anything at all. ATI Radeon HD cards look especially problematic. I'm not sure if there is a driver error, but I think it is more likely that my code above makes the wrong assumption.

500 rep bounty and I will send a free business license to anyone who knows what's wrong! (Worth £ 99)

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

ATI Mobility Radeon HD 5650

ATI Radeon X1600 Pro

ATI Mobility Radeon HD 4200

No texture rendering is actually performed. It seems that calling glGenFramebuffers on its own stops completely rendering on these cards. I could postpone the creation of FBO for the first time the rendering texture is actually being executed, but presumably this will just stop rendering again.

I could use GLEW, but what does it do that my code does not? I looked at the source and seemed to use a similar wglGetProcAddress list. Methods are returned in my case, otherwise glGenFramebuffers will be NULL and fail. Any ideas ...?

+6
source share
2 answers

If the GL_EXT_framebuffer_object extension is GL_EXT_framebuffer_object , you can use wglGetProcAddress("glGenFramebuffersEXT"); .

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

+8
source

The code you included is not a problem. Of course, anchor points must be obtained, as you already know.

In the case of ARB_framebuffer_object supported, entry points without the EXT suffix. If supported, EXT_framebuffer_object uses entry points with the suffix EXT. If both of them are supported, you can select the implementation by getting the correct anchor points.

I am very interested in this question (since I had a similar doubt because you).

If you are comparing the ARB specification with the EXT specification, you may notice many differences.

Here I will give the most interesting points of the ARB specification on this topic.

The specification is very long, but the ARB variant contains a lot of discussion on the EXT compatibility issue. As you launch the application, the entry points are probably correct, and the error (as suggested by Nicholas Bolas) may be in the full framebuffer.

Imagine every possible check and double check the implementation twice (one of them takes into account the ARB specification, taking into account the EXT specification).

What additional functionality does this extension include EXT_framebuffer_object?

  Currently we incorporate the following layered extensions: * EXT_framebuffer_multisample * EXT_framebuffer_blit * EXT_packed_depth_stencil

In addition to the following functions:

  * 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.

  * 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 have a “framebuffer” binding (BindFramebuffer and BindFramebufferEXT). Are there differences in functionality between the two functions?

  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.
+3
source

Source: https://habr.com/ru/post/894107/

More articles:


All Articles