Texture Memory, compression, mip-mapping

Here are some advice:
-Learn 3D hardware tech.
-Read the API doc.

Now to answer your questions (but please do what I''ve previously mentionned) :

In a Video Card are Stored ZBuffers, stencil buffer and Color Buffer.
This is true for standard card, but not PowerVR tech (best Technology I know) and Gigapixel (bought by 3Dfx and expected to ship next year), both don''t have to store Stencil and Z buffers in RAM, they have an on chip dedicated RAM to do that.

Basically:
Free RAM = Total RAM - (Resolution*bitdepth/8)*numberOfBuffers - (Resolution*Zbitdepth/8).
Stencil bits are commonly ''stoled'' from the ZBuffer.

If you used S3TC (I''m an OpenGL guy) you can achieve 6:1 compression.

I recommend that you ask OpenGL for the Best texture format and use it rather than using a defined 3D format, cause PowerVR have VQ texture compression with a ratio 8:1 and top quality.
Also 3Dfx have FXT1 that is very good.

Try to have some free Video RAM to be able to manage texture priorities and the like. (Or let OpenGL do it for you)

So with 16Mb card having S3TC (also known as DXTC): (in kb)
Res : 1024*768
bit depth : 32bits
ZBuffer : 24 + 8 stencil
Double Buffered.

16384 - ((1024*768*32/8)/1024)*2 - (1024*768*32/8)/1024 =
16384 - 6144 - 3072 = 7168 kb FREE.

7168*6 = 43008 kb FREE = 42Mb FREE


2. Mip mapping is required for trilinear filtering.
I think you should get a book about the basics of 3D.
Basically it does bilinear filtering on two mipmaps levels making best transition between different mipmaps level.
Mipmaps are used to make things appear best.
(The complete theory is of course a bit more complicated and involve maths)
It consumes memory of course, has you have to store all mipmaps levels.
1024*1024 Base texture + 512*512 mipmap + 256*256 + 128*128 + 64*64 ...
Note that you can have only a few levels of mipmaps, but you must NEVER break the continuity.
eg : 1024*1024 + 512*512 + 128*128 is wrong since the 256*256 step is not present.

I think that you can do the maths yourself to see how many mipmapped textures you can store in local video memory using the above maths and your brain.

Quality:
Point sample filtering.
bilinear filtering.
bilinear mip mapped filtering.
trilinear filtering
anisotropic filtering.

A trilinear filtered game looks very good, and an anisotropic filtered one best

-* So many things to do, so little time to spend. *-

I know everything that you mentioned. I do understand the fundamentals of 3D tech, and I have read through the API''s before. I may be a simpleton, but despite all of that I have questions.

All of your math makes one assumption. That you can only have as much textures as you have video memory. This is the assumption that I originally made, but my belief is that it is flawed. There''s this wonderful technology called AGP which came into being to facilitate faster transfers from sys->vid memory and visa versa. If we were to assume that all textures were required to fit into video memory, we would then have to assume that, other than the inital load of textures to video memory, there is no need for AGP memory. This also removes the possibility of procedural textures, etc... In addition to all of this, there is this notion of texture "thrashing", which, in my mind, would not exist if all textures were so simply stored into video memory... Beside, one of the touted advantages of s3 texture compression is the speed at which they can be loaded from AGP to video memory (due to their reduced size which equals reduced memory bandwidth requirements)

All this in mind... is there a healthy trade-off between the amount of video memory you have and the amount of system textures you can have. That was my question... I was not asking about the fundamental makeup of a 3D card. (which I am already familiar with)

As for mip-mapping... I understand that as well... I know how to divide by 2 etc... ad naseum to produce a mipmap. That too was not my question. You did, however, manage to give me AN answer to that question, which was that it allowed for enhanced visual quality... I have heard other reasoning behind mipmaps, which is that textures at smaller mipmap levels can be more quickly loaded from sys->vid memory if the object is at such a distance that the lower mipmap level is adequate (of course this ties into my earlier statement about the whole sys vs. vid memory textures) What I was trying to determine was the reasoning most people use mipmaps... If it is for performance reasons (faster load of smaller mipmaps) then that is one thing, if it is for visual reasons then that is another.

Galshin

I apologies
I''m very sorry, most of the time I see total newbees in here, so I thought you were one, I beg your pardon.

Basically AGP is meant to faster memory load. This means that it helps on texture management.
Local memory is way faster than RAM, and AGP have T&L informations to transport too now.
This is a problem.
I try to put all my scenes textures in Video memory, using AGP not for texturing but only as a fast way to update my Video memory content.
AGP texturing is possible but kills performances IMO.
(and in benchs too )

So to answer (And I hope correctly this time) your question, we can store textures in RAM (not Video memory) after everything we need is loaded.
(I''m thinking of sounds, music, models,...)
Storing texture in RAM is of course interesting since AGP is way faster than a disk access
How much memory can be used depends on the system you run on and your game/app requirements.
I don''t know if there''s a healthy ratio, I do think that you store as much possible in Video, and remaining required in AGP memory, and if possible textures you may need in AGP too.


I use mipmaps for quality reasons.
I do think that other engineer I know use it for that reason too.
About the small mipmaps being uploaded faster in video memory...
Bad idea since this means that you actually have to use the AGP bus, which is slower than local video RAM.
But on low end system that could be interesting for speed reason.
Anyway since low end systems tend to have fewer RAM/video memory available I don''t think that the argument is really good.

I think I wanna test that in my 3D engine, and talk about it around me to see is some have some knowledge about all this.

-* So many things to do, so little time to spend. *-

Actually, I don''t think mipmapping will ever speed up texture transfers. Apparently, if you have, say, a 2048x2048 texture that''s not currently in video mem, you will always have to transfer the entire mipmap pyramid. Not just the one level that you need, even if it''s just the 2x2 pixel one

If I recall correctly, it was John Carmack who discussed this in a .plan file a few months ago. I can look it up if you want to. The solution he suggested was to virtualize the video memory - i.e. use paging to load textures in, say, 4KB blocks.

ouf...

I wasn''t sure about the mipmap pyramid so I''m glad you confirm this.

Virtualized texture memory is available in the 3DLabs Permedia3 card.


-* So many things to do, so little time to spend. *-

Mipmaps make accelerators happy. Cards have an internal cache which can only hold so many texels at a time. If you're rendering a distant object with a full scale texture, you'll be skipping a large amount of texels and the cache is next to useless. If you're using a mipmap (remember the card tries to get close to a 1:1 pixel-texel ratio when choosing mip level) the cache will function optimally and performance should be much better.

Edited by - Ampere on November 7, 2000 1:21:45 PM

Ok... thanks for the input.

As for mipmapping. There seems to be mixed feeling on wether or not it offers a performance increase. (texel caching, etc...) I will have to keep digging on this one. Basically, for the game I am working on I need to use a lot of textures (unless my approach is fundamentally flawed, in which case this whole thread is moot ... and if mipmapping only offers visual improvement, I would be willing to forgo it to save on texture memory.

As for texture memory. The main reason I ask is because of the PS2. I know that it has a low amount of VRAM (4MB), and once you chunk out the memory for all the different buffers (all though it won''t be too bad because the res is so low) you don''t have much memory left for textures. Even with texture compression, you are sort of hosed. That''s why I was wondering about textures being pulled out of system memory. Maybe the PS2 has some sort of enhanced memory bus where this becomes possible? Sort of like the XBox which has a shared memory architecture.

For those who hadn''t already found it: check out this 3Dlabs whitepaper about their virtual video memory architecture.

Using mipmapping along with texture compression is very appreciated by current hardware, cause the cache contains much more informations (thanks to the texture compression).

About PS2 : They will use procedural textures and/or stream textures form disk.
If you look at the games available you''ll see that it''s very poor on textures and texture quality. However, as you said, res is so low that it''s not that much visible.
You only see that the game seems to be ''nude'' compared to PC or DC games.

-* So many things to do, so little time to spend. *-

One the the primary reasons for using mipmapping is to enhance visual quality. The full explanation (which I cannot accurately provide) is a detailed account in the realm of signal processing. But I''ll try to provide a simple explanation.

Let''s say we have a one dimensional image (ie, pixels in a horizontal line). And let''s say it''s thirty-two, alternating pixels of black and white, like this:

X_X_X_X_X_X_X_X_X_X_X_X_X_X_X_X_

Now, we map this texture onto the screen (and doing everything screen-aligned right now) at the right distance and we''re fine; our 32 pixels show up on screen exactly as they do in texture.

Now let''s move the camera away just a little so that we have to scale our line down from 32 pixels to 31.... If we maintain only the two colors (black and white), we are essentially left to remove one pixel somewhere. Our line might look like this:

X_X_X_X_X_X_X_XX_X_X_X_X_X_X_X_

Suddenly, where we had this nice alternating pattern, we now have a disruption. On screen this will look like one of the black bands got wider, or one of the white bands disappeared. It only gets worse as you remove more and more pixels.

Blending or anti-aliasing using grey values won''t help, because you''ll get this:

GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG

Your whole signal has disappeared!

Now, my example is extreme; we usually don''t see patterns like that in games, unless you''re drawing something like a chess board. The gentler textures, even though some may still be harsh or sharp, don''t degrade quite as quickly as my pattern above, but they still will. This is noticeable in games that don''t use mipmapping when you see a surface that seems to "shimmer".

Mipmapping essentially creates versions of the pattern (aka signal) at various resolutions, then uses the appropriate resolution to render. Trilinear mipmapping will actually blend between two mipmap levels to come up with a very good rendering of the texture.



---- --- -- -
Blue programmer needs food badly. Blue programmer is about to die!
---- --- -- -
New York. New York. New York. Texas. Texas. New York. New York. Canada.
---- --- -- -

You NEED mipmapping for visual quality as much as you need textures for visual quality.

Mipmaps require at most 50% more storage space than the single texture. Each map is only 1/4 of its parent. So we have 1 + 1/4 + 1/16 + 1/64 + 1/256 + 1/1024...

quote:

---

As for texture memory. The main reason I ask is because of the PS2. I know that it has a low amount of VRAM (4MB), and once you chunk out the memory for all the different buffers (all though it won't be too bad because the res is so low) you don't have much memory left for textures. Even with texture compression, you are sort of hosed. That's why I was wondering about textures being pulled out of system memory. Maybe the PS2 has some sort of enhanced memory bus where this becomes possible? Sort of like the XBox which has a shared memory architecture

---

The PS2 has a really fast BUS, 2560 bits wide(No, that's not a typo, I did mean to type 2560 ) and running at at least 66Mhz, but probably 100Mhz. So I guess they only really use the 4MB on the display hardware for the frame buffers and maybe a few odds and ends, and just shove the rest in the 32MB sys RAM.

------------
- outRider -

Edited by - outRider on November 13, 2000 1:32:19 PM

Actually, a mipmapped texture is at most 33% larger than a
not mipmapped one. Simple counting gives:

64x64 = 4096
64x64 + 32x32 + 16x16 + 8x8 + 4x4 + 2x2 + 1 = 5461

which is 5461 / 4096 = 1.33325.

aXeLP

quote:

---

Original post by axelp

Actually, a mipmapped texture is at most 33% larger than a
not mipmapped one. Simple counting gives:

64x64 = 4096
64x64 + 32x32 + 16x16 + 8x8 + 4x4 + 2x2 + 1 = 5461

which is 5461 / 4096 = 1.33325.

---

So there you have it. Only 33% bigger. Even better than I said.