OpenGL "Duplicating"

Quote:
Can I somehow show the same part of a GL scene in two different places?

Not without rendering your scene multiple times per frame --- the GL Scissor patch (part of Kineme GLTools) might be helpful in clipping the subviews.

Are you really so fillrate/vram limited that RII isn't available? If that's the case, then as @smokris (#loltwitterofftwitter #deadsyntax) said you'll have to re-render the scene (or parts of the scene). If you've got any overdraw whatsoever, this approach might burn more fillrate than RII would.

Alternatively, you could use a geometry shader to duplicate input geometry to multiple locations, but you'd have to do a lot of custom work to get that up and running.

Yes, I'm curious about that too. Unless there's not much in the scene, re-rendering part of it is likely to be at least as expensive as RII.

I see.

I was hoping that GL could somehow show a copy of the space without rendering from scratch.

It annoyes me that I have to render pixels and crop stuff – only becaurse of the damn overlap. All moving around and masking can be done in GL with ease, but the overlap apparently HAS to be rendered.

Thank you for the replies.

Of course it has to be rendered, you can't show something without rendering it. And RII is the standard way of duplicating an image, it sounds like this is exactly what you want. It works like this:

1. You render the scene once, but to an texture rather than the screen. (This is what RII does.)
2. You draw that texture to the scene twice, to get your overlapping areas. You're not rendering the scene here, just a single textured rectangle. It's very fast.

The only time you'd have a possible problem with that is if you're rendering at super high resolution, and the GPU just doesn't have any time left after rendering the scene once. In that case you're screwed anyway, and you need to look at some other solution (like lower res, optimising the actual scene, or buying a faster GPU).

Not necessarily faster, but also potentially with more vram -- the GPU can trivially purge a lot of texture data (static textures that are backed by system memory can be thrown away from the GPU for "free" because they don't need to be paged off), but render-to-texture operations create volatile vram stuff that can't be discarded freely - it needs to be paged (because it's not backed by system memory). paging on/off is woefully expensive (particularly the off part, but the on part isn't great either). It's quite possible enough volatile textures are in flight that adding more (via RII) will cause paging. [this is a current problem I'm dealing with at work for some demos, incidentally]

The other nicety about using RII is that your vertex emission cost is very low for RII (another quad), and RII's output can potentially be cheaper in terms of texel fetches (unless you're using un-textured geometry).

It'd be great to hear the rationale behind the constraints; otherwise we're just guessing, and that's not particularly useful :)