Molly Rocket

[Won]

Sean shows Carmack's simple 3-instruction bilinear fragment program that results from using a floating-point page map. It would be totally reasonable to do everything with 32-bit floats. 16-bit floats might be nice, but those are kind of a pain to deal with on the software side.

On the other hand, you probably never have to deal with that. A different way to update your page map would be to use render-to-texture (which could be whatever format, including 16-bit floats), and use floating-point colors and quads/points to fill in your page map levels. Going back-to-front with painter's is probably good enough, but maybe you'd use the depth buffer to go front-to-back, which might help when filling your finer levels with coarser values. Anyway, this would be totally cheap, and maybe makes looping in the pixel shader for mipmap substitution unnecessary.

You could also easily double-buffer (or n-buffer for multi-GPU) page map rendering so that your frame rendering doesn't have to wait.

[sean]

I'm not sure what you're picturing doing. Every frame, for every physical page, you're going to draw one-quad-per-mip-level for that page? I guess that works... how many physical pages do you have? Hmm, assume a 4K x 2K physical texture, then for 256x256 page, only 128 quads. For 128x128, 512. THen multiply those by mip levels, say 10, so 1280 or 5120 quads. I guess that's not too bad.

The problem is your page tables can be huge. I can reasonable run with 4K x 4K page tables. I can reasonable run with multiples of them. The only real constraint on total page virtual pages is the size of texture memory to store page table texels. So going to floats reduces the maximum virtual texels you can have, double-buffering them is another hit, and rebuilding them by painter's rendering seems like a pretty significant fill-rate hit.

The depth-buffered approach is cooler because you could actually incrementally update that, probably z compare one way when unmapping, then z compare the other way when mapping. (So batch all the unmaps and then all the maps, obviously.)

I'm not sure if 16-bit floats in the page table will provide enough accuracy to do the bilinear 'contraction' operation. Maybe so, though. As long as physical pages are power-of-two texels, I think everything but the contraction is actually a power of two, and the contraction is then a ratio like '124/128', which is exactly representable in FP.

[Won]

And when you start to think of the page map as a thing to directly manipulate, then other interesting ideas crop up. For example, something like Wang tiles (or the new hotness, corner tiles: http://www.cs.kuleuven.ac.be/~graph...VersusColoredCorners/) become a bit more straightforward (assuming you can do something about the edge padding).

You could share common tiles. Like, if you're rendering something that is mostly a background color, the background-color tile can be shared at many virtual offsets, even in different mipmap levels, or entirely different textures. This could really come in handy for a texture painter. You could do something weird and fractal-ly with limited storage.

[sean]

Yeah, another thing in the rough draft of the talk that got cut was I mentioned you could do things like slightly varied instances or baked-decals by having multiple SVTs (or packed together in one) that shared the physical memory for all the identical parts.

You could do the Wang tile stuff... that's a bit like stuff I talked about in one of my GDMag articles that I've never put online (in Oct 2004!), the idea of doing procedural texture "bombing" in the shader by sampling from an index table that tells you what decal overlaps a given texel, and all the decals are packed together in another texture. (I didn't implement that, I implemented something simpler.)

The Wang tiles basically require you have a standard set of edge pixels anyway, so the padding just forces you to have two standard edge pixels or some such.

The problem with these things is they mismatch with mipmapping the page table. You'd need to start packing multiple tiles into one page as you mipmap up. Which blows out the number of possible combinations. You could not mipmap the page table, and just mipmap the tiles, but now you have a more significant padding problem... at every mip level you need a couple texels in common across the boundary; plus your texture samples becomes more incoherent (poor performing) the coarser and coarser the mipmaps are.

[Won]

Them pages tables can big, but a 4k x 4k page table seems pretty big, since you're not leaving too much room for your actual texture. With 240 pixel tiles, that's...calculating...a pixel per square inch for a 240 sq mi area (weird numerical coincidence? did I screw something up?).

1k by 1k might be a more reasonable size, especially considering that fast depth has a resolution limit. Hm, does fast Z even work on RTT?

Anyway, I'm just brainstorming out loud here.

[Won]

Well, you could just use Wang tiles to do detail texturing, in which case the mipmapping issue is somewhat mooted. But, you hardly need SVTM to do detail texturing, anyway.

The baked decal idea reminds me of a suggestion I gave a friend once about text rendering in OpenGL. He wasn't happy with the performance, so I suggested something that was like a super-dumb version of SVTM. It didn't have to deal with texture filtering or faulting since it was sampled 1:1 and the font atlas easily fit in texture memory. The neat thing was that the "page map" was just the text string he wanted to render.

[sylvan]

Two other ways of doing it:

* Render to UV space. I.e. render to a texture that's the same size as the page table (small, hopefully), and output the page coordinate in the VS, then in the PS you output the mip level, and use a MIN blending mode. You can possibly hack things like occlusion by projecting polygons through the near plane or something.

* If you're developing on Xbox 360, just write out the page fault in the actual rendering shader (using memory export). Let the page table be a 4 component texture (two coordinates, one mip level, and one "page fault"), and just write out into this page fault component if the required MIP is smaller than the current value. This will lead to coherency issues, but they are benign, as you're at least guaranteed that the value will never increase, it will always get smaller. This means that you will, every now and then, have to artificially bump this value up a bit just to see if the page is still in use (i.e. bump it up, and if it didn't get bumped down again during rendering, you can bump it up another level next frame, keep going until you run out of mip levels - when you need a new page just grab the one with the largest positive discrepancy between "loaded" and "required").