Since nobody’s started a thread on it, I guess I will.
EXT_render_target, coupled with PBO, gives you 70-90 percent of the important functionality of the superbuffers extension. Which, therefore, makes superbuffers superfluous and unnecessary.
So, basically, we’re being asked to choose between PBO/EXT_render_target and superbuffers. Well, I’d choose PBO/EXT_render_target simply because I have extension specs I can read, and I don’t for superbuffers. It’s hard to compare two things when you can’t gain access to the alternative.
One thing that concerns me about the extension is issue #3: the requirement that all buffers in the texture drawable be the same size. It would be a really nice if this weren’t the case. If there is to be a separate extension to relax this, it should be available alongside EXT_render_target.
I, in particularly, like the way that the idea of a drawable object type is neatly ducked by using the state-based mechanism. This allows actual users to decide if objects are needed, and if they are, another extension can be provided. Although I’m don’t know if I entirely agree with the rationalle for not providing objects.
Should there be N MRT-style depth textures?
I would think no. To do so, the MRT shader would also need to have a depth value for each render target, which neither glslang nor the multiple-render-target extension to ARB_fp does. In general, when you start getting into MRT-like functionality, you’re going to be willing to create your own depth-like texture (as a luminance 32-bit fp or something like that) and do the comparison in the fragment program. As such, having, explicitly, multiple depth textures is not necessary.
Why is it that various commands to set the current render target state are not stored in display lists?