Virtual texture mapping

May 12, 2008

Graphics

approximately 2 minutes to read

There’s somehow a lot of confusion going on about virtual texture mapping: I’ve been recently asked whether it’s going to increase the VRAM usage extremely, and this is so way off I think it’s time to clarify some things about it ;)

Sources

Virtual texture mapping is going to be used by the id Tech 5 engine (from id Software). The technology behind this dates back to SGI, where it was called clipmaps and worked only for terrains. Later, a paper was written about a similar technique: “Unified Texture Management for Arbitrary Meshes”. Carmack himself has been describing the basic idea back in 2000 already. Tom Forsyth has also a blog entry about it. Sean Barret presented a technique called “Sparse Virtual Textures” at GDC 2008, with a working virtual texture mapping implementation. For a good overview, take a look at Mittring’s “Advanced virtual texture topics”.

How it works

The main idea behind virtual texture mapping is the following observation: Given a screen resolution, it makes no sense to have more texture data in memory than needed to have one texel per pixel (at least). For example, if we are running a game at 1680x1050, we cannot display more texture data than 1680x1050 (simply because there are not more pixel available), so if we can create a texture with exactly the parts needed for display, it won’t be any larger than our framebuffer. Of course, a perfect fit is not possible, but we can reasonably estimate that if we can figure out which mip-map level of each texture is needed, we can get away with a fixed cache of maybe 2-3 times our framebuffer (let’s say 1680x1050x4 byte per pixel x 6 layers x 3 times overdraw = 120 MiB worst-case). This gives us a constant upper limit for the memory usage: We can never go above our texture budget, only below, if the amount of textures visible is smaller than our cache. Sounds easy, eh? The difficult part is:

figuring out what part of each texture is visible, and at which mip-map level (efficiently)
stream in the textures quick enough

But the idea is pretty easy. Notice how this is similar to virtual memory in a normal PC: There you have pages (texture tiles), which are either in RAM (VRAM) or on disk and paged in on demand. Same with virtual texture mapping, with exactly the same advantage: You can use larger working sets than your available RAM. For graphics, it’s even a bit better as the upper limit can be capped by the display resolution. Larger working set in the context of graphics simply means you can use more textures than your VRAM would allow you to (basically, unlimited, as you can stream them from disk).

Update: Added links to “Sparse virtual textures”, “Advanced virtual texture topics”.

Update: Fixed link to “Advanced virtual texture topics”.