This post is very old. Please bear in mind that information here might be incorrect or obsolete, and links can be broken. If something seems wrong, please feel free to comment or contact me and I'll update the post.
Over the last months, I’ve written a virtual texture mapping implementation as part of my student research work. Some people have already got a copy to read (you know who you are 
), rest assured that I’ll continue to work on this stuff. I’m going to post about it on this block, as soon as the work becomes a bit more mature, currently the framework is in early alpha stage, and we are working on a better content creation pipeline. Our artist — although very talented — had a hard time to produce demo content, and hence we (that is, a co-developer and me) have to write some tools to help him.
My solution is basically a reimplementation of Sean Barret’s “Sparse Virtual Textures” (about which I already blogged about), this time with DX10, though I didn’t use anything DX10 specific. However, I measured lots of stuff, and tweaked based on that, and I still have lots and lots of things I have to try and measure. The implementation supports 4:1 anisotropic hardware filtering, and requires roughly 5x more texture space than framebuffer size (for a framebuffer with 400k pixels, you would need a 2M cache). No special shader tricks are needed, the lookup costs < 10 cycles (of which most are fixed overhead costs, so it becomes cheaper with more lookups).
Not all is lost though, you can use the comments to ask specific questions, and I’ll try to answer them.
Related posts:
Hello,
I am very interested in implementing sparse virtual textures myself however there is just one thing that confuses me and I have not found an answer in the Mittring paper or the Barret talk. Lets assume we are only rendering a terrain with a very large texture. I understand how to use the tex coords of the geometry and how to map them into the “physical (videomem) texture via the indirection texture (page table). The part I don’t get is the seemingly cyclic problem of knowing what data to copy into the physical texture. Do we render the texcoords of the terrain geometry into a texture and read back on the cpu to determine what pages to load? This seems like it would be painful on the CPU side especially if your screen resolution starts getting higher. Any insight would be greatly appreciated – Richard
Yep, that’s the approach — you have a pre-pass in which you render everything with UV coordinates only (or better, page ids), read this back (or parse on the GPU), and create a list of requested pages.
Reading back to CPU is not too bad, you can render at much lower resolutions (1/10 or less!) and still get correct results — this is easy to understand if you think about how large the pages are in screen-space: If a page is 128², you could potentially get away with 1/128th the resolution, as it would still cover one pixel. In practice, 1/10-1/20 seems to be the sweet spot (you need some security margin due to stretching etc.). Alternatively, you could implement the parsing on the GPU and just read back a very short list of changes per frame.
Shameless advertisement: In the upcoming book GPUPro: Advanced Rendering Techniques there will be two sections on virtual texture mapping, one about accelerating it with CUDA, and one which covers the basics. The latter is written by me (among others), and comes with a sample implementation which you can try out.