 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| How to get Texture Memory Size |
|
 |
stelabouras Member since: 4/14/2004 From: Thessaloniki, Greece |
|||
 Posted - 10/20/2007 9:13:02 AM |
||||
| Hello everyone! Is there a way in OpenGl to get the size of Texture Memory in order to watch if it's 50% full and then free some texture objects? Thanks in advance for your answers! |
||||
|
||||
|
V-man Member since: 3/2/2002 From: Montreal, Canada |
|||
|
Posted - 10/20/2007 9:31:55 AM |
||||
| I did a search and this is one of the links. There is plenty of them! http://www.gamedev.net/community/forums/topic.asp?topic_id=451658&whichpage=1� |
||||
|
||||
|
swiftcoder Member since: 7/3/2003 From: Boston, MA, United States |
|||
|
Posted - 10/20/2007 9:43:39 AM |
||||
| Short answer is that you don't need to. Presumably you already free textures when you are done with them, right? If you exceed the amount of available video memory, OpenGL will automagically handle paging from main memory - and it does a very good job. Don't second-guess the driver unless you have a very good reason. |
||||
|
||||
|
stelabouras Member since: 4/14/2004 From: Thessaloniki, Greece |
|||
|
Posted - 10/20/2007 10:19:35 AM |
||||
| @V-man I found only workaround for DirectX and not for OpenGL..Have you seen any relevant answers for Opengl programs? @swiftcoder You are right although I want to know if it's feasible! Is there any function to easily enumerate Texture memory? |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 10/20/2007 11:02:30 AM |
||||
Quote: There are always workarounds, but they come with significant implications on many aspects of your engine. You essentially have to completely change the way you do texturing (eg. by using clipmaps or megatextures), and this again comes with a lot of highly complex issues and is an advanced topic. In 99.9% of all cases, doing manual texture memory management is not needed, and may even backfire badly if you're not experienced enough. Quote: No, there isn't. |
||||
|
||||
|
stelabouras Member since: 4/14/2004 From: Thessaloniki, Greece |
|||
|
Posted - 10/20/2007 11:33:19 AM |
||||
| Oh thanks a lot Yann L! My engine's approach to texturing is quite different from clipmaps or megatexture techniques, so I will rather relay on Opengl when it comes to texture managment. On the other hand, I would really want to have full control of this aspect (for texturing very large scale terrains) as I just load only the textures visible to the camera and delete all the others. As the whole project is academic (and maybe ready for a paper), I can't say more concerning those techniques. Thanks again everyone! |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 10/20/2007 12:13:15 PM |
||||
Quote: You should not do that. The memory management subsystems of most OpenGL implementations are not designed to deal with constant texture creations and deletions during rendering. Doing it can create a wide range of problems going from bad performance to extreme memory fragmentation (which again can cause out of memory errors or extreme performance drops on 'locked' resources such as FBOs). Instead, you should keep created textures in a cache (garbage collecting only occasionally or not at all) and recycling them by updating the texture image data using PBOs (if you stream in content) or FBOs (if you procedurally generate content). That's essentially the way clipmaps work. |
||||
|
||||
|
V-man Member since: 3/2/2002 From: Montreal, Canada |
|||
|
Posted - 10/22/2007 5:15:46 AM |
||||
| I forgot about this one. You can get the total video memory from the registry but the problem is that it's not the same place for all video cards. For some cards/drivers, it might not even present. Vendors have always refused to make extensions for this information. I think they fear developers will do dumb things. |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 10/22/2007 7:47:42 AM |
||||
Quote: And it doesn't mean anything. VRAM is a shared resource, you have no idea about how much is taken by framebuffers (the internal formats are not exposed), by shaders, by vertex and face data, etc. Also keep in mind, that your game isn't the only process using VRAM. Even Windows itself uses VRAM for the UI, especially Vista is running havok on video memory usage. So knowing the total amount of VRAM on the card won't help you at all. You'd need to actually hook into the entire systems video memory management in order to get meaningful results - which would amount to writing your own video driver (and besides, these hooks are obviously not exposed, since they're trade secrets). Quote: And since Vista, it has become more or less impossible to reliably provide this information to the developer. |
||||
|
||||
 |
phantom Moderator Member since: 12/15/2001 From: Ipswich, United Kingdom |
|||
 Posted - 10/22/2007 9:27:08 AM |
||||
| Strangely, the AMD/ATI Vista OpenGL driver DOES have an extension which allows you to query the total pool available, largest pool available, total aux pool and largest aux pool available for VBO, texture and renderbuffer memory types. That said, the values are conservative values and not exact information so I wouldn't use it personally for anything precise (at best I might have used it for detail level guess on startup). |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 10/22/2007 3:44:00 PM |
||||
Quote: How does this work with MT resource management ? Eg, what happens if you ask for available memory, and between the size query and you actually requesting the memory area, some other thread/process/Aero decides to allocate some large chunk of memory ? This looks a little risky to me. |
||||
|
||||
|
V-man Member since: 3/2/2002 From: Montreal, Canada |
|||
|
Posted - 10/22/2007 8:34:48 PM |
||||
Quote: Finding the VRAM size from the registry can give you an idea of what is available. The problem is that vendors haven't made an extension available but can't blame because I think the OS makes things complicated and they don't want to put that kind of feature in a GL driver. Windows doesn't have anything in it's API. DirectDraw offers a solutions but... Windows has functions for getting physical RAM, cpu name, and a bunch of system information. Quote: So what's it called and how to use it? |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
