I was just wondering how much texture memory I have available in an application I’m developing, and I started trying to work it out. Does the following look right?
I have 8MB VRAM, OpenGL context is 1024x768@16bpp, double-buffered, no depth, alpha or stencil.
So the frame buffer is taking up: 1024 * 768 * 2 [16bpp/8 bits in a byte] * 2 [two buffers] = 3MB.
So (roughly speaking) I have about 5MB available for textures, right?
It’s a tile-based app using 32x32 pixel tiles. For argument’s sake, I’ll use 256x256 pixel textures. They can hold 8x8 tiles = 64 tiles. I’ll need several of these.
So, 256x256 pixel textures in GL_RGBA format. Those textures each take up 256 * 256 * 1 [one byte per pixel component] * 4 [four pixel components] = 256KB.
So I can have up to 20 of these! Does that sound right? Is the math correct, are my assumptions correct, and have I missed anything out?
Now, what eats away at this? A 16-bit depth buffer will require another 1.5MB. Display lists will use another unspecified amount. Server-side vertex caches etc will do, too.
Your maths is right, though your assumptions about limits and vram are not.
Infact worrying about it, is fairly pointless IMO (except when coding consoles). In openGL a texture is ‘resident’ if it is stored in the graphics card memory, and non-resident if it is in system memory. You can query if a texture is resident (glAreTexturesResident()), and you can also assign higher prioities to textures so that they will be made resident before other textures of a lower prioity; you cannot however force a texture to be resident. Put simply openGL will decide where to put textures, you can help it make better descisions, but you can’t control it.
Anyhow, essentually if a texture cannot be stored in VRAM, then it will most likely end up in your main memory. Access to that texture will be slower than if it’s in VRAM, but it’s not horrifically slow. If you run out of system memory then you fall into virtual memory and the data will be swapped out to your hard drive which is horrifically slow…
Basically, the answer is NO, 8Mb VRam is not enough to store all of your textures; but it really doesn’t matter because OpenGL is clever(ish)…
Anyway, who cares, it’s summer and there’s a heat wave…
[This message has been edited by Rob The Bloke (edited 08-10-2003).]
Hi Rob, thanks for the response.
Excellent, so the math is right - phew! That gives me an idea of the right kind of size to work with - with a sufficient overhead of course. I think I’ll go with four 512x512 textures for the first cut.
(Sorry, I should have mentioned I get how OpenGL handles the textures - I was just trying to get a rough idea on how much I can use without resorting to system memory or causing texture thrashing.)
And yes, what a Summer!
Remember to call delete after you called TexImage. It was non-obvious to me when I was moving the first steps into texturing.