Hello,
I'd like to know if (and in case how) it's possible to distinguish when a texture is loaded in the system memory only and when it's also on the video memory.
In particular I'd like to pre-load a certain (quite big) amount of textures in system memory only, and then selectively send some of them to the video card when needed (removing those unused), making sure I don't run out of video mem.
Is this difference expressed by the unload / remove function of TextureManager class?
not sure about it...
thank a lot
ciaup_ricky
Textures in system / video memory
-
- Gnoblar
- Posts: 6
- Joined: Fri Oct 22, 2004 10:40 am
- Location: Torino - Italy
-
- Gremlin
- Posts: 181
- Joined: Thu Jan 06, 2005 10:19 pm
- Location: Belgium
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Ogre does that for you, excellently. 
I suggest you look into the resource loading systems.

I suggest you look into the resource loading systems.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
-
- Gnome
- Posts: 347
- Joined: Sat Feb 05, 2005 12:56 am
Actually, the graphics driver does this for you, these days. In OpenGL, the driver has always done it. In D3D, when you use MANAGED textures, the driver does it for you.Ogre does that for you, excellently.
The driver knows a LOT more about the hardware that your application will ever do, so delegating this decision there is a good idea. You should just upload all the necessary textures, and the driver will put them in VRAM when it feels it's time.
-
- Gnoblar
- Posts: 6
- Joined: Fri Oct 22, 2004 10:40 am
- Location: Torino - Italy
what you say is correct, but in other applications I've seen that when several textures suddenly have to be changed (in a "LOD way") you can sometimes notice a little hit, when textures are quite large. Of course that depends on the transfer bus bottleneck as well, so I was looking for a way to prevent it.
In this particular application I'll have the same model (geometry) affected by sudden light and ambiance changes, meaning that several 1024x1024 textures might change from one frame to the following. My idea to "pre-load" the textures was to spread this loading process on several frames, so that a sudden change doesn't show any hit, having the new textures already present in video memory.
If I leave the management to the driver (which of course does a good job, as you say), is there a way to "suggest" it to prepare some textures a bit before they're going to be used? As it cannot preview what's happening next in my application, correct?
thanks a lot guys!
In this particular application I'll have the same model (geometry) affected by sudden light and ambiance changes, meaning that several 1024x1024 textures might change from one frame to the following. My idea to "pre-load" the textures was to spread this loading process on several frames, so that a sudden change doesn't show any hit, having the new textures already present in video memory.
If I leave the management to the driver (which of course does a good job, as you say), is there a way to "suggest" it to prepare some textures a bit before they're going to be used? As it cannot preview what's happening next in my application, correct?
Sinbad, do you think that if resident in agp memory, such a sudden texture swap won't hit the framerate?ie a dynamic & discardable texture is held only in AGP memory with no system swap, for efficiency.
thanks a lot guys!
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
Not as much. Dynamic textures (ie those you're updating every frame or similar) are best held in AGP and not managed since they're quicker to update that way (since AGP is accessible by the CPU using via DMA), and aren't software-backed (which implies a write-through). Doing it this way makes Demo_DynTex considerably faster in D3D for example. However the downside is that if the device needs resetting, you have to recover the texture yourself.rickyviking wrote: Sinbad, do you think that if resident in agp memory, such a sudden texture swap won't hit the framerate?
-
- Gnome
- Posts: 347
- Joined: Sat Feb 05, 2005 12:56 am
Because the driver does make these decisions, the best way to hint what you want is to render some geometry with the texture bound. I would suggest turning off Z and color writes, and render a buffer with a single triangle, with that texture bound.
Also, I would expect that drivers can migrate textures as necessary. If a big texture is suddenly needed, it might tell the card to texture out of AGP for the first frame (or few frames) while it purges/compacts VRAM to make space for it. This, taken to extreme, ends up with the 3dlabs virtual texture space solution, where they treat VRAM as a cache for main RAM, and actually have a TLB from the graphics card. The more coherent your working set is, the more VRAM hits you have, and the better throughput you get. Uploading is implcit with usage. This also means that only the MIP levels actually used for a texture will get to VRAM! I'd expect the future to look a lot like this, too.
Also, I would expect that drivers can migrate textures as necessary. If a big texture is suddenly needed, it might tell the card to texture out of AGP for the first frame (or few frames) while it purges/compacts VRAM to make space for it. This, taken to extreme, ends up with the 3dlabs virtual texture space solution, where they treat VRAM as a cache for main RAM, and actually have a TLB from the graphics card. The more coherent your working set is, the more VRAM hits you have, and the better throughput you get. Uploading is implcit with usage. This also means that only the MIP levels actually used for a texture will get to VRAM! I'd expect the future to look a lot like this, too.