SIGGRAPH 2009: Beyond Programmable Shading papers

Also Tim Sweeney's keynote "The End of the GPU Roadmap" at HPG (which was colocated with Siggraph) can be found here:
http://bit.ly/bniNt
Abstract: "Mainstream GPUs emerged 12 years ago and rapidly evolved from fixed-function graphics accelerators to semi-programmable computing devices. The speaker will argue that the GPU roadmap is now coming to an end, and that future PCs and game consoles will be powered by general computing devices, utilizing multi-core vector-processing units to run all code, graphics and non-graphics, uniformly, at Teraflop performance levels. He'll then give an overview of the design dimensions impacting such an architectures, such as caches, threads, vector sizes, and programming models."

Sweet! Thanks.
 
Although I get Tim's point of diminishing returns I have a big problem with his statement that "Crysis on high-end NVIDIA SLI solution only looks at most marginally better than top Xbox 360 games".

Oh and CryTek's presentation looks very promising, especially their new GI.
 
I wonder why Mr. Sweeney likes analytical anti-aliasing so much. An a-buffer is one thing, but a BSP per pixel? Seriously? Just for edge AA? (It's not like say a micropolygon edge is the real edge anyway.)
He seems to be talking more about the level at which it remains accurate, not so much actually having a separate . Then again, I'm going only off the slides here rather than actually going off of an actual talk.

As far as the analytical AA thing, I think that relates to the point he was making about the fact that 1 extra bit of AA accuracy requires twice the hardware. If you can compute the exact coverage region analytically, you're limited by numerical precision rather than how much silicon you can throw at it. Since micropolygons are flat-shaded, the function you're convolving with your AA filter kernel is constant (per micropoly, that is), so the contribution is fairly straightforward to compute.
 
Since micropolygons are flat-shaded, the function you're convolving with your AA filter kernel is constant (per micropoly, that is), so the contribution is fairly straightforward to compute.
Sure, after clipping it against every other visible micropolygon in the pixel. The hidden surface removal requires a 2D BSP (or to use Carmack's classic term, a beam tree).
 
Last edited by a moderator:
Sure, after clipping it against every other visual micropolygon in the pixel. The hidden surface removal requires a 2D BSP (or to use Carmack's classic term, a beam tree).
Maybe I'm not sure what you mean insofar as clipping against micropolygons for each pixel...

You actually don't need to worry so much about the micropolygons that cover a pixel unless you're going to sample by raycasting. You really only need the running sum of the filter weights for all coverage areas that have covered that pixel as you go along. For a rasterizer, the micropolygons only need to worry about which pixels it covers. Basically, if you do a depth pass to determine which micropolygons are visible overall, you only need to draw a micropolygon by simply accumulating its contribution to each pixel that it covers. The weighted sum of all contributions is the color of any given pixel, which you'll get once all the visible micropolys for the scene are actually drawn. On the geometry edges, the total sum of contributions to a pixel will not add up to a weight of 1.0, but it will be premultiplied by the weight you'd use for a lerp against any background layers such as your skybox or whatever.
 
Although I get Tim's point of diminishing returns I have a big problem with his statement that "Crysis on high-end NVIDIA SLI solution only looks at most marginally better than top Xbox 360 games".

Oh and CryTek's presentation looks very promising, especially their new GI.

Meh, the usual trash talk about competitors ignoring functions beyond visuals.. and visuals to (considering you only need high-end SLI for 1080p 4-8xAA). I'll bet they refer to UE3 Gears 2, ME2 etc as the top titles. :LOL:

I also found page 28 interesting regarding "Ran 100% on CPU, No GPU required". However didn't it greatly benefit from Voodo cards and Glide API vs just running in software mode? I remember some effects where limited to PowerVR chips like colored fog which Voodoo chips couldn't handle.

And yep that CE3 GI solution really looks robust.
 
Anyone here interested maybe in doing one or a series of discussions of these papers 'live' for the podcast? Could be interesting.
 
If that's the case then they haven't implemented GI, they've just built some local ambient term to mix with some static ambient. I don't mind hacks, just they shouldn't be called GI when they're not.

Jawed
 
If that's the case then they haven't implemented GI, they've just built some local ambient term to mix with some static ambient. I don't mind hacks, just they shouldn't be called GI when they're not.

Jawed

Well, they're only simulating one bounce, so they'll still need a (dimmer) static ambient to approximate the rest. It seems to me like it should be quite possible to extend the technique to more bounces, but unfortunately the paper doesn't make any mention of it.
 
You actually don't need to worry so much about the micropolygons that cover a pixel unless you're going to sample by raycasting. You really only need the running sum of the filter weights for all coverage areas that have covered that pixel as you go along.
No, you can't do both AA and ignore subpixel visibility ... you get bleedthrough. You can use full subpixel samples (SSAA/MSAA), coverage masks (A-buffer) or BSPs.
Basically, if you do a depth pass to determine which micropolygons are visible overall, you only need to draw a micropolygon by simply accumulating its contribution to each pixel that it covers.
Depth != visibility ... ignoring intersections the topmost micropolygon in a pixel will always be entirely visible but a completely arbitrary part of the bottom most micropolygon in a pixel _might_ always be visible too. Determining the visibility and contribution of a micropolygon is no easier than for a normal polygon.

The advantage of the BSP approach is that you don't get twinkling when there are tiny holes in the geometry, in theory ... a visible micropolygon contributes regardless whether it hits arbitrary subpixel sampling points. Between LOD and dicing changes I think such geometry will still be problematic even with BSPs though.
On the geometry edges, the total sum of contributions to a pixel will not add up to a weight of 1.0, but it will be premultiplied by the weight you'd use for a lerp against any background layers such as your skybox or whatever.
There is absolutely no reason to assume there is a continuous background to a micropolygon, the background might be made up by a million slightly overlapping micropolygons none of which belong to the same surface.
 
Depth != visibility ... ignoring intersections the topmost micropolygon in a pixel will always be entirely visible but a completely arbitrary part of the bottom most micropolygon in a pixel _might_ always be visible too. Determining the visibility and contribution of a micropolygon is no easier than for a normal polygon.
Okay... that's different from the way you made it sound as if you were scanning through the pixels and clipping micropolys pixel-by-pixel as you rendered. As far as I was thinking, the clipping is part of the dicing process for a given frame and is done before you actually rasterize anything, so when you get to the point of actually rasterizing a micropoly, it's already been clipped for every fraction of its visibility. The depth-map role is more or less a broad phase for determining which ones even have parts of themselves visible in the first place.

There is absolutely no reason to assume there is a continuous background to a micropolygon, the background might be made up by a million slightly overlapping micropolygons none of which belong to the same surface.
Hmmm... I think you misunderstood what I was getting at. When I mentioned background layers, I literally meant layers. In much the same way that we currently render skydomes and terrain and things first before rendering anything else, there's no reason to be doing differently just because you have micropoly rasterization or REYES. Indeed, you will quite often construct a scene with several layers in practice, but that's a bit far removed from realtime/games rendering, though it is one way to avert the disasters that may result due to erroneous clipping. Either way, my point was that by the time those other layers are rendered, you don't really have to care how the background is constructed since it is basically a 2d image to the other layers at that point. The case for a particular render pass yielding not-totally-covered or just plain uncovered pixels in its rendered state would be one where that pass is only part of the end result.
 
Last edited by a moderator:
As far as I was thinking, the clipping is part of the dicing process for a given frame and is done before you actually rasterize anything
If you want to do analytical HSR before rasterization you have to use a 3D beam tree instead, that's not really progress.
 
Nvidia's Siggraph slides now up as well:
http://developer.nvidia.com/object/siggraph-2009.html

Highly recommend the 'Alternative Rendering Pipelines in CUDA' talk and the OptiX (old NVIRT) talk.

Love the CUDA SPU-like über-kernels for flexible load balancing of irregular workloads between tasks, exactly the sort of things we want to do for more complex multi-stage techniques although the efficiency doing it in software right now using CUDA is probably not ideal.
 
Carmack and Sweeney.......

Both talk enough but dont make any decent game or game engine. ( May be Id Tech 5 will change my view... ) Not that i have enough knowledge to judge on them............

Would have like if some technical Director from Blizzard and Valve to post a presentation.
 
Last edited by a moderator:
Practicaly every second AA title uses UE3.

Carmack's introducing radicaly new tech that the whole industry follows, in every major engine release: lightmaps, 3D acceleration required, normal mapping, virtual texturing.

So yeah, they don't make anything decent, really.
 
I think Valve is doing good things with the Source engine, it's always evolving. I'm not blown away when i play to HL:Ep2, TF2 or L4D, but it's still good looking and at least it runs very well.
 
Back
Top