# Copying texture/buffer data

This topic is 4172 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi, I have a problem with FBO's. In part of my rendering stage, I render everything to a texture. First I do the opaque stuff, then the transparent stuff. Before I start with the transparent stuff, I need a screen capture. I use that captured texture for effects like water, deformations, glass, and so on. Normally I use "glCopyTexSubImage2D" for that, but it seems that this function is extremely slow when the FBO is active (somebody knows why?). So, I simply used the "target texture" (where everything is rendered on) also as an input texture for some of the transparent objects. This works, but with artifacts (dots, weird lines). I think this is because I use the same texture both as input and output. So I need a copy of that FBO texture. glCopyTexSubImage2D is way too slow (unless I'm doing something competely wrong), so I need another way. One possibility would be by "switching" the render target texture:
  targetTex = Texture where normally everything gets rendered on
copyTex   = A copy of targetTex, used as input for transparent stuff

1- Render all opaque stuff on "targetTex"
2- Set the FBO render target to "copyTex", instead if "targetTex"
3- Render a screen filling quad where "targetTex" is placed on
4- CopyTex now has a copy of targetTex
5- Switch the FBO render target back to "targetTex"
6- Render transparent stuff with "copyTex" as input

I think this works... But isn't there a faster way? Now I need a pass between and render a quad that fills the entire screen. It's a simple pass though, but maybe it can be done smarter. Rick

##### Share on other sites
I am going out on a limb here and saying look at PBOs. Ask Phantom he is the man for questions on PBOs. :)

##### Share on other sites
PBO's... That's new for me :) I quickly readed a little bit info. As far as I understand now, PBO's are used to quickly read pixel data, right?

I use FBO's for rendering in the background. In my case I render to a floating point texture for HDR (in the end, this FBO texture is rendered to the normal output buffer with tonemapping). I also use it for making a "depth" texture for the DoF effect. In both cases, I also use "glReadPixels" for measuring average pixel values (luminance), or getting the depth at the center of the screen. I know glReadPixels isn't really fast, although I only read a few pixels. And now I also need a copy of the FBO texture, before I render transparent things that use this copy for refraction effects.

Should I do this background stuff on a PBO instead of a FBO? Or is is possible to "connect" the FBO to a PBO so that I can read the pixels quickly? And when I have my copy of the screen content in a PBO, how to use it (as a texture?) in my shaders that use refraction?

Maybe some of the questions are stupid, but I'm trying to understand how the PBO is used, since its completely new for me.

Thanks for helping,
Rick

##### Share on other sites
http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial3.html

##### Share on other sites
PBO's is not the solution. PBO is like VBO, but you can render to it and then use it as a VBO. You probably know it better as "render to vertex array" == RTVA

Back to the first post :
Do not render to a texture and sample it at the same time
and looks like you have the right idea
There is another extension for FBO blitting. I've never tried it.

##### Share on other sites
Thanks everyone!

But I'm a little bit confused now. Some say I should go for the PBO's, others say I shouldn't. From what I understand, PBO's can give fast access to pixel data, since its a direct link. And operations such as "glCopyTex" are using a similiar approach as well, if I'm right.

But V-man says I'd be better off not using PBO's. So, that means in my case I just render the scene to another FBO(texture), before doing my transparent stuff, and then switch back to the other FBO. Which basically means I do an extra pass between. Not a difficult one though, I just render a quad with a (floating point) texture on it.

greetings,
Rick

##### Share on other sites
The FBO blitting extension is currently only supported on G80 based cards afaik and isn't really an option here (I'm also pretty sure it's only for copying between areas of a framebuffer).

Define 'slow' when it comes to glCopyTexSubImage2D?

- Perform all your rendering to one texture and then re-render into another with a single quad thus giving you a copy
- Render to two textures at once using MRT, thus generating two copies of the data.

Personally, I'd take the first option, as the overhead of doing what is in effect a fast copy will probably out weight the bandwidth loss from trying to MRT (plus I'm pretty sure that'll require modifications of any shaders being used).

btw, PBOs aren't the solution here at all, while they do have more uses than RTVA this isn't one of them. Poor poor misunderstood extension [sad]

##### Share on other sites
>> Define 'slow' when it comes to glCopyTexSubImage2D?
With no FBO's, it's just fast. When a FBO is enabled (all the output is going to a 16F texture, and the snapshot is also taken from that texture), my framerate drops from 60 to 10 or something. Something really isn't going very well.

>> Perform all your rendering to one texture and then re-render into another with a single quad thus giving you a copy

I was indeed thinking about that. But I was wondering is there were faster methods. Therefore PBO's were suggested.

Everybody thanks for helping,
Rick

1. 1
2. 2
3. 3
Rutin
18
4. 4
JoeJ
14
5. 5

• 14
• 10
• 23
• 9
• 32
• ### Forum Statistics

• Total Topics
632631
• Total Posts
3007532
• ### Who's Online (See full list)

There are no registered users currently online

×