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.

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