Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Any estimation for FBO memory consumption?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 RPTD   Members   -  Reputation: 316

Like
0Likes
Like

Posted 08 April 2012 - 03:36 PM

This question might sound a bit strange but seeing on how switching multiple FBOs perform faster than using one and switching attachments I could not get around wondering how much memory an FBO roughly consumes? I don't mean now the attachments as these I can calculate already. I could not find any information on what kind of memory consumption one should expect from creating holding a configurated FBO. Any ideas?
Life's like a Hydra... cut off one problem just to have two more popping out.
Leader and Coder: Project Epsylon | Drag[en]gine Game Engine

Sponsor:

#2 Yours3!f   Members   -  Reputation: 1385

Like
0Likes
Like

Posted 09 April 2012 - 05:47 AM

I checked my app with gDEBugger, and it showed that 3 FBOs consume less than 1KB memory --> insignificant. The attachments however consume 4 * 3.6 = 14.4MB @ 720p

#3 RobinsonUK   Members   -  Reputation: 108

Like
0Likes
Like

Posted 09 April 2012 - 05:54 AM

Sounds about right. Did you work out whether switching FBO was faster than switching attachments? I'm curious to know.

#4 RPTD   Members   -  Reputation: 316

Like
0Likes
Like

Posted 09 April 2012 - 06:59 AM

Yeah, I did tests with a HW occlusion testing method I made recently (no occ-queries, a HZB oriented method but my own style). For creating the mip-map levels I used once a method where I use one FBO and switching the attachments around and one where I use one FBO for each mip-map level and switching those. The difference had been up to 1ms faster with the FBO switching version depending on the situation. That's though on ATI on Linux. I plan to switch everything now to individual FBOs to gain these speed improvements on various places. I estimate that I can end up with 50+ FBOs that way hence I wanted to see if I would get memory wise into troubles with the already tight GPU memory at hand. Could back-fire on me though as on Windows if I remember correctly switching FBOs is horribly slow compared to switching attachment points.
Life's like a Hydra... cut off one problem just to have two more popping out.
Leader and Coder: Project Epsylon | Drag[en]gine Game Engine

#5 samoth   Crossbones+   -  Reputation: 4932

Like
0Likes
Like

Posted 09 April 2012 - 10:01 AM

Sounds about right. Did you work out whether switching FBO was faster than switching attachments? I'm curious to know.

There is actually no way it could be any different.

When you bind a different FBO, the driver internally does something like the equivalent of changing a pointer. When you switch attachments, the FBO is in an unknown/undefined state. The driver must run a number of checks on both the attachment and the FBO (render target size, bit depth, framebuffer completeness, and what not). What's worst, it has little choice to defer those checks and batch them together.

If a FBO is not bound, the driver can, as an optimization, choose to do the completeness check no earlier than either you ask for completeness or attempt to bind it. If it is bound already, the driver must do the check every single time you touch an attachment.

#6 RPTD   Members   -  Reputation: 316

Like
0Likes
Like

Posted 09 April 2012 - 10:39 AM

Sounds about right. Did you work out whether switching FBO was faster than switching attachments? I'm curious to know.

There is actually no way it could be any different.

When you bind a different FBO, the driver internally does something like the equivalent of changing a pointer. When you switch attachments, the FBO is in an unknown/undefined state. The driver must run a number of checks on both the attachment and the FBO (render target size, bit depth, framebuffer completeness, and what not). What's worst, it has little choice to defer those checks and batch them together.

If a FBO is not bound, the driver can, as an optimization, choose to do the completeness check no earlier than either you ask for completeness or attempt to bind it. If it is bound already, the driver must do the check every single time you touch an attachment.

1ms difference sounds to me though like quite a large difference to begin with.

EDIT: Besides you can't change attachments on an FBO if it is not bound so it is not possible to optimized the attachment process of an FBO if it is not bound.
Life's like a Hydra... cut off one problem just to have two more popping out.
Leader and Coder: Project Epsylon | Drag[en]gine Game Engine




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS