Game View stats performance

[anon_72585682]

The Stats panel in the Game View has the line “Used Textures” with a count and memory value.

I assume that this is the total memory used by the textures. So this is the value to watch in terms of how much GPU memory is being used. So if we want it to run well on a 64 MB GPU, we need to make sure this value stays under 64 MB, right?

Or do GPUs use their VRAM for other stuff and so there’s really less available for textures? Any rules of thumb?

A similar, though more general question is about the impact of using smaller textures at lower quality levels. Our quality levels use 1/8, 1/4, and 1/2 texture sizes at the lower quality levels. But I’m not seeing the texture memory used change in the stats window.

Is that because the texture takes up the same amount of memory, but is just faster to render at lower sizes for other reasons? Or what?

Thanks,
Steve

[Aras]

@""

I assume that this is the total memory used by the textures. So this is the value to watch in terms of how much GPU memory is being used. So if we want it to run well on a 64 MB GPU, we need to make sure this value stays under 64 MB, right?

Yes, it would better be under that amount. If you’ll go over that, it will start swapping textures in and out each frame, which hurts.

Or do GPUs use their VRAM for other stuff and so there’s really less available for textures? Any rules of thumb?

Framebuffer and backbuffer are always (or almost always? I don’t know these days…) located in video memory. So add memory for “the screen”; which depends on resolution. Usually that’s frontbuffer (32 bit per pixel), backbuffer (32 bit per pixel) and depth buffer (32 bit per pixel). If you’re using anti-aliasing, then backbuffer and depth buffer take correspondingly more VRAM (e.g. 4xFSAA takes at least 4 times more VRAM).

Render textures very often live in video memory as well. Sometimes they can be swapped out (e.g. on Mac OS X or Vista, where video memory is virtualized).

Then it’s mostly textures. If there’s space, vertex buffers are usually put into VRAM as well; but it’s not very bad if they don’t fit there. Vertex data is usually much smaller than texture data, so reading them through AGP/PCIe bus is usually not a problem.

A similar, though more general question is about the impact of using smaller textures at lower quality levels. Our quality levels use 1/8, 1/4, and 1/2 texture sizes at the lower quality levels. But I’m not seeing the texture memory used change in the stats window.

I think we don’t account for that in the stats calculation… Oops

[anon_72585682]

@Aras Pranckevicius

A similar, though more general question is about the impact of using smaller textures at lower quality levels. Our quality levels use 1/8, 1/4, and 1/2 texture sizes at the lower quality levels. But I’m not seeing the texture memory used change in the stats window.

I think we don’t account for that in the stats calculation… Oops

So that means that right now, those stats reflect full sized textures rather than the reduced sizes?

And could you briefly say what the other benefits of smaller textures are (if any) besides keeping VRAM usage down?

Thanks,
Steve

[Aras]

@""

I think we don’t account for that in the stats calculation… Oops

So that means that right now, those stats reflect full sized textures rather than the reduced sizes?

Yes. You can divide texture memory by four for each dropped mipmap level (assuming all your textures are mipmapped).

And could you briefly say what the other benefits of smaller textures are (if any) besides keeping VRAM usage down?

Lower VRAM usage is the primary benefit. Lower resolution textures might be faster to render, but that should be negligible.

[anon_72585682]

Thanks a lot, Aras. That’s very helpful. (and I filed a bug report about the stat window and texture reduction settings).

[anon_78480614]

Good thread – thank you Aras and DocSWAB.

Now a dumb question – what’s a render texture as a opposed to a regular texture?

[jashan]

Hi Unclet

rendertexture is a texture that a camera renders into during runtime, i.e. to fake reflections or refractions (or many other funny things ).

Sunny regards,
Jashan

[anon_78480614]

Ah, thank you Jashan.

So I guess there is a VRAM penalty for each active camera?

[Aras]

@""

So I guess there is a VRAM penalty for each active camera?

For each render texture. Multiple cameras can render into the same render texture (or directly to screen). Shadows use render textures internally. Image postprocessing effects use render textures. And so on.

[anon_18482239]

About this problem of memory, Does the WWW.texture compress textures? If not, Could be possible to do that in realtime?

Thanks

[Aras]

@""

About this problem of memory, Does the WWW.texture compress textures? If not, Could be possible to do that in realtime?

Not right now. Someday - yes, maybe.