Sign in to follow this  
popsoftheyear

Texture memory management

Recommended Posts

Not sure if this is the right place to post this...but... Generally, how is texture memory management done these days? Say, for a game where levels are loaded 1 at a time (as opposed to implementing some sort of fluid transition between "areas"). I realize that this is a very broad question, but what is the norm, if there is one? Does one load all the textures for the level into RAM, and then swapped in/out of VRAM when needed? Is everything loaded into VRAM at once for a given level? Does it stay on disk and get swapped into VRAM when needed? I guess I'm trying to figure out a couple key points. Is everything pre-loaded? Either way, is there a CPU RAM mid-step (essentially having 2 copies of a texture in memory...at least from my current viewpoint)? If there is no clear cut answer, what are the most common factors that determine what the answers are? I haven't coded a 3d engine of any sorts in a few years and I sure haven't owned a modern gfx card since the voodoo3 (it was modern when I got it...), so if the questions are too broad, just let me know how much more specific I need to be or what else needs included to narrow it down. Thanks! Cheers -Scott

Share this post


Link to post
Share on other sites
Quote:
Original post by popsoftheyear
Not sure if this is the right place to post this...but... Generally, how is texture memory management done these days? Say, for a game where levels are loaded 1 at a time (as opposed to implementing some sort of fluid transition between "areas"). I realize that this is a very broad question, but what is the norm, if there is one? Does one load all the textures for the level into RAM, and then swapped in/out of VRAM when needed? Is everything loaded into VRAM at once for a given level? Does it stay on disk and get swapped into VRAM when needed?
It depends. If the level is smallish, then usually all the textures are loaded into RAM. If it's a larger level, then textures are often loaded in the background to keep RAM usage down.

If you're using D3D, then it'll handle the RAM -> VRAM transfer for you if you use the managed pool (Which you should use all the time when possible). I don't know about OpenGL, I assume you need to do that yourself.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Quote:
Original post by popsoftheyear
Not sure if this is the right place to post this...but... Generally, how is texture memory management done these days? Say, for a game where levels are loaded 1 at a time (as opposed to implementing some sort of fluid transition between "areas"). I realize that this is a very broad question, but what is the norm, if there is one? Does one load all the textures for the level into RAM, and then swapped in/out of VRAM when needed? Is everything loaded into VRAM at once for a given level? Does it stay on disk and get swapped into VRAM when needed?
It depends. If the level is smallish, then usually all the textures are loaded into RAM. If it's a larger level, then textures are often loaded in the background to keep RAM usage down.

If you're using D3D, then it'll handle the RAM -> VRAM transfer for you if you use the managed pool (Which you should use all the time when possible). I don't know about OpenGL, I assume you need to do that yourself.

Actually, OpenGL always handles this for *all* textures. In general, you load your textures into OpenGL, and the driver decides on the fly when to swap them in and out of VRAM. You can provide hints on how you want individual textures to be handled, but I don't see that used very often, as the driver does a pretty nice job.

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Actually, OpenGL always handles this for *all* textures. In general, you load your textures into OpenGL, and the driver decides on the fly when to swap them in and out of VRAM. You can provide hints on how you want individual textures to be handled, but I don't see that used very often, as the driver does a pretty nice job.
Interesting. It's pretty much the same in D3D; you only tend to use the default ("please put me in video memory") pool when you have to (Render targets and dynamic resources for instance have to be created in the default pool). You'd never want to put everything into the default pool and then manage the vram yourself.

Share this post


Link to post
Share on other sites
You typically load all your textures in once.
In D3D you load them into the managed pool and D3D will move textures to the VRAM whilst keeping a shadow copy on the system RAM.
OpenGL does this anyway, there is no default pool as such.
Render targets in OpenGL are handled through a different API to normal textures and are possibly more akin to belonging in D3D's default pool concept.

If you had very large or many, many textures then you will have to take some control and start unloading textures from RAM/VRAM and move them too/from the hard-drive. Having many many textures would really be equivalent to the fluid streaming approach. Having very large textures is somewhat similar to Carmacks virtualised mega-textures. Both of which are more complex systems than the drivers/API can provide.

For a classic one level loaded at a time approach you can safely just upload all your textures at load-time and leave it to the drivers/API to manage them for you [smile]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this