pouët.net

well, i've tried a lot of approaches to reading the framebuffer (actually, just interested in the colorbuffer) to do things like "invert colors" and the like, using ReadPixels really hits the performance. Pbuffers are faster, but not that fast anyway... anything bigger than 192*128 get's really slow. most prods i've seen doing stuff like that are using direct3d and not opengl. But, since I'm (finally) dropping TNT2 support in my next production I'd like to know if anyone could share their trick to read from the color buffer in opengl and tell what is their target hardware.

render to texture and try to do it without the CPU. Come on, "Invert colors" needs exactly ONE alphablended polygon ;)

yeh, i was about to write the same as kb :-) inverting colors isn't exactly the hardest task

For fusks sake. invert, as pointed out by others is just an overlay. other stuff, you just do a copyteximage of the framebuffer and then bind the copied texture again to do the stuff on the gpu. texture rectangles are useful if you want to save gpu mem. pbuffers are a slight speed improvement, but they are a bit awkward to work with (not to mention that you tend to waste a lot of gpu mem for additional zs buffers). do not do readbacks. it's slow and it stalls.
btw. i didn't check yet, but is there a nice and easy to use copyteximage/copytexsubimage equivalent in dx?

"invert colors" was just an example, is not what i have in mind, ok, let's change that to old fashion motion blur or a dynamic cubemap texture or _whatever_ effect you cant think of that needs to read pixels already rendered... i was asking about reading the framebuffer at reasonable speed, not how to do an "invert colors" effect. if the "trick" is to not use the CPU at all (as to avoid the agpmem->conv_mem->process_pixels_in_conv_mem->back_to_agpmem penaty) that's enough answer for me. I was hoping there was a (faster) way to process raw pixels getting them from the framebuffer and putting them back after processing in the CPU.

So, the answer to your initial post was actually "pixel shaders" ...

shiva: there's no exact equivalent (StretchRect probably comes closest), but multiple render target support is great, so why bother?

I was trying to avoid pixelshaders at first, but as pointed out seems to be the best choice. The problem is that nvidia drivers don't support GLslang yet. cg is nvidia only (i think). and prefer not to write them in asm because I only have a gf4-4600 card, no ATIs to develop/test on. So that pretty much leaves me a few choices:

a) write for nvidia only
b) wait some undefined ammount of time until GLslang is implemented in nvidia drivers.
c) use direct3d

any advice?

c)

panoramix: ARB Fragmentprograms etc .. supported by both nVidia and ATI AFAIK.

Also, *blur is doable with some smart layer handling 100% on gpu, prety much all effects can be done somehow on the gpu, if you go accel, go for accel for real, readbacks is just an insane idea.