It’s optimization time on our project, so we’re rockin’ out with pstats and the framerate counter.
We’re currently chasing around our texture memory usage, and I wanted to clarify one of the features of pstats. In the “Graphics Memory” graph, I can drill down through “context1” to see the “Active, Inactive” resource charts. My question is: what exactly is the meaning of this level of division? Are the “Active” resources the ones in the graphics card’s memory, while “Inactive” are the ones staged in RAM to be loaded when needed?
Additionally, if I drill down one more level, I can see the content divided into texture, ibuffer, and vbuffer. I recognize texture, and I assume vbuffer is the vertex buffer; what’s ibuffer?
“Active” means textures that are actually onscreen and being rendered, this frame. “Inactive” means textures that are still in texture memory, but are not actually being rendered this frame. You might also occasionally see “Nonresident”, which are those textures which have been evicted from texture memory, though you should hope to never see “Thrashing”, which are textures that have been evicted from texture memory, even though they were used to render something this frame.
Note that OpenGL is not terribly informative about the residency state of textures, so in some cases this is just an educated guess on Panda’s part. DirectX is a little more helpful, though I’m not 100% sure that the pandadx library handles DirectX’s response codes fully.
An ibuffer is an index buffer. It’s just like a vertex buffer, except instead of vertex data it holds indexes into vertices. OpenGL doesn’t make a distinction between ibuffers and vbuffers, but DirectX does, so Panda does too.
So does “Inactive” means that the textures are on the graphics card but not needed this frame, or that they’re in RAM and weren’t used by the graphics card this frame? I’m a little confused because pstats is reporting that the combination of “Active” and “Inactive” is over 200MB; we’re using Radeon 9600 Pro cards, which (I believe) only have 128MB of texture memory.
On a related note: we’re considering using egg-palettize to unify our textures into larger paletted source images. In general, our textures are already square and powers-of-2. Can we generally expect any gains from palettizing in this situation? Empirical testing suggested that our world was faster (i.e. experienced less popping and frame-rate drop as we turned around in a large scene) with a smaller number of large textures than a larger number of small textures, but I’m not sure why. The CS theorest in me says that if ab==cd, it shouldn’t matter if a is larger or smaller than c if the total byte-count is the same. Of course, computer graphics are one part theory and one part hardware implementation; is there a general rule-of-thumb that I need to make myself aware of in terms of how graphics cards are designed?
“Inactive” means on the graphics card but not needed this frame. However, the total size is based on OpenGL’s estimate of texture memory consumed, which is only an estimate, and may be wildly inaccurate, depending on your driver. So it may well be that you’re seeing over 200MB of reported texture usage, even though the actual texture usage remains within 128MB.
You should be able to expect performance gains for this. Having a handful of large textures is generally substantially faster than having a large number of small textures for a number of reasons:
(1) The graphics state has to be changed fewer times within a frame.
(2) Panda has to manage fewer Texture and RenderState objects.
(3) Some objects which previously had different textures, and therefore different states, might now have the same state, and can therefore be combined into a single larger object. This will happen automatically to a certain extent, especially if you are already making judicious use of flattenStrong() throughout your code. It will also help if you structure your textures.txa file to group together textures that are likely to appear on the same object.
Ah, excellent! I hadn’t considered the state unification aspect of the card communication. Palettize, here we come!
I double-checked the information pstats was giving me, and I’m afraid I’m still a bit lost. Using wdxGraphicsPipe8, pstats is reporting values for “Active” and “inactive” textures that sum together to exceed the 128MB limit on my graphics card (coming closer to 180MB). Where could I be getting the extra room? Is it possible that either the driver or wdxGraphicsPipe8 caches some of those textures in system RAM and only pulls them in when needed, or could the graphics card be doing some kind of dynamic compression, allowing it to stash more than 128MB in some form of higher-density format?
Let me reiterate: the actual amount of memory consumed, as shown in PStats, is merely an estimate, based on assumptions made about the way certain texture formats are likely to be stored in memory. It may be inaccurate. For instance, it might be off by a factor of 2. If this is the case, then you are actually consuming only 90MB.
However, now that I think about it, I believe the DX8 implementation does not know which textures are actually resident in texture memroy; so in this case “inactive” simply means textures that have ever been rendered and have not yet been deleted. So it may be that these textures are not actually resident anymore.
If you run in OpenGL, I think it will report more accurate “Active” and “Inactive” state.
Incidentally, the graphics card will not automatically enable texture compression unless you put:
compressed-textures 1
in your Config.prc. And this is presently only supported on OpenGL anyway.
That makes a lot more sense. I thought that you had meant that the rough estimates were an OpenGL-specific issue, not a general phenomenon of modern graphics hardware. That certainly makes sense, since any kind of card-supported diagnostic could end up being a performance hit.
Thank you for the tip on egg-palettize as well; we gave it a try tonight, and were able to reduce our total texture file count by a factor of 4 without any loss in visual quality! The “jerkiness” we were seeing is also decreased.
The next step is probably going to be to decrease our on-card memory usage. If I come up with any good techniques, I’ll be sure to share them!
