[sqrt[-1]]

From:
http://developer.amd.com/SAMPLES/DEM...TimeDemos.aspx

"Specifically, this demo uses DirectCompute to cull and manage lights in a scene. The end result is a per-pixel or per-tile list of lights that forward-render based shaders use for lighting each pixel. This technique also allows for adding one bounce global illumination effects by spawning virtual point light sources where light strikes a surface. Finally, the lighting in this demo is physically based in that it is fully HDR and the material and reflection models take advantage of the ALU power of the AMD Radeon HD 7900 GPU to calculate physically accurate light and surface interactions (multiple BRDF equations, realistic use of index of refraction, absorption based on wavelength for metals, etc)."

So is this an update on the technique I used in my light indexed deferred rendering demo - or is it something else entirely? The per-tile list of lights could be similar to Uncharted lighting (I noticed that a few other presentations at GDC used computer shaders and tiled lighting)

I wonder if they have found a new novel way of supporting different light types in such a scheme? (The main problem with light indexed deferred rendering)

I assume there will be a Siggraph/GDC presentation on this - but any speculation is welcome.

[MJP]

It does sound like light-indexed deferred rendering, or something very similar. It would be pretty easy to implement with compute shader tile calculation, or with DX11.1 logical blend operations.

[Ike Turner]

FYI: The demo works on all DX11 Radeon cards (Cyrpess, Cayman etc..).

[KKRT]

How's performance of this demo?

[Ike Turner]

Originally Posted by KKRT

How's performance of this demo?

I'm guesstimating between 20-25fps on a 5870 @1680x1050 with 2xMSAA

[Lightman]

Originally Posted by KKRT

How's performance of this demo?

22-30FPS on HD6970 with majority around 25FPS

[KKRT]

Originally Posted by Lightman

22-30FPS on HD6970 with majority around 25FPS

Thats pretty bad, now i'm curious how similar 7xxx card will perform.

[gongo]

Originally Posted by Lightman

22-30FPS on HD6970 with majority around 25FPS

same here....what graphics features does HD7970 adds? pretty hard to tell these days...BUT the shaders aliasing...jaggies...textures shimmering...you know those IQ eyesores...still very prevalent even if i was running at ...1080p ..forcing 8xEQAA...morphoric AA on/off...16xAF through CCC...the chains of bridge...the greenies...the stove...the camera edges...the door handle...the dragon jaws...all breaking the illusion of "CGI-in-realtime" graphics..

i wonder will the day finally come when these go away..imho these artifacts are still a problem to reach that "CGI-in-realtime" graphics...

[AlphaWolf]

Originally Posted by KKRT

Thats pretty bad, now i'm curious how similar 7xxx card will perform.

Someone on hardforums said 40FPS @ 1920x1200 8xAA with a 7970 running at 1125Mhz.

[rpg.314]

Originally Posted by gongo

same here....what graphics features does HD7970 adds? pretty hard to tell these days...BUT the shaders aliasing...jaggies...textures shimmering...you know those IQ eyesores...still very prevalent even if i was running at ...1080p ..forcing 8xEQAA...morphoric AA on/off...16xAF through CCC...the chains of bridge...the greenies...the stove...the camera edges...the door handle...the dragon jaws...all breaking the illusion of "CGI-in-realtime" graphics..

i wonder will the day finally come when these go away..imho these artifacts are still a problem to reach that "CGI-in-realtime" graphics...

You want CGI like quality, then push for IHVs to add support for REYES as well.

[sqrt[-1]]

So how does the real demo compare to the 1080p video posted - I can't run the demo and was quite impressed by the video. (or perhaps I am less sensitive to these artifacts)

[gongo]

Originally Posted by rpg.314

You want CGI like quality, then push for IHVs to add support for REYES as well.

Will REYES get rid of those aliasing? There are so much computing...teraflops...on the table now...but the age old artifacts are still present..What do you mean by ....'supporting' REYES?

Originally Posted by sqrt[-1]

So how does the real demo compare to the 1080p video posted - I can't run the demo and was quite impressed by the video. (or perhaps I am less sensitive to these artifacts)

Looks worse man...visible aliasing clearly distracted me..video could pass of as old CGI...

[ToTTenTranz]

Originally Posted by gongo

same here....what graphics features does HD7970 adds? pretty hard to tell these days...BUT the shaders aliasing...jaggies...textures shimmering...you know those IQ eyesores...still very prevalent even if i was running at ...1080p ..forcing 8xEQAA...morphoric AA on/off...16xAF through CCC...the chains of bridge...the greenies...the stove...the camera edges...the door handle...the dragon jaws...all breaking the illusion of "CGI-in-realtime" graphics..

i wonder will the day finally come when these go away..imho these artifacts are still a problem to reach that "CGI-in-realtime" graphics...

Try a FXAA injector.
(I'm not sure it works on DX11 though, so sorry if that was too stupid.)

[rpg.314]

Originally Posted by gongo

Will REYES get rid of those aliasing?

Watch a PIxar movie and find out.

Originally Posted by gongo

What do you mean by ....'supporting' REYES?

Implement a REYES pipeline as well, along with DX11. Making DX microtriangle friendly would be a start.

[CNCAddict]

Will it be a REYES type system or some form of pathtracing that makes it into a marketable game first? Seems like with the brigade 2 engine we already have an unbiased pathtracing game with no aliasing; but tons of noise. The noise will get better with future hardware and algorithms.

http://igad.nhtv.nl/~bikker/

[rpg.314]

No idea, and probably neither with ff hw. But I'd rather have REYES first.

Seems like with the brigade 2 engine we already have an unbiased pathtracing game with no aliasing; but tons of noise. The noise will get better with future hardware and algorithms.

Not any time soon.

http://www.beyond3d.com/content/articles/94/

[hoho]

Originally Posted by rpg.314

Watch a PIxar movie and find out.

From what I've understood they get rid of aliasing by massive oversampling. If you render at exactly the output resolution you'd get just as jaggy image as with regular rendering methods.

[jlippo]

Originally Posted by hoho

From what I've understood they get rid of aliasing by massive oversampling. If you render at exactly the output resolution you'd get just as jaggy image as with regular rendering methods.

REYES uses stochastic sampling and oversampling to get rid of edge aliasing.

It's quite cheap in REYES as you basically supersample a solid/goraud colored polygon patches. (REYES calculates all shaders into colors on micro polygons/vertexes before it actually renders the image.)
http://www.renderman.org/RMR/st/PRMa..._In_PRMan.html

For shader aliasing the preferred cure is to fix the shader itself. (supersampling, LoD, prefiltering and so on.)

[Andrew Lauritzen]

Move this from the other thread as it fits more naturally with the discussion here:

Originally Posted by fellix

Isn't that similar to how Frostbite 2.0 generally occludes the lit surfaces, with tiled screen-space and running a compute shader pass ahead?

Yes it's exactly the same, it's just instead of storing the surface data that you need to do lighting, you regenerate it in a second geometry pass. The cost you pay (in addition to the second geometry pass) is storing the lighting lists. Given that they need to store them in this case, I hope they are storing a hierarchical tree instead of a raw list/bitfield for each tile but I somehow doubt that they are... It's not really that interesting a question, because you simply compute or test whether it's faster to store the lighting data or surface data, and do whatever works best.

Honestly the "differences" between deferred and forward are not worth discussing these days. It's a big grey area of application-dependent performance considerations. Even generalizations like "forward can do more complex materials" or "deferred can do more lights" are simply incorrect. I guess it's normal for the media discussion to lag the technology by 3-5 years, but it's somewhat tiresome.

The interesting discussion today has nothing to do with lighting or G-buffers or anything else, but rather the shading efficiency of the immediate-mode 3D pipeline, particularly for small triangles and with varying AA techniques (MSAA, SSAA, surface-based deferred AA). That's the most interesting thing about "rescheduling" computation in image space using compute shaders, not that you can save some memory bandwidth by storing the light lists in local memory vs. VRAM or anything else that can be decided by a simple performance test.

Neat demo though. I wish they had used LEAN mapping or something to get rid of the specular shimmering, but otherwise it's quite clean looking.

[ToTTenTranz]

So why is FXAA really out of question?

[Andrew Lauritzen]

Originally Posted by ToTTenTranz

So why is FXAA really out of question?

What do you mean?

[ToTTenTranz]

Originally Posted by Andrew Lauritzen

What do you mean?

To solve gongo's complaints:

Originally Posted by gongo

same here....what graphics features does HD7970 adds? pretty hard to tell these days...BUT the shaders aliasing...jaggies...textures shimmering...you know those IQ eyesores...still very prevalent even if i was running at ...1080p ..forcing 8xEQAA...morphoric AA on/off...16xAF through CCC...the chains of bridge...the greenies...the stove...the camera edges...the door handle...the dragon jaws...all breaking the illusion of "CGI-in-realtime" graphics..

i wonder will the day finally come when these go away..imho these artifacts are still a problem to reach that "CGI-in-realtime" graphics...

I've been using FXAA in some games and it seems to do a very good job at reducing the jaggies from shaded surfaces and shimmering textures...

[Andrew Lauritzen]

Originally Posted by ToTTenTranz

I've been using FXAA in some games and it seems to do a very good job at reducing the jaggies from shaded surfaces and shimmering textures...

It's doesn't solve the root cause. You need to fix the shaders (prefiltering, etc) to address undersampling of terms like specular, etc. FXAA/MSAA won't help. SSAA (via MSAA and sample-frequency execution) will help somewhat but it's pretty brute force.

People need to stop asking about hardware "features" these days. More relevant, we just need more performance to use better data structures and algorithms to solve the issues. 7970 delivers pretty decently on that in my limited experience. It certainly enables you to do stuff like use LEAN mapping (with its fairly large increase in texture footprint for instance) on most/all surfaces without being too worried about tanking your frame-rate. It's a very fast card.

[Frenetic Pony]

Originally Posted by Andrew Lauritzen

It's doesn't solve the root cause. You need to fix the shaders (prefiltering, etc) to address undersampling of terms like specular, etc. FXAA/MSAA won't help. SSAA (via MSAA and sample-frequency execution) will help somewhat but it's pretty brute force.

People need to stop asking about hardware "features" these days. More relevant, we just need more performance to use better data structures and algorithms to solve the issues. 7970 delivers pretty decently on that in my limited experience. It certainly enables you to do stuff like use LEAN mapping (with its fairly large increase in texture footprint for instance) on most/all surfaces without being too worried about tanking your frame-rate. It's a very fast card.

Of course post process AA helps! Not by much, but you can see it qualitatively, and so it helps. You take what you can get, for the least amount of milliseconds possible. Sure it would be nicer to pre-filter and run at 64x super sample and etc. And any research into do any of that faster is most welcome, but games need to ship and if FXAA is what you have at the moment then you may as well take it.

But further research does indeed need to go into a more "root cause" solution. Post process AA probably doesn't have much more in the way to offer in terms of visual quality than what's already out.

Further, there is one last thing in terms of hardware features that I'd say most people would like to see, or two things really. Eliminating the messy API stuff, if somehow possible. And much better hardware texture compression. Block compression is very nice, but can still be improved, better quality/less bits means more available ram for everyone without console manufacturers or consumers having to pony up more dough. A win for everyone really.

[Frenetic Pony]

As for the demo, I don't really see the benefit to this for a next gen renderer. I suppose I can see that if you've got the tiled lightlist for deffered shading anyway, you've got the framework/etc. you could re-use for forward rendering transparency. But forward rendering the entire thing doesn't really seem beneficial. Even if you want to do msaa, there's already a nice production ready technique/paper out on reducing the cost for msaa and deffered shading.