There is an ARB version, it is not part of the core OpenGL 2.0 (it's still just an extension), and I was under the impression that no ATI cards (including the newer ones) supported it yet.

[Edit: I was confusing PBOs and pbuffers in this post...]

I ran into this, but could use the new (but non-standard) offscreen buffer using glGenFramebuffersEXT/glDeleteFramebuffersEXT. This is apparently the way things will be going in the future with OpenGL, as pbos are phased out.

Does anyone know if ATI's drivers support these at all?

[Edited by - taby on March 15, 2006 10:09:40 AM]

Quote:Original post by taby
I ran into this, but could use the new (but non-standard) offscreen buffer using glGenFramebuffersEXT/glDeleteFramebuffersEXT. This is apparently the way things will be going in the future with OpenGL, as pbos are phased out.

Does anyone know if ATI's drivers support these at all?

You are thinking of PBuffers. They are different from pixel buffer objects (PBOs). PBOs are an extension to VBOs that allow buffer objects to be used with pixel data as well as vertex data.

Framebuffer (one word) objects (FBOs) are supported in ATI drivers now as well.

Yes, all these similarly named extensions can get confusing. [grin]

Quote:Original post by Kalidor

Quote:Original post by taby
I ran into this, but could use the new (but non-standard) offscreen buffer using glGenFramebuffersEXT/glDeleteFramebuffersEXT. This is apparently the way things will be going in the future with OpenGL, as pbos are phased out.

Does anyone know if ATI's drivers support these at all?

You are thinking of PBuffers. They are different from pixel buffer objects (PBOs). PBOs are an extension to VBOs that allow buffer objects to be used with pixel data as well as vertex data.

Framebuffer (one word) objects (FBOs) are supported in ATI drivers now as well.

Yes, all these similarly named extensions can get confusing. [grin]

You've got me! My ignorance shines through. :)

I hadn't a clue that there was a difference, but now I do. Much thanks (for taking it easy on a recovering D3D-programmer). ;)

Quote:Original post by anist
Ok, i have it working on NVidia, but I am noticing some bad performance characterisitcs on my card. PBO's (which are different from PBuffers), upload at about 10ms. glTexImage2D uploads at 5ms, which seems odd since PBO's I understood were faster. Also, glTexSubImage2D uploads at a nominal 5ms, which is even odder because I have always heard there was a signifigant increase in performance over glTexImage. This was benchmarked with a 1024x1024 texture, 32 bit BGRA format.

Any thoughts on these benchmarks?

If you haven't seen it yet, I recommend reading this paper on Fast Texture Transfers from NVIDIA's site. It seems like you may have already seen it though since I notice you are using 32-bit BGRA. Either way it couldn't hurt to take another pass through it and make sure you are doing everything the way they mention.

The performance benefits of using PBOs are from making the reading and writing of the texture data asynchronous, so if all you are doing is just reading the texture data I wouldn't expect much of a performance increase. With that said, it does seem a bit odd that it would be even slower with PBOs but again it probably depends on whatever else you are doing as well.

I'm also curious how you went about timing that. Did you use the GL_NV_fence extension? Also the timer's precision could come into play with a difference of 5 and 10 ms, just something to keep in mind.

Quote:Original post by taby
You've got me! My ignorance shines through. :)

I hadn't a clue that there was a difference, but now I do. Much thanks (for taking it easy on a recovering D3D-programmer). ;)

[grin]
Don't mention it, we've all been in similar situations before.