Molly Rocket

[sean]

[TomF]

You don't have to make those pages exist immediately. You can just resample with a mipmap bias/clamp, use that data this frame, then when the data comes from host/disk/whatever, fill in the page then. We expect just-too-late to be the default mode of operation. You can still load-balance just fine - only fill in X number of pages per frame.

All those instruction timings are fascinating, but why do you care about multiplying absolute coordinates together? BSPing the whole world is a bit 1990s. All you normally do with positions is add and subtract them, and "add rax, rbx" is something like quad-issue on modern cores.

[sean]

Lord knows we never rotate any vectors!

[casey]

[Won]

[sean]

I agree it should let you get away without needing tile padding.

That's nice, but I'm not sure it's actually that big a deal.

Edit: I guess I come off as too negative-nancy here, but basically, since SVT basically just works if you do pad and do have gradients, and there are some grey issues with Larrabee's advantages, it doesn't seem totally huge. Clearly a bunch of complexity is thrown out if you can use native pages and not have to fake the pages yourself, etc. So e.g. 16-tap anisotropy without needing tiles padded by 8 samples all around, that's probably great, and you don't need two copies of the mipmaps so maybe you save another 25% there.

Except nobody's actually sat down and implemented it, so does it really work? What do you do on a page miss caused by significant anisotropy? You still have to drop the mip level of the whole sample, right? Is the cache writing viable? What's the Larrabee page size, and is it as effective a size as you can do by hand? Etc.

So, from a practical standpoint, it seems like all the "workarounds" for the classic GPU just work, and maybe Larrabee is simpler on some fronts but more complex on other fronts. It will almost certainly save memory usage and instruction count, but not necessarily a meaningful amount in practice in a complex shader.

[jeffatrad]

I think the problem is that it's difficult to talk about the specifics of why LRB will be good for this, when we can only speak in generalities. This is lame (especially in this case), when you know your technique very well and just want to know the exact ways it will be better instead of platitudes.

The general reason why I think this will be a good LRB situation is that I feel like there are lots of corner cases that you need to handle once you roll out SVT in the large. This is awkward with the standard GPU model since you have to figure out ways to make the fixes for the corner cases affect just those areas. LRB allows you to handle those types of issues better, imo, since hey, it's just normal C code.

It's kind of like the pattern matching model in C++ templates. Yes, you can make cool things like Boost once you handle all the weirdnesses with counter rules and specializtion tricks, but it's never not awkward. And you chafe in all the places where you just want to write want you want directly instead of trying to figure out how to phrase it in terms of how the compiler is going to match against your templates definitions.

So, in your and JohnC's case, you have done all the neavy lifting to handle the weirdnesses that you have encountered so far, but when I hear about the crazy lengths you have to go to, my intuition just says that a more programmable and customizable system is going to make this massively more robust, faster and simpler.

But that's just intuition (about something I can't talk about in specifics in relation to an area that I haven't written any code for), while you have real world experience, so I dunno. <grin> In a few weeks, you'll be able to make the call yourself, I suppose...

->Jeff

[TomF]

I think from the replies here that we're talking at cross-purposes some of the time - probably because of a misunderstanding about what the hardware does and doesn't do. I can't actually give you the hardware spec - I like my balls where they are - so you might have to read between the lines a bit here.

But software I can totally talk about. As of last Monday the gloves are off, and I'm doing a talk at Siggraph on Thursday that mentions all this stuff (though it's only 20 minutes, so it doesn't go into this sort of detail).