Molly Rocket

[casey]

Why is it called "sparse virtual texturing"? Virtual memory is not called "sparse virtual memory". It seems really redundant to me.

If you had called it "sparse texture buffering", then I could understand why you included the "sparse", but otherwise I don't get it.

- Casey

[Won]

Maybe the "S" should stand for "Software," as distinct from most virtual memory systems which have some kind of hardware support. Of course, paged virtual memory didn't always have hardware support, but I believe the TLB was the first cache-like thing added to a CPU.

[casey]

Yeah I'm pretty certain the Mac was still using double dereferenced pointers until like 1996 or something terrible like that

- Casey

[Won]

Hm, I doubt that was a hardware limitation, since the 68030 had an MMU with a 22-entry TLB. I'm guessing it's just the old handle-as-pointer-to-pointer technique before MacOS was designed to take advantage of hardware protected memory. I'm sure Windows went through a similar transition.

[sean]

It's called "sparse virtual texturing" because I needed something to distinguish it from the virtual texturing defined by DirectX 10. That's all. It's totally a fiction in that sense.

So the idea here is that DX10 textures are virtual, but the API knows about the whole texture (even if it's sparsely downloaded); to user code it never looks sparse. Whereas with SVT, the API doesn't know about the whole texture, and the client code does have to know about the sparseness.

Note that I don't think that justifies adding the word "sparse"; to me the SVT approach is the right way of generalizing virtual memory to texturing; putting a virtual memory manager behind a texture sampler is the naive way of doing it. But once I needed a different term, that was the one I came up with.

[ryg]

[TomF]

The main difference from DX10's thing is the granularity - DX10 has to have each entire mipmap in video memory or not. So a better name might be "fine-grained virtual texturing"

Now, "sparse textures" are even cooler. That's where some bits of the texture simply don't exist at some mipmap levels. This is nice for things like shadowbuffers, where you only generate the parts of the mipmap levels you actually need, which is a huge memory and render-time saving.

And then finally there's "lazy sparse textures" (also called "Just In Time textures") where you don't render any part of any textures until you actually need it (i.e. you get a page fault), and then you only render that bit. Excellent for reflection maps.

[Wolf Mathwig]

Maybe the 'S' should stand for 'Sean'...

[sean]

[Won]

Tom's comments about sparse textures reminded me of an older SIGGRAPH paper. It turns out it was called "Adaptive Shadow Maps," but I found some interesting stuff.

http://graphics.cs.ucdavis.edu/~lefohn/work/glift/

In particular, the implementation of "Dynamic Adaptive Shadow Maps 2005" appears to be pretty close to SVTM (although it doesn't try to deal with trilinear).

As it turns out, this guy, Andre Lefohn, founded Neoptica which got bought by Intel recently. My guess is that you RAD guys already knew all that!

[casey]

[sean]

once again, I am totally missing your jokes!

[casey]

I know, I'm losing my mojo!

(The original post was serious, though - I actually did want to know what the deal was with the "sparse". I just threw a joke in there for fun...)

- Casey

[bharris]

The virtual textures in idTech5 actually are sparse. Any pages which aren't used are not even stored on disk. There are the obvious non-used pages (mapping a bunch of non-squares to a square will often create wasted space), but we also use a technique that finds pages which can never be seen during game play (such as the back side of a crate against a wall) and toss those pages out, too.

That being said, in idTech5, they are simply called "virtual textures"

[AndyFirth]

one of these days i'm hoping to get a week or two to play around with this stuff... been reading on here for a while and it sounds interesting and useful.

ah... maybe ... one day... i'll get a week to myself.
_________________
Andy Firth : Engineer Architect, Bungie