Textures in system / video memory

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
rickyviking
Gnoblar
Posts: 6
Joined: Fri Oct 22, 2004 10:40 am
Location: Torino - Italy

Textures in system / video memory

Post by rickyviking »

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
User avatar
LordMyth
Gremlin
Posts: 181
Joined: Thu Jan 06, 2005 10:19 pm
Location: Belgium

Post by LordMyth »

I think it is possible, but you probably will have to get into API specific code, as I THINK it's not implemented in OGRE...
Have a kiss from me!
Gentoo Linux on AMD64 3200+
NForce4 Chipset
Dual Channel DDR 2x512MB
PCX 16 GeForce 6600 256MB
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179

Post by jacmoe »

Ogre does that for you, excellently. :)
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.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

Leave this to the driver. GL and D3D do good jobs of organising efficient usage of the GPU / AGP / system memory. We only influence it when you specify your 'usage' options - ie a dynamic & discardable texture is held only in AGP memory with no system swap, for efficiency.
User avatar
jwatte
Gnome
Posts: 347
Joined: Sat Feb 05, 2005 12:56 am

Post by jwatte »

Ogre does that for you, excellently.
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.

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.
rickyviking
Gnoblar
Posts: 6
Joined: Fri Oct 22, 2004 10:40 am
Location: Torino - Italy

Post by rickyviking »

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?
ie a dynamic & discardable texture is held only in AGP memory with no system swap, for efficiency.
Sinbad, do you think that if resident in agp memory, such a sudden texture swap won't hit the framerate?

thanks a lot guys!
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

rickyviking wrote: Sinbad, do you think that if resident in agp memory, such a sudden texture swap won't hit the framerate?
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.
User avatar
jwatte
Gnome
Posts: 347
Joined: Sat Feb 05, 2005 12:56 am

Post by jwatte »

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.