NVIDIA Forceware 75.90 => OpenGL 2.0.0 & fbo

OpenGL OpenGL: Advanced Coding
61

Originally posted by Nico:
[b]Has anyone used glew successfully to load fbo? GLEW_EXT_framebuffer_object is false although GL_EXT_framebuffer_object is included in the extension string…

(and glew is initialized correctly - at least other extensions like GLEW_ARB_multitexture are true).[/b]
Yes, seems the problem is that the extension implementation doesn’t fully support all the entrypoints. In particular, doesn’t support glFrameBufferTexture1DEXT.
When Glew detects the extension, as it has glFrameBufferTexture1DEXT as missing, glew decides that the extension is not supported.

U can see that in the glewInfo utility provided by glew

62

Originally posted by toni:
[b][QUOTE]Originally posted by Nico:
Yes, seems the problem is that the extension implementation doesn’t fully support all the entrypoints. In particular, doesn’t support glFrameBufferTexture1DEXT.
When Glew detects the extension, as it has glFrameBufferTexture1DEXT as missing, glew decides that the extension is not supported.

U can see that in the glewInfo utility provided by glew[/b]
Actually, that looks like a bug in glew : the function should be glFramebufferTexture1DEXT. I’d noticed that function was misnamed, but not that it affected detecting the extension…search and replace glFrameBufferTexture1DEXT for glFramebufferTexture1DEXT in glew.c,glew.h and glewinfo.c and recompile fixes the problem…

63

Did someone compare the speed of fbo to the pbuffer, especially when rendering depth only?
How expensive is switching the framebuffer?

64

Same question: is framebuffer switching faster than pbuffer’s ?

65

Another related question: Is it better to switch framebuffers, or to bind new textures to the same framebuffer? When should I make two framebuffers and when should I just rebind textures?

66

Originally posted by Overmind:
Another related question: Is it better to switch framebuffers, or to bind new textures to the same framebuffer? When should I make two framebuffers and when should I just rebind textures?
Issue #8 in the FBO spec says validating framebuffer state might be ‘expensive’ (one of the reasons for having an fb object to switch in the first place), so I assume switching framebuffers is intended to be the fast path. Example 4 also uses 1 fb per texture.

67

Originally posted by KRONOS:

[quote]From 1.5 spec:

If the data argument of TexImage1D, TexImage2D, or TexImage3D is a null pointer (a zero-valued pointer in the C implementation), a one-, two-, or threed- dimensional texture array is created with the specified target, level, internalformat, width, height, and depth, but with unspecified image contents. In this case no pixel values are accessed in client memory, and no pixel processing is performed. Errors are generated, however, exactly as though the data pointer were valid.
[/QUOTE]A strong caution. If ARB_pixel_buffer_object is supported, and if you have a non-zero pixel unpack buffer object:

From GL_ARB_pixel_buffer_object:

If the data argument of TexImage1D, TexImage2D, or TexImage3D
is a null pointer (a zero-valued pointer in the C implementation)
and the pixel unpack buffer object is zero, a one-, two-, or three-
dimensional texture array is created with the specified target, level,
internalformat, width, height, and depth border, but with unspecified
image contents. In this case no pixel values are access in client
memory, and no pixel processing is performed. Errors are generated,
however, exactly as though the data pointer were valid. Otherwise if
the pixel unpack buffer object is non-zero, the data argument is
treatedly normally to refer to the beginning of the pixel unpack
buffer object’s data.

Ambiguous matter. The manpage for glBitmap states:

From glBitmap man page:
[b]
NOTES
To set a valid raster position outside the viewport, first
set a valid raster position inside the viewport, then call
glBitmap with NULL as the bitmap parameter and with xmove
and ymove set to the offsets of the new raster position.
This technique is useful when panning an image around the
viewport.

[/b]

The core spec itself is silent on this matter, and so is ARB_pixel_buffer_object. Is this a manpage bug? A spec bug? Your interpretation may vary.

-mr. bill

68

Originally posted by 3B:
Issue #8 in the FBO spec says validating framebuffer state might be ‘expensive’ (one of the reasons for having an fb object to switch in the first place), so I assume switching framebuffers is intended to be the fast path. Example 4 also uses 1 fb per texture.
So for example if I want to render to a cubemap, I would create 6 framebuffers, and bind a cubemap face and a shared depth renderbuffer to each of them. And if I want to render to a 2D texture with the same dimensions, I make another new framebuffer object, again reusing the shared depth renderbuffer. Is this correct?

69

Originally posted by Overmind:
So for example if I want to render to a cubemap, I would create 6 framebuffers, and bind a cubemap face and a shared depth renderbuffer to each of them. And if I want to render to a 2D texture with the same dimensions, I make another new framebuffer object, again reusing the shared depth renderbuffer. Is this correct?
Thats how I read the spec…Though I suppose if MAX_COLOR_ATTACHMENTS > 1, you could attach more than 1 face or texture to a framebuffer and switch with DrawBuffer, no idea how that would compare speed wise to switching framebuffers.

70

Originally posted by Overmind:
Another related question: Is it better to switch framebuffers, or to bind new textures to the same framebuffer? When should I make two framebuffers and when should I just rebind textures?
I’d be super-interested in vendor comments on this one too. What’s the fast path? I would’ve thought that using multiple fbos would be slower, since you have to switch fbos and also attach (and detach? or is that unnecessary for rendering from a previously attached texture of an unbound fbo? Maybe, according to example 4) and detach textures as I render into them and render from them. Using one fbo I just bind the fbo when I need it and attach and detach textures where I need to - I lose the overhead of switching fbos. A quick skim over the spec doesn’t really say one way or another (excepting 3B’s comments).

71

Originally posted by 3B:
Actually, that looks like a bug in glew : the function should be glFramebufferTexture1DEXT. I’d noticed that function was misnamed, but not that it affected detecting the extension…search and replace glFrameBufferTexture1DEXT for glFramebufferTexture1DEXT in glew.c,glew.h and glewinfo.c and recompile fixes the problem…[/QB]
Indeed :slight_smile:

Thanx

72

76.10 out
Time to try again :stuck_out_tongue:

http://www.station-drivers.com/forum/viewtopic.php?t=1174

73

oh new drivers :slight_smile: very fast, maybe the stencil buffer in EXT_framebuffer_object can be used. :slight_smile:

74

Originally posted by Matt Zamborsky:
oh new drivers :slight_smile: very fast, maybe the stencil buffer in EXT_framebuffer_object can be used. :slight_smile:
doesn’t look like it :frowning:
same list of supported renderbuffer formats as far as I can see (and same odd chunk of GL_INVALID_OPERATION instead of GL_INVALID_ENUM for the NV_float_buffer formats 0x8880-0x888b)

75

oh, I see :frowning: . But it’s still beta drivers so it’s still good to have at least something .

76

Does anyone see a problem with this code?
I think it should work, but I’m getting some weird trouble. Could it be because NV drivers are beta?

uint fb;
uint color_tex;

glGenFramebuffersEXT(1, &fb);
glGenTextures(1, &color_tex);

glGenRenderbuffersEXT(1, &depth_rb);

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fb);

//Initialize color texture
glBindTexture(GL_TEXTURE_2D, color_tex);
glTexParameteri(GL_TEXTURE_2D,GL_GENERATE_MIPMAP_SGIS, GL_TRUE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 512, 512, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, color_tex, 0);

CheckFramebufferStatus();

glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, 0);

glDeleteTextures(1, &color_tex);
glDeleteRenderbuffersEXT(1, &fb);

77

I also happened ever,when i updated GLEW to version1.3.1, it works now.

Originally posted by Nico:
[b]Has anyone used glew successfully to load fbo? GLEW_EXT_framebuffer_object is false although GL_EXT_framebuffer_object is included in the extension string…

(and glew is initialized correctly - at least other extensions like GLEW_ARB_multitexture are true).[/b]

78

Here is a working FBO example . Take look into FBOTest class.

yooyo

79

Anyone tried to switch a hundred times FBO per frame ? That was the main point preventing me to use RTT, I need to compute a hundred small independent renders per frame and context switching was way too slow with RTT method.

80

Got bored and decided to do some FBO speed testing, thought I would post some numbers before going to sleep since everyone seems curious :slight_smile:

Numbers so far (with lots of stuff being done inefficiently) on 2.6GHz p4, 6800 GT, 76.10 betas :

10 sorta shiny spheres, reflecting 3 levels deep = 30-35 FPS. (180 fb switches/frame, 320 tris/sphere, ~140k tris for entire scene)
with just the glClear in the reflection passes = ~60-70 FPS
with just the BindFramebufferEXT = ~85-90 FPS

so looks like pretty easily 5-10k fb switches/sec depending on how much you do per buffer…

misc implementation details :
cube maps are 256x256xRGBA16F (doesn’t look fill limited, about the same speed at 64x64)
No mipmaps on the cubemaps, since I couldn’t get that working with these drivers…

1 Framebuffer per cubemap face, 2 cubemaps per object for a total of 120 framebuffers

24bit depth renderbuffer shared between all framebuffers