Molly Rocket

[BrianKaris]

Sean,
I am trying to implement the fastest version of these shaders. While digging through your notes I found this piece of code labeled as the simplest trilinear shader.

[sean]

I believe I just sketched that out quickly, based on Carmack's bilinear one, so it's buggy.

I'm not sure what the intention was, precisely. What I was trying to do, I believe, is use a texture that's the same resolution as the page table (since that's the limit to how far you can mipmap anyway, the same # of mipmap levels as the page table). However, you need to rescale the texture coordinates to force that texture to trilerp in the right way, so I'm not sure what I was thinking when I sampled tex1 by the vtc, instead of vtc*PAGESIZE (which would require another instruction).

The output of the "LOD-computing-texture" will be, abstractly, a number from 0..16 (whatever the max # of mipmaps is), with fractional values representing the amount of lerp between the mip levels. However, I believe I was assuming that, for efficiency, it was coming from an 8-bit texture so it's actually a number from [0,1], so it needs to be multipled by 16 (or whatever number of mipmaps).

However, what we want to hand to the final TXL instruction needs to just be a lerp factor from [0..1] (because the physical texture only has 2 mipmaps), so the idea is that you store the (integer) level in the page table, in the w field.

So the actual texture LOD level should be:
.... lod = phys.w*16 - p.w

So you actually store p.w negated in tex0, and I end up with:

[BrianKaris]

Yeah, you are right. I keep forgetting that the page table points to pages of different scales. I've made that same mistake a few times already .

For the 2x2 texture my thinking is that all you need is that 0 to 1 lod factor. That should only need a mip texture with 2 levels so long as its sampled correctly. As you point out I would only sample it correctly for pages at full resolution.

As far as changing that scaling with p.w not only would that have problems on the boundaries it also introduces another level of dependency.

Your new code looks good to me. I don't see any obvious ways to simplify it further. The extra mul instruction will probably be masked in the dependent read so it shouldn't make much difference. What is stored in this mip texture looks to be the same as what you would use in the pass to find what pages to load. With a reasonably sized page table this looks like definitely the way to go.

[sean]

Actually, I believe somebody else (here?) suggested that the lod-computing texture can be a lot smaller.

The idea is that, say your page table size is 1024x1024, so theoretically your mip-level-computing texture tex1 needs to be 1024x1024 as well (and you scale up the original coordinates by the page size (Edit: used to say "page table size")).

I believe the trick is that the way mipmapping math is defined, if you use a 2D texture that is 1024x1, then obviously the mipmapping works correctly along one axis. If you scale the other texture coordinate by 1024 before sampling, that will cause the other texture coordinate to also trigger the appropriate mipmapping.

You can think of this by figuring that the way it normally works to mipmap a, say, 1024x128 texture is to compute the mipmapping for the s paramter 'normally', and for the t parameter by dividing the t coordinate by 8 (or, equivalently, just bumping the lod computed for t down by 3). So even though once you hit 1-pixel in a given axis, so that axis shouldn't really have *any* mipmapping effect anymore, the same math is still applied.

(It's possible some hardware might not allow a 1024x1 texture, e.g. you can't have that large an aspect ratio? If so, you might have to use a 1024x8 or something like that.)

[BrianKaris]

Yeah, I read that but I wasn't clear what happened when the scales of s and t weren't the same or if there was sheering. What you described sounds like it should handle those cases fine.

If you need a page id texture that is the size of the page table for the find needed pages pass, it can have this info in it to. It would be sampled then by vtc and not vtc * vPageSize but the same texture can be used.

For the next 2 weeks or so I don't have time to start work on implementing this stuff so until them I'm just doing research. Once I have my hands dirty I should be able to talk about this with a lot less uncertainty.

Thanks for the help.