It appears the frame buffer gets clipped at screen size and glReadPixels() only gains access to the part that is actually rastered. I'd like to draw a huge (4096x4096 or even larger, if possible) image in the frame buffer and copy it into RAM. I don't care if I need to read it into some texture in VRAM first (as long as there's no data loss), although I don't think too many graphics cards support that large textures, but I'm not so sure how to go about it (or even if it's possible to render something that large, especially on older hardware). If it's not possible, I'll probably have to do it the (rather) hard way: render by chunks... sigh...

I doubt that many software renderers even support textures that large.

That is not a job for your video card. You'll probably have to split it, I don't see how you could do it any other way... unless there's an extension that allows huge textures...

I don't know whether pbuffers have a size limit, but anything over a GF3 has 4096x4096 texture support...

Different options:

1) render the large image part by part, adjusting the view frustum and reading back each tile separately. In a postprocess, you stich all parts together to form the final image. This method can produce virtually infinite resolution images.

2) Instead of rendering to the framebuffer, create a large pbuffer, render to it, and read it back from there. This method will decouple your image size from the frame buffer size. But it's limited by the cards capabilities and the amount of available VRAM.

3) Use a software implementation. Mesa can support very large images when rendering to a memory buffer.

BTW, most modern cards support 4096*4096 textures. They take a lot of VRAM, but they're supported.