Drawing Textures on FBO: Performance

Hi! I have a question regarding how drawing in FBO deal with VRAM and RAM.
Suppose the following scenario: I am drawing textures from video into and FBO and then applying a shader to the FBO.
If I am not worng, as long as I work with textures from the videoclips I am dealing with VRAM
Also, applying shaders will deal with the GPU.
I am slowing the process drawing on a FBO? Where -which memory-is the FBO stored?

Attending to ofFbo description:

At it’s core the ofFBO is a container for textures and an optional depth buffer. Kind of like, well, an OpenGL framebuffer, which is what you’re normally rendering to. One way, conceptually correct but technically a bit loose, is that it’s another renderer that you can write to. You can draw textures to it, draw 3D or 2D objects to it, render the view of cameras inside of it, all with one key difference: it’s just an object stored on the graphics card that repreesents a rendered drawing pass. You can have multiple of them, draw all kinds of things inside of them, and then get all the textures out of them to play with in a shader or just draw them directly to the screen. They are, for most purposes, little render buffers that you can render to and store without needing to be drawing to the screen.

everything should be happening in VRAM, so it should be kind of fast. I am understanding it right?

Thanks a lot for your help!
D!

Hi! Indeed it will be nice and fast. The Fbo will be stored in VRAM.

If you are using an ofVideoPlayer and doing something like:

myFbo.begin();
myVideo.draw(0,0);
myFbo.end();

Then it’s all happening in GPU memory, ofVideoPlayer has behind the scenes uploaded it’s video frame into a texture in GPU memory so that you can draw it. Not the fastest thing in the (graphic card) world but nothing you need to worry about unless you are uploading loads and loads of stuff to video memory every frame, then once it’s there it will be very fast to draw onto an Fbo.

Thanks a lot for your answer hahakid!
I am using ofxHapPlayer instead of ofVideoPlayer in order to speed up and move the graphic card the decodification.
I am playing several clips at the same time -around 20- and then applying a shader to the whole thing. So I have something like this:

ofTexture tex[20];
ofxHapPlayer players[20];
//in update();
for (int i=0; i<20; i++){
    tex[i] = video[i].getTexture(); //it doesn't work like getTextureReference() in ofVideoPlayer
}
//in draw();
fbo.begin();
for (int i=0; i<20; i++){
    tex[i].draw(0,0);
}
fbo.end();

shader.begin();
fbo.draw(0,0);
shader.end();

I am not sure of using memory in the best possible fashion. I am open to any suggestion!

My question: do I really need to go through the texture or can I draw it directly without messing with “other” memories?
I guess the answer depends on how ofxHapPlayer is implemented, but assuming it is like ofVideoPlayer, attending to your comment, I should not go through texture, right?

Best,
Diego

Hi, yeah no need to grab the texture first, just use the draw function of the video player, it will do the same thing.

One gotcha with ofxHapPlayer might be that it uses a shader in draw to do some conversion ( https://github.com/bangnoise/ofxHapPlayer/blob/master/src/ofxHapPlayer.cpp#L562) so something like this won’t work as myShader won’t be used:

myShader.begin();
   myFbo.begin();
      videoPlayer.draw(0,0);
   myFbo.end();
myShader.end();

But something like this should do the trick:

 mySrcFbo.begin();
    videoPlayer.draw(0,0);
 mySrcFbo.end();


myShader.begin();
   myDestFbo.begin();
      mySrcFbo.draw(0,0);
   myDestFbo.end();
myShader.end();

Men, you know your thing :wink:
Thanks for the points, I will give you feedback asap :smile:
Best,
Diego