..Im looking for thread , someone posted here quite some time about calculation and nice explanations regarding relationship between texture size and video memory usage based on that, as well as explanation and calculus about frontbuffer/backbuffer/zbuffer usage based on set screen size...anyone know who use to write that thread or link maybe?
Video memory usage
Miscellaneous Forums/General Discussion/Video memory usage Buffer size = width * height * colour depth
(could be a bit off with that, bit might kick start someone into posting a more accruate answer. how to calculate the size of the z-buffer, i'm not sure.
Texture size = (width * height /8)* bit depth
Everything, textures, meshes... etc etc, is loaded into RAM first, then transfered over to VRAM when it appears in the viewport, at least in blitz anyway. However, nothing is unloaded until VRAM is full and it starts swapping in and out. Must be a optimsation of some sort :o)
(could be a bit off with that, bit might kick start someone into posting a more accruate answer. how to calculate the size of the z-buffer, i'm not sure.
Texture size = (width * height /8)* bit depth
Everything, textures, meshes... etc etc, is loaded into RAM first, then transfered over to VRAM when it appears in the viewport, at least in blitz anyway. However, nothing is unloaded until VRAM is full and it starts swapping in and out. Must be a optimsation of some sort :o)
The thread has an error thought.
Buffer size is not fully right * FSAA is missing there in case of the FB and BB and those two buffers are always on the GPU and VRAM
Buffer size is not fully right * FSAA is missing there in case of the FB and BB and those two buffers are always on the GPU and VRAM
how this number for mipmaps(1.33) are created?
Mipmaps which contains
The increase in storage space required for all of these mipmaps is a third of the original texture, because the sum of the areas 1/4 + 1/16 + 1/64 + 1/256 + · · · converges to 1/3. (This assumes compression is not being used.)
The increase in storage space required for all of these mipmaps is a third of the original texture, because the sum of the areas 1/4 + 1/16 + 1/64 + 1/256 + · · · converges to 1/3. (This assumes compression is not being used.)
On top of that, images are converted to the nearest power-of-two dimensions by blitzmax (IIRC) to maximize compatibility with older video cards.
At least in OpenGL you can use glGet() to get the number of bits in any of the buffers. Note that even if you do not ask for a Depth buffer you might be given one anyway. It depends on how the graphics card allocates and uses memory. Normally a pixel in the depth buffer will be 24-bit or 32-bit. If you ask for a stencil buffer it often will share some space with the depth buffer, so the stencil will be 8-bit and the depth will be 24-bit, otherwise most likely the depth is either 16-bit or 32-bit, in most cases.
If you do not ask for an alpha buffer it's possible that you will get a 24-bit color mode with no alpha channel if your gfx card supports it, something to consider - it's one less byte per pixel.
Also you need to consider what is the internal format of textures which you've uploaded. Usually if you upload an RGBA8888 texture it'll be 4 bytes per texel, but for example you can have a 16-bit backbuffer and yet GL might store your textures as 32-bit. Or it may give you a 32-bit back backbuffer on a 16-bit desktop and scale the colors down when you do a Flip (and maybe dither it).
Note it is also possible to not ask for a back buffer - if you set the driver default to not include backbuffer you may get a single-buffered screen (front buffer only), which means you are using less vram. And another thing to bear in mind is that not all systems use only one backbuffer, some systems allocate multiple backbuffers and then cycles through them each time you Flip, to allow you to render at high hz rates without (ie Flip 0) without a vertical blank sync. These extra backbuffers will take up extra ram just like a single backbuffer will and you cannot easily tell through BlitzMax whether this is happening - except perhaps if you experience `mouse lag`.
If you use more advanced features like display lists or vertex buffers etc that stuff has to be stored in vram also.
From my experience OpenGL will try to use as much vram as is available to store textures but if there is not enough it will start to dynamically spool texture data off to main memory by itself, based on the prioritization of individual textures that you define. In an ideal situation this won't happen but if you run out of ram then the amount of video ram being used will remain mostly `full` but the actual amount of graphics that it's handling is more than that.
It's also possible in OpenGL to create `proxy` textures which are basically empty textures or textures with no image, and you can return the error messages generated when there is not enough ram for them, to possibly detect how much video ram is available. I haven't tried it though.
Also bear in mind some systems have ram embedded within the graphics bus, inbetween main memory and video ram, as a kind of cache.
Also other OpenGL state data might reside in video ram so it's hard to tell. I *really* wish they would've implemented a `video ram avaliable` function as part of the library - but I suppose that would have to mean other o/s apps could be using some of the vram outside of OpenGL and it wouldn't be able to tell without dipping into platform-specific code. But hey, if you have to write the driver for GL on a specific platform anyway you'd hope they would at least let you wire-in a memory test.
If you do not ask for an alpha buffer it's possible that you will get a 24-bit color mode with no alpha channel if your gfx card supports it, something to consider - it's one less byte per pixel.
Also you need to consider what is the internal format of textures which you've uploaded. Usually if you upload an RGBA8888 texture it'll be 4 bytes per texel, but for example you can have a 16-bit backbuffer and yet GL might store your textures as 32-bit. Or it may give you a 32-bit back backbuffer on a 16-bit desktop and scale the colors down when you do a Flip (and maybe dither it).
Note it is also possible to not ask for a back buffer - if you set the driver default to not include backbuffer you may get a single-buffered screen (front buffer only), which means you are using less vram. And another thing to bear in mind is that not all systems use only one backbuffer, some systems allocate multiple backbuffers and then cycles through them each time you Flip, to allow you to render at high hz rates without (ie Flip 0) without a vertical blank sync. These extra backbuffers will take up extra ram just like a single backbuffer will and you cannot easily tell through BlitzMax whether this is happening - except perhaps if you experience `mouse lag`.
If you use more advanced features like display lists or vertex buffers etc that stuff has to be stored in vram also.
From my experience OpenGL will try to use as much vram as is available to store textures but if there is not enough it will start to dynamically spool texture data off to main memory by itself, based on the prioritization of individual textures that you define. In an ideal situation this won't happen but if you run out of ram then the amount of video ram being used will remain mostly `full` but the actual amount of graphics that it's handling is more than that.
It's also possible in OpenGL to create `proxy` textures which are basically empty textures or textures with no image, and you can return the error messages generated when there is not enough ram for them, to possibly detect how much video ram is available. I haven't tried it though.
Also bear in mind some systems have ram embedded within the graphics bus, inbetween main memory and video ram, as a kind of cache.
Also other OpenGL state data might reside in video ram so it's hard to tell. I *really* wish they would've implemented a `video ram avaliable` function as part of the library - but I suppose that would have to mean other o/s apps could be using some of the vram outside of OpenGL and it wouldn't be able to tell without dipping into platform-specific code. But hey, if you have to write the driver for GL on a specific platform anyway you'd hope they would at least let you wire-in a memory test.
..all this readings are fine, and giving much more brighter picture about whats going on in VRAM..however, I would like to see some calculus(not just explanation for it) where level geometry goes (polygons and stuff) and how actual calculus for memory load looks like, so i can roughly know how much my polygons taking on VRAM, if it is going to be there...that info would be helpful to me..