still looking for answers on the pbuffers problem I encounter, I ran the glview v2.13 app to check what extensions were supported by my radeon 9600 128 Mo board installed with catalysts 4.11
I ran the glview rendering tests suite with the “use pbuffers” option ticked (glview uses pbuffers to create a motion blur effect).
With pbuffers activated, the rendering failed on the fourth (vertex program) and fifth (vertex objects) tests, as if the full texturing engine went mad and that the framebuffer swapping were desynchronized. All other thests ran fine (including the OpenGL 2.0 test)
Seems like pbuffers are allergic to framgment/ vertex programs. Would anybody like to share some experience on using double buffered pbuffers on ATI hardware?
I use float pbuffers with GLSlang and they work fine(R9800 128MB CATALYST 4.9/4.10/4.11).
But why would you like to use double buffered pbuffers? From what I know, pbuffers are offscreen(invisible) so there is no need to make them double buffered.
I use GLSL with pbuffers, too. I´m using several pbuffers (9 in total), floating point and 32bit mixed. None of them is doublebuffered. I create 3 rendering contexts, one for each group of pixel formats in use (framebuffer, fp-pbuffer and 32bit pbuffer). On Windows I make use of ARB_render_texture, on Linux glCopyTexSubImage. In either case I only employ ATI_texture_float and ATI_pixel_format_float. The code works on ATI9500+ class cards (Windows only, since no GLSL on Linux) and on GF6800GT (both, Linux and Windows).
I noticed only one small discrepancy: when using a ATI_texture_float texture on the GF6800, you have to enable a GLSL program, even if you don´t need it. Otherwise you could get strange results (in my case, the rendering of a HDR skybox looked bad).
To sum it up: there seem to be no critical bugs/problems when combining pbuffers and GLSL.
FYC, the glview test with pbuffer is single buffered
What it does is:
render the scene in the pbuffer.
render the pbuffer as texture in alpha transparency, without clearing the previous screen creating the blur effect. Ideally, I should have done a second pbuffer.
This test is used to work in Catalyst 4.10 and earlier versions. So apparently this is now broken …
Another note: Since Catalyst 4.12 beta, you cannot do fragment processing in to texture anymore (pbuffer + ARB fragment or GLSL). it’s totally broken (as well some regular GLSL rendering).
I’d like to use pbuffers with multiple drawable color surfaces (front/back/aux surface) instead of multiple pbuffers with a single color surface.
This is supposed to save a lot of time as a single context is fully shared by all the surfaces, thus you don’t have to do that expensive context switch, you just have to tell GL in what surface you want to draw using glDrawBuffer()
with the name of your color buffer as parameter
What happens when the application binds one color buffer of a pbuffer
to a texture and then tries to render to another color buffer of the
pbuffer?
If any of the pbuffer's color buffers are bound to a texture, then
rendering results are undefined for all color buffers of the pbuffer.
This prevents you from rendering from one of the color-buffers to another one of the same pbuffer. But that would be needed if you wanted to reasonably use those multiple buffers per pbuffer object.
I’m back with catalyst 4.7 since they are the only one that work with my stuff right now.
What I do is basically :
declare a floating point double buffer (successfully created)
set the pbuffer as the active context
using wglMakeCurrent();
load a GLSL shader that does smooth shading (no lighting at all, just interpolating vertex colors)
issue a glDrawBuffer(GL_BACK_LEFT) call
draw some geometry;
then I shift back to my frame buffer,
I bind the pbuffer as a texture using wglBindTexImageARB(hpc,WGL_BACK_LEFT_ARB);
then I display the texture on a large screen fitting QUAD. and I see… nothing.
-doing the same thing drawing in the FRONT buffer works as a charm, meaning I can see what’s just be drawn offscreen
the funny thing is that if I draw, in a single pass to both front and back surfaces of the pbuffer, anf then display the contents of its back buffer, I see the contents of its front buffer.
ex: FIRST draw box in back buffer, THEN draw sphere in front buffer, THEN bind back buffer as texture, display textured quad : yields a sphere. As if there were no back buffer despite the sucessfull double buffered pbuffer creation.
Originally posted by skynet: On Windows I make use of ARB_render_texture, on Linux glCopyTexSubImage.
There is a GLX_ATI_render_texture extension in Linux that’s pretty much equivalent to ARB_render_texture.
Yes, I know. Forgot to mention it. I make use of it, if present.
But its completely undocumented. Why?
Ok, its almost completely identical to ARB_render_texture on Windows. But why not write a single word about it on ATI´s OpenGL extension list? Before noticing it in the exension string and checking the headers for function names and enumerants I didn´t know that this extension even existed. Thats another point for “What kind of communication do you find lacking?”
I do work with double buffered pixel buffers. At first, I was unable to synchronize both my pixel buffer and my frame buffer. How did I succeed? I swap my pixel buffer’s front and back buffers by changing which of the two will be the current read and/or write buffer with glDrawBuffer and glReadBuffer. Obviously, the buffer I bind as a texture will be the buffer set as the current read buffer. In the end, it is as if I was calling glutSwapBuffers or any equivalent function.
Also, do not forget to unbind your pixel buffer before swapping its front and back buffers.
Finally, did you bind the texture to the texture unit with glBindTexture(GL_TEXTURE_2D, textureID) ?
