Virtual Texture Memory Pools : mips and configuration

Development Rendering
, ,
1

Hello,

I am currently investigating memory usage of our virtual textures and I have some trouble understanding some concepts.

What I have already researched :

Questions I am asking myself :

  • In the engine code, I can see that there is the concept of “ResidencyMipBias”. Does that mean that multiple or maybe all mips of a given texture’s tiles are loaded into memory ?
  • I have read that “r.VT.PoolSizeScale” should be used to control the pools’ sizes globally, but it doesn’t seem like it should in the scalability settings of [TextureQuality[Content removed] but I don’t see how both are related.
  • Do the scalability settings of [TextureQuality@N] affect virtual texturing aside from “r.VT.MaxAnisotropy” ?

Regards.

2

Hi there,

Residency MipMap Bias and other virtual texture pool settings / setup are covered in this documentation.

From the docs:

“If a pool has been configured with the bEnableResidencyMipMapBias setting enabled, a mipmap bias is set to reduce residency when it is oversubscribed. This prevents unwanted IO and screen flickering at the cost of rendering virtual textures with a reduced resolution.

This setting is useful if residency is very rarely oversubscribed and you don’t want to allocate memory for the rare chance this could happen. The on-screen message for oversubscription includes any mipmap bias that is being applied.”

Basically, with this enabled, the engine will start dropping the texture quality when a pool is almost full. This allows the engine to evict the higher quality mips (that are no longer needed due to the MipMap bias), and keep the pool from completely filling up and causing IO trashing as tiles are constantly evicted / loaded.

Only the mip levels that are actually sampled in the shaders (the MipMap bias is applied here) will get streamed into the pool. Generally the system will not load mips outside those requested.

The scalability settings in BaseScalability.ini are just the defaults. You can create your own scalability settings which set the r.VT.poolSizeScale CVar, at each scalability level, to values appropriate for your project. You can do this by creating a DefaultScalability.ini config file in your projects Config directory, see here for details.

In terms of the relation to screen resolution, picture it like this: if you have an 8k display and an 8k texture, and the texture you’re looking at fits perfectly to the display, then you need to stream in all its mip 0 tiles. However, if I only have a 4k display, then I only need to stream in all the mip 1 tiles (the 4k mip tiles). If your tile size is 256x256, then the 8k display requires 1024 tiles to be loaded, while the 4k display only requires 256 tiles to be loaded. If you go closer to the object, you would have to steam in some of the mip 0 tiles on the 4k display. However, a bunch of tiles will also no longer be visible, so the requirement of roughly 256 tiles will be maintained. This is because we only need 256 texture tiles to fill a 4k display.

Other than r.VT.MaxAnisotropy, there are no settings in the BaseScalability.ini that affect virtual textures, but, as I mentioned above, you can create your own scalability settings to configure this. You can also override the scalability settings per platform as described here for Android (but the same applies to other platforms).

Regards,

Lance Chaney

3

Hello,

> In terms of the relation to screen resolution, picture it like this: if you have an 8k display and an 8k texture, and the texture you’re looking at fits perfectly to the display, then you need to stream in all its mip 0 tiles.

> However, if I only have a 4k display, then I only need to stream in all the mip 1 tiles (the 4k mip tiles). If your tile size is 256x256, then the 8k display requires 1024 tiles to be loaded, while the 4k display only requires 256 tiles to be loaded. If you go closer to the object, you would have to steam in some of the mip 0 tiles on the 4k display.

> However, a bunch of tiles will also no longer be visible, so the requirement of roughly 256 tiles will be maintained. This is because we only need 256 texture tiles to fill a 4k display.

Thank you very much for this response, this was exactly what I couldn’t wrap my head around.

> The scalability settings in BaseScalability.ini are just the defaults. You can create your own scalability settings which set the r.VT.poolSizeScale CVar, at each scalability level, to values appropriate for your project. You can do this by creating a DefaultScalability.ini config file in your projects Config directory, seeherefor details.

According to this [Content removed] setting r.VT.poolSizeScale in the [TextureQuality@N] scalability settings doesn’t really make sense as the memory requirements seem to be heavily influenced by the render resolution. Which is why it recommends to estimate our own ratios for user-defined resolutions on PC.

> Other than r.VT.MaxAnisotropy, there are no settings in the BaseScalability.ini that affect virtual textures, but, as I mentioned above, you can create your own scalability settings to configure this. You can also override the scalability settings per platform as describedherefor Android (but the same applies to other platforms).

As the render resolution on consoles is fixed, we are planning to either set custom sizes for the VT pools or a custom r.VT.poolSizeScale value.

Regards.

4

You’re welcome. Setting the pool size scale relative to the screen resolution seems like a good approach. I’m closing this case out for now, but let me know if you have any further questions.

Regards,

Lance Chaney