just so i can get a little headstart when the new nvidia drivers come out.
currently to render into a texture im going.
*clear the buffer
*render into buffer
*not using flush or finish (it isnt required is it, it works ok with out using it at the moment)
*use glCopyTexSubImage2D to update the texture with the new image
i imagine using pbuffers is exactlly the same. what are the advantages? speed perhaps?
also say ive got a lot of 256x256 textures i want to update is it better to
A/create a pbuffer of dimensions 256x256 then render into it ,read back then clear the buffer + repeat.
B/create a larger pbuffer say 1024x1024 render into it 4*4 times , read back + update the 16 images and then clear and repeat if neccessary?
Today (not necessarily next week), for dynamically generated textures, pbuffers are of no particular benefit over rendering to the framebuffer and doing a glCopyTexSubImage2D iff the framebuffer format closely matches the texture internal format, and the framebuffer width and height are greater than the texture subimage being rendered.
As it turns out, there are a number of cases (esp for resizable-windowed apps) where it’s problematic to use the framebuffer for updating textures because you want a guaranteed 512x512 or 1024x1024.
You may also want to update R5G6B5 texture with an RGB8 framebuffer, and creating a pbuffer whose color buffer matches the textuer internal format is the only way to get hardware accelerated updates.
Also, as a special case for shadow maps, you can allocate a pbuffer that has 0 bits for RGBA, and 16 or 24 bits for depth. This not only saves memory, but also memory bandwidth.
I just wanted to chime in from ATI here and say that our next driver release will also support the ‘WGL_ARB_pbuffer’ extension (I think there may be a leaked driver that already has it in, but I’m not sure). In addition, glCopyTexSubImage2D() is accelerated when the pixel format of the pbuffer matches the pixel format of the texture.
nice one guys at the moment im using copytexsubimage and its costing me a 30% drop in framerate (and im not going overboard with it).
all the stuff im using at the moment is only greyscale but at the moment im having to use RGBA (cause thats what the window is) so an 8bit pbuffer looks like the way to go
Could you explain how Radeon’s priority buffers could be used under OpenGL? It seems like pbuffers and SGIX_shadow are right things to use them, but they are not in ICD (well probably pbuffer is already is in)
im using 6.34. 6.5 was not as stable (brought down win2000 both times i ran my game with them). i havent tried the 10.x drivers i notice the unreleased driver versions tend not to support 1152x864 ( which is what i use )