Extra VRAM required for Filtered and MipMapped
BlitzMax Forums/BlitzMax Programming/Extra VRAM required for Filtered and MipMapped
| ||
| Hi All, I can't recall if it's Filtered Images or Mip Mapped Images that require more VRAM (or both). I recall something about a texture 1/4 the size and then 1/16th the size etc which I think must have been for mip mapped. I'm basically trying to work out the VRAM an image uses. For example: 1024x1024x4 = 4Mb for a plain image. How much more for filtered, and how much more for mip mapped. Anyone know? Thx. |
| ||
| I don't have the exact formula, but my notes tell me to figure 6mb for every 1kX1k texture with filtered/mip mapping flags. |
| ||
| MGE's figure is correct. For any given texture, multiply by 1.5 to get the total figure including mips. |
| ||
| OK thanks, that's worth knowing. |
| ||
| Mipmapping needs more ram. I saw elsewhere that it would work out to about *1.3 not *1.5 - but I could be wrong. You basically divide the dimensions by 2 each time until it gets down to like 1x1. There is a little bit of overhead probably for storing the textures in an mipmap array. Filtering does not use any additional video ram. |
| ||
| Yeah I thought it was less that 1.5. e.g. 1st mip map = 25% 2nd mip map = 25% of 25%, so 6.25% 3rd mip map = 25% of 25% of 25%, so 1.56% and so on. Add them and you'll get 33% ish extra. So 1.33 is maybe a more accurate figure? Interesting that filtering doesn't use more RAM. |
| ||
| Yes, 1 + 1/4 + 1/4 * 1/4 ... is a mathematical series that tends towards 4/3, so you need 1/3 more memory when using mipmapped textures. |
| ||
| Yup 133% compares to non-mipmapping. It's not a bad amount of overhead considering it makes the rendering potentially faster and better looking. Having said that, the main purpose of mipmapping is to create pre-scaled versions of the image which will be displayed when you render your image with some kind of scale factor. It isn't going to have any effect when you use SetScale above 1.0 as there is no `bigger` image to tap into. It's only going to have an effect when you shrink your image with SetScale below 1.0, and will only use the mipmap level close to/within the scale of the image. For example if you setscale to 0.5 you will probably begin to see the first mipmap level ie 50% size. It won't use the next one until you set scale to 0.25 etc... so if you aren't scaling down very much, and especially if you aren't scaling down to 50% size or less, they aren't going to help and are a waste of memory. I forget exactly how the texture lookup system uses the mipmap levels - I think it does some kind of cross-reference between the current mipmap image and the next one depending on the scale factor? Also there is anisotropic texture lookup which is somewhat more advanced but better quality, and not a standard blitzmax feature. Where mipmapping is basically a way of selecting texel colors in the Z direction, ie comparing a further-away image to a nearer image, filtering is a similar process but in the X-Y direction. Filtering doesn't need any mipmaps. It's just a way of looking up texel colors and, if necessary, interpolating between their values to create pretend in-between values. Also it might take several texels and blend them together if you're scaling down - basically a way of doing sub-pixel floating-point coordinate access with interpolation. It doesn't need any extra memory to do it, it's part of the texture lookup functionality. It's basically just some different math. |
| ||
| Yeah I use it to scale down fonts. Actually for some graphics that I was scaling down I felt that mipmap actually made it worse so switched it off. |
| ||
| I guess that's possible, since it sort of blends between two differently scaled images, and depending on how you created those scaled images, they may or may not be a good fit together. I think BMax auto-generates them using the hardware, which then depends on the driver as to the quality. You could alternatively create your own mipmaps and upload them. |
   |