PDA

View Full Version : Using only video memory for textures...



Mark Shaxted
08-18-2007, 03:24 AM
I need to render textures in a 2D application, but I only want them to reside in video memory. How can I go about doing this?

For example, I assume FBO's are only stored in vidmem, as are PBO's (?). Are there any other options for older cards? What about pBuffers?

Many thanks

Zengar
08-18-2007, 07:45 AM
It is not possible. The driver will put textures where it finds appropriate to ensure the best performance. You could try glPrioritizeTextures though...

Why do you want them all to be in video memory anyway?

Mark Shaxted
08-18-2007, 10:05 AM
Thanks Zengar

Basically, It's an image viewer, with thumbnails broken down as follows...

64x64 pre-compressed @ 8:1 (2Kb) for fast viewing - stored in vid+sys mem as gl textures
300x200 jpeg of thumbnail (~20Kb) stored in sys ram - which are expanded on demand into...
300x200 gl textures - hopefully 'ONLY' in vidmem

The idea is that thousands of 64x64 textures are loaded into the system, which will be fast to transfer onto the card for fast viewing, and then the full quality jpegs will be decompressed on demand into vidmem.

I was hoping that maybe pBuffers (for example on older cards) or FBO's (on newer cards) are 'ONLY' stored in vidmem to maximise available system ram - the compressed textures in ram take an average of 22Kb, and decompressed ~234Kb.

In other words, I'd like to consider video memory as an extension of system ram - not a duplicate.

I understand that video ram is meant as a fast cache - but it's seems really dumb that it's not easy to actually use it in it's own right...!

Jengu
08-20-2007, 09:44 AM
The driver will probably do a much better job than you at determining if something should go into VRAM. But, you can ensure that something is not in VRAM by not uploading it as a texture. For your purposes I would consider uploaded as texture to mean in VRAM, and not uploaded (or uploaded then deleted) to mean not in VRAM. Most drivers I think will use up all VRAM first, then go for system memory, then swap so that should be close to the desired behavior.

Also, unless you've actually tried coding this, you're prematurely optimizing anyway.