|
View previous topic :: View next topic
|
| Author |
Message |
casey
Site Admin
Joined: 18 Dec 2004
Posts: 1768
Location: Seattle
|
| |
 Posted: Fri Feb 22, 2008 3:05 am Post subject: Sparse Virtual Texture Memory |
 |
|
My nagging of Sean for slides / audio / writeup / other goodies from his GDC Lecture begins NOW!
Sean?
And also, now that you've gone through all the details of such a scheme, can you revisit our previous discussion about whether or not it has implications for geometric complexity? Does megatexture impose a cost relative to the texturing only, or is there a per-triangle cost as well?
Etc., etc.
- Casey |
|
| Back to top |
|
 |
sean
Joined: 01 Feb 2005
Posts: 1392
Location: Kirkland WA
|
| |
Posted: Fri Feb 22, 2008 7:43 am Post subject: |
|
|
My official plan is to post all the code and the slides by Sunday the 24th. I may try to find an hour to re-give the talk by then as well, but no promises. (I'd prefer to do it sooner while I still remember it.)
| Quote: | | And also, now that you've gone through all the details of such a scheme, can you revisit our previous discussion about whether or not it has implications for geometric complexity? |
I don't remember what the previous discussion was, but here's what I know right now.
Let's start with a bold hypothetical.
Somehow you need to know which texture data you need. Let's suppose we have an oracle that tells us this magically with no overhead.
In this case, there are absolutely NO geometric implications. It's purely fragment shader and texture management. (There are indirect geometric implications in the sense that the geometry determines what's visible, but there's no cost to, say, further tesselating your object.)
Unfortunately, the current best-known implementation of the oracle is to render the scene first, which obvious incurs you geometric cost. (You might be able to afford reduced LODs at this step, though.) If you want to try a purely analytic oracle, you can avoid this cost, but you'll need to be a lot more conservative and download more data.
But there is no vertex shader work or other per-vertex work, and no cost to changing your tesselation density. |
|
| Back to top |
|
|
casey
Site Admin
Joined: 18 Dec 2004
Posts: 1768
Location: Seattle
|
| |
Posted: Sun Feb 24, 2008 8:44 am Post subject: |
|
|
This post is incorrectly dated.
| sean wrote: | | Unfortunately, the current best-known implementation of the oracle is to render the scene first, which obvious incurs you geometric cost. (You might be able to afford reduced LODs at this step, though.) If you want to try a purely analytic oracle, you can avoid this cost, but you'll need to be a lot more conservative and download more data. |
I see.
So, assuming you don't do any different LOD for the oracle pass, then a svtm scene can afford half the geometry of a non-svtm scene in a primitive-bound scene? And the frame rate would be halved for a fill-rate bound scene? Or can you render at a lower resolution (ie., a quarter screen or something) and still be OK?
- Casey |
|
| Back to top |
|
|
sean
Joined: 01 Feb 2005
Posts: 1392
Location: Kirkland WA
|
| |
Posted: Sun Feb 24, 2008 9:33 am Post subject: |
|
|
This post is incorrectly dated.
| casey wrote: | | So, assuming you don't do any different LOD for the oracle pass, then a svtm scene can afford half the geometry of a non-svtm scene in a primitive-bound scene? And the frame rate would be halved for a fill-rate bound scene? Or can you render at a lower resolution (ie., a quarter screen or something) and still be OK? |
Yeah, you're cutting your geometric complexity in half, to a first approximation. But if you're, say, doing rendering to compute shadows, so you're already rendering everything twice, maybe this is the third render pass, so it's only dropping by a third. (And this is ignoring the possibility that you're using simpler vertex shaders and the like for the first pass.)
It would be nice if you could at least use this first page-ID pass as a 'depth only' pass as well, but assuming you're doing anti-aliasing like all modern games, the page-ID buffer needs to be non-anti-aliased. But I guess if you're doing deferred shading maybe this is awesome, since that has the same issue.
As for fill rate, obviously it's a different pixel shader so the fill rate changes a bunch. I have an implementation that computes it entirely with math, and implementation that uses 1 texture, and I can imagine an implementation that uses 1 2D texture and 2 1D textures that might have very nice performance.
And yeah, you can use a smaller-than-screen buffer; pages are large in texel count, and mipmapping makes them vaguely 1:1 texels to pixels, so I subsample by 64 (8 in each dimension) without any visible artifacts, but my demo has no thin objects at all. I'm comfortable thinking you could definitely rendering at quarter-res (2 in each dimension) basically anything and not get much loss (which I don't mean in a ray-tracing reduced sample sense of 'gee, you can hardly ever see these hideous drop-outs, but rather 'in these corner cases you might a pixel sampling from a mipmap or two coarser than ideal, but it would be hard for that to be noticeable since the object is so thin). |
|
| Back to top |
|
|
TomF
Joined: 18 Feb 2007
Posts: 107
Location: Seattle
|
| |
Posted: Sun Feb 24, 2008 6:07 pm Post subject: |
|
|
I'd love to see a comparison of the memory-use efficiency (ignoring the rendering performance difference) between an analytic version and the true per-pixel feedback version. My experience with the analytic one is that because objects are moving, to page stuff in in time to not have them pop, you need to be very conservative. And because the camera in most games can spin very quickly, you have to ignore the frustum when calculating the analytical measurement.
Taken all together, I'm not sure the per-pixel version is going to work that well on its own - you need a lot of extra heuristics and prediction, not just simple feedback. And once you have that, did the difference between per-pixel and analytic actually give you anything? |
|
| Back to top |
|
|
casey
Site Admin
Joined: 18 Dec 2004
Posts: 1768
Location: Seattle
|
| |
Posted: Sun Feb 24, 2008 6:31 pm Post subject: |
|
|
I had similar thoughts, Tom. It seems like a coarse traversal scheme would actually be better in the end, although obviously more difficult to implement.
- Casey |
|
| Back to top |
|
|
sean
Joined: 01 Feb 2005
Posts: 1392
Location: Kirkland WA
|
| |
Posted: Sun Feb 24, 2008 7:58 pm Post subject: |
|
|
Well, just from the frustum (ignoring occlusion), if we assume you put 100% of your textures through SVT (e.g. indoors), it seems like you'd need 6x the memory if you frustum was 90 x 90 degrees, right? So either you can afford that or not.
I'd be more concerned with the download bandwidth versus your procedural generation bandwidth or disk streaming bandwidth. How many more page downloads per frame does analytic require in particular situations? Does it make the rapid rotation problem better but make some other situation (like moving forward) worse? Probably not (the stuff you don't see when moving forward tends to drop levels), but what about moving backwards or sideways?
Another thing cut from the talk: in the current system, even if you don't have mouselook -- if you don't have high-speed, unpredictable rotation -- you can still force sufficiently high-resolution unique texturing to need lots of textures at high speed, if you have side-stepping. Just move arbitrarily close to a wall, and start side-stepping. The closer you are to the wall, the more pages per frame you'll need. But this case occurs whether you use readback or do it analytically. Of course users don't normally stare at a wall closely and move very fast sideways (except briefly peeking around a corner--but that leads to a worst case for occluded downloading, though). Except, if you're doing it omni-directionally analytically, there's always SOME direction you're sidestepping relative to, so that means just running down a hall you're potentially hitting this case on the left AND on the right. So it means as you run down a hall, with analytic paging, your download bandwidth requirements suddenly change depending how close you are to the wall that you're running along!
(All of which argues for keep using detail textures.) |
|
| Back to top |
|
|
TomF
Joined: 18 Feb 2007
Posts: 107
Location: Seattle
|
| |
Posted: Mon Feb 25, 2008 1:02 am Post subject: |
|
|
| sean wrote: | | what about moving backwards or sideways? |
Since the analytical method I uses totally ignores the view direction except in the case of a tie (i.e. if two textures want loading, load the visible one first), then moving in any direction works the same. I know, I'm being slightly facetious, and there certainly are cases where the analytical one does worse than the per-pixel one (facing a wall behind which is a big landscape is the obvious one).
But I think its peak memory use is never significantly worse, and because of the aggressive prefetching, its peak bandwidth for a given quality is arguably lower, because it fetches stuff earlier. And peak is all you really care about.
Actually, the correct measure is "quality for a fixed bandwidth and memory size", because that's really what we're talking about.
| sean wrote: | | Of course users don't normally stare at a wall closely and move very fast sideways |
No, but they do suddenly open doors and expect the thing on the other side to look good. The analytical system I wrote had to prefetch through doors pretty aggressively to cope with this - if a door was unlocked, we regarded it as always being open, and the visibility traversal (we had a portal system) was purely based on the distance between portals, NOT on whether they were in line of sight - so it's more like an audio propagation model than a visibility one. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Usergroups
Log in
Register
