Texture sizes and VRAM
by Vern Jensen · in Torque Game Builder · 10/06/2007 (12:14 pm) · 12 replies
I have one sprite I'm adding to my shooter that is 7856 by 337 pixels in size. (337 pixels each way, 16 frames). It's a large dragon. If my calculations are correct, this will take up about 10 MB of VRAM. There will be a few other large sprites in the scene at the same time, for perhaps 20-30MB VRAM in all.
I'm curious if this is just beyond the realm of reason in terms of what graphics cards are out there. I'm not too familiar with what most cards come with in terms of VRAM. Also, what does Torque do if the textures loaded and used in a level won't fit in the card's VRAM? Run much slower? Not display anything?
I'm curious if this is just beyond the realm of reason in terms of what graphics cards are out there. I'm not too familiar with what most cards come with in terms of VRAM. Also, what does Torque do if the textures loaded and used in a level won't fit in the card's VRAM? Run much slower? Not display anything?
#2
10/08/2007 (10:49 am)
I guess I'm curious what older cards come with. So if I aim for, say, 32 MB minimum VRAM, what years I'm aiming for in terms of older computer models, in general. 
#3
10/16/2007 (10:53 am)
Its there any kinda conversion formula, where you could calculate how much VRAM will certain art sheet eat up?... cuz, im havin a memory problem with my game, and im feeling theres a resource hog somewhere but cant just detect it... basically, as explained in another post, torque its eating up up to 900MB of ram, and i havent even loaded the whole art assets i need on that particulr project!!!
#4
In Millions of colors, each pixel takes 4 bytes. So multiple your image size by 4. For instance, if I have a 512x512 texture, I do:
512x512x4 = 1048576 bytes
There are 1024 bytes in a Kilobyte, so divide by 1024
That gives us 1024 K, or about 1 Megabyte.
I'm not sure how alpha channels are stored, so I might not be taking into account an additional source of memory consumption. Also, lots of VRAM can be wasted when you load textures that are not an even power of 2. So you need to try to take that into account as well. (For instance, if you load a 512x364 texture, it gets padded ot 512x512.) Note also that if you load a 512x512 texture, and have padding on, that will make it LARGER than 512x512 by several pixels (depending on how many frames are in it), so it will get padded up to 1024x1024.
Feel free to correct me (anyone) if there is a better way of calculating this stuff. This is just what I came up with on my own, and isn't based on too much actual knowledge of VRAM, etc.
A tip I saw in a forum for a similar post as yours (600MB of RAM) was that someone suggested to allow unloading of media after levels. There's a checkbox for that in the Torque editor for each image you load.
10/16/2007 (11:08 am)
I generally do this, which may or may not be correct.In Millions of colors, each pixel takes 4 bytes. So multiple your image size by 4. For instance, if I have a 512x512 texture, I do:
512x512x4 = 1048576 bytes
There are 1024 bytes in a Kilobyte, so divide by 1024
That gives us 1024 K, or about 1 Megabyte.
I'm not sure how alpha channels are stored, so I might not be taking into account an additional source of memory consumption. Also, lots of VRAM can be wasted when you load textures that are not an even power of 2. So you need to try to take that into account as well. (For instance, if you load a 512x364 texture, it gets padded ot 512x512.) Note also that if you load a 512x512 texture, and have padding on, that will make it LARGER than 512x512 by several pixels (depending on how many frames are in it), so it will get padded up to 1024x1024.
Feel free to correct me (anyone) if there is a better way of calculating this stuff. This is just what I came up with on my own, and isn't based on too much actual knowledge of VRAM, etc.
A tip I saw in a forum for a similar post as yours (600MB of RAM) was that someone suggested to allow unloading of media after levels. There's a checkbox for that in the Torque editor for each image you load.
#5
8192x512
4096x256
2048x128
1024x64
512x32
256x16
128x8
64x4
32x2
16x1
8x1
4x1
2x1
1x1
If your image has alpha in it, each pixel is 4 bytes wide. If your image does not have alpha in it, each pixel is still probably 4 bytes wide due to cache alignment.
In laymans terms, it's using a metric-assload of memory, which is entirely unnecessary. A texture size of 7856x337 is foolish.
Simply summing up those values doesn't give an accurate representation of how the memory is used, either. This is an example, mipmapped image, from Wikipedia:
You may be tempted to turn off mipmapping, however processing a texture of that size is going to kill fill-rate on any object which uses it.
10/16/2007 (11:27 am)
7856x337 will get rounded up to the next power of two by the drivers/hardware, most likely. You will end up with an image that is 8192x512. It will then mipmap the image, if mipmapping is turned on. This will downsample, on powers-of-two, until it gets to 1x1. So when you upload a 7856x337, mipmapped image you get (worst case):8192x512
4096x256
2048x128
1024x64
512x32
256x16
128x8
64x4
32x2
16x1
8x1
4x1
2x1
1x1
If your image has alpha in it, each pixel is 4 bytes wide. If your image does not have alpha in it, each pixel is still probably 4 bytes wide due to cache alignment.
In laymans terms, it's using a metric-assload of memory, which is entirely unnecessary. A texture size of 7856x337 is foolish.
Simply summing up those values doesn't give an accurate representation of how the memory is used, either. This is an example, mipmapped image, from Wikipedia:
You may be tempted to turn off mipmapping, however processing a texture of that size is going to kill fill-rate on any object which uses it.
#6
what's the additional area required to generate all the mip-maps for a given texture ?
eg, say you've got a texture that's W by H pixels, how many pixels are required to generate the mip-maps all the way down to 1x1.
(i was asked this question when i interviewed at nvidia once)
10/16/2007 (12:05 pm)
Stupid math Quiz:what's the additional area required to generate all the mip-maps for a given texture ?
eg, say you've got a texture that's W by H pixels, how many pixels are required to generate the mip-maps all the way down to 1x1.
(i was asked this question when i interviewed at nvidia once)
#7
10/16/2007 (12:18 pm)
My napkin math ends at, or around, log2. It should have something to do with the largest dimension of the texture (width/depth/height), and there's probably logs in there.
#8
10/16/2007 (1:28 pm)
Ok... so, whats the maximum texture size recommended to use with TGB?... cuz right now, im using 4 large textures (2112x1150 each), and the rest are 512x512 or less (each of the non-large textures have a power of 2 size at W&H)... if i take out the large textures, the game will run fine, but will still eat up a huge ammount of ram (say 500MB)... and i kinda think thats unnaceptable for a 2D Game....
#9
this is because each mip level is 1/4 the area of the previous,
and the infinite sum 1/4 + 1/16 + 1/64 + ... converges to 1/3.
if you're the sort of person who apparently had nothing better to do than fool around with dynamic html and infinite sums for at least two whole evenings, you might enjoy elenzil.com/esoterica/sums. edit: the rest of you, please don't click that link, as it's embarrassing.
10/16/2007 (1:33 pm)
It takes an additional 1/3 area.this is because each mip level is 1/4 the area of the previous,
and the infinite sum 1/4 + 1/16 + 1/64 + ... converges to 1/3.
if you're the sort of person who apparently had nothing better to do than fool around with dynamic html and infinite sums for at least two whole evenings, you might enjoy elenzil.com/esoterica/sums. edit: the rest of you, please don't click that link, as it's embarrassing.
#10
Not trying to be rude, but then you should stop using textures appropriate for a 3D game, and re-optimize for minimum footprint instead of speed (which may take as many as 6-12 months depending on your skill set, which will require going in to the code and re-writing several systems from the ground up).
You mention for example that you still have textures that are at/near 512 x 512 -- assuming that you are running in a windowed mode, that means that just one game object is going to take up probably 1/2 to 3/4 of your screen (depending on your resolution), or be using a lower mip level in any case if the object isn't that large.
10/16/2007 (4:44 pm)
Quote:
and i kinda think thats unnaceptable for a 2D Game....
Not trying to be rude, but then you should stop using textures appropriate for a 3D game, and re-optimize for minimum footprint instead of speed (which may take as many as 6-12 months depending on your skill set, which will require going in to the code and re-writing several systems from the ground up).
You mention for example that you still have textures that are at/near 512 x 512 -- assuming that you are running in a windowed mode, that means that just one game object is going to take up probably 1/2 to 3/4 of your screen (depending on your resolution), or be using a lower mip level in any case if the object isn't that large.
#12
Is TGB able to do/would it help to make textures the way ET:Quake Wars does (at least how i've seen how it does them)? That game has texture sheets for a whole set of textures used at once. So if you have a level that uses bricks, a big texture sheet (say, 1024x512) contains all the bricks the level uses. Then you just tell the world editor to use certain sections at a certain time. It increases the # of files on the hard drive & you have repeats in some files, but lowers loading time a bit (because there's fewer files to load) &, i would think, memory used as you could put textures you'd use of any size in one sheet, from 1x1 to as big as the sheet. Similar to your first link.
10/16/2007 (6:52 pm)
Nice!Is TGB able to do/would it help to make textures the way ET:Quake Wars does (at least how i've seen how it does them)? That game has texture sheets for a whole set of textures used at once. So if you have a level that uses bricks, a big texture sheet (say, 1024x512) contains all the bricks the level uses. Then you just tell the world editor to use certain sections at a certain time. It increases the # of files on the hard drive & you have repeats in some files, but lowers loading time a bit (because there's fewer files to load) &, i would think, memory used as you could put textures you'd use of any size in one sheet, from 1x1 to as big as the sheet. Similar to your first link.
Torque Owner Stephen Howe
i don't know how the vram gets used though. looking in to how data is actually put in to there might be more useful. ET:QW, for example, uses detailed textures up close & less detailed ones far away so it doesn't have 2gb textures loaded. TGB may do something simular.