DEMO: Deferred Shading
Works great on my P4 2.4, X800XT. Framerate is somwehere along 130-200 fps, and thanks for sharing!
Author
Thank you all guys for feedback!
It "should" benefit even in my simple scene - really.
If you enable stencil-clipping preview mode you can see how many pixels are not lit by each single light. Just take a look at this:
[ Scene rendered normally ]
[ Scene rendered in stencil-preview mode (<j> key in the demo) - lit pixels are marked with green color ]
Green lines enclose light's bounding volume. As you can see, there are a lot less lit pixels than those which fit within light's volume screen space bounding shape. Of course it heavily depends on viewing angle, viewer position and sorrounding geometry, but in overall it should be a good optimization - however on GeForce 6600 TD I even get slightly worse performance with stencil clipping enabled.
Just fixed FPS calculation.
Your frame rate is a little surprise to me, because on GeForce 6600 I get between 30-40 (with default settings) and my card shouldn't be twice slower.
[Edited by - MickeyMouse on July 19, 2005 12:02:17 PM]
Quote:Original post by b34rQuote:Original post by MickeyMouse
Do you suggest I might somehow not benefit from stencil culling (that is the pixel shader is executed for culled pixels too)? What parameters and tweaks do you mean?
I cannot try the demo but judging from your screenshot the test scene is not going to benefit from stencil test since even with a simple zbuffer based rejection the number of false hit will stay fairly low. That's assuming you shade if greater than Z when outside the volume and shade when less than when inside it.
It "should" benefit even in my simple scene - really.
If you enable stencil-clipping preview mode you can see how many pixels are not lit by each single light. Just take a look at this:
[ Scene rendered normally ]
[ Scene rendered in stencil-preview mode (<j> key in the demo) - lit pixels are marked with green color ]
Green lines enclose light's bounding volume. As you can see, there are a lot less lit pixels than those which fit within light's volume screen space bounding shape. Of course it heavily depends on viewing angle, viewer position and sorrounding geometry, but in overall it should be a good optimization - however on GeForce 6600 TD I even get slightly worse performance with stencil clipping enabled.
Quote:Original post by NoodleizzeR
With the information off the framerate changes very quickly and its hard get an exact reading
Just fixed FPS calculation.
Quote:Original post by Konfusius
I renamed the d3dx dll and got ~85 Frames with default options.
Specs:
Sempron 2600+
512 MB DDR2 Memory/333 MHz
Radeon 9800 Pro 128 MB.
Your frame rate is a little surprise to me, because on GeForce 6600 I get between 30-40 (with default settings) and my card shouldn't be twice slower.
[Edited by - MickeyMouse on July 19, 2005 12:02:17 PM]
Quote:Original post by MickeyMouse
Your frame rate is a little surprise to me, because on GeForce 6600 I get between 30-40 (with default settings) and my card shouldn't be twice slower.
Make sure to ONLY profile in Release mode and with the RELEASE mode DirectX DLLs! From my understanding of his renaming, he's using the latter while your using the DirectX Debug DLLs.
Still, the 9800 is a pretty fast card and it wouldn't surprise me if it was able to run this type of rendering at a much faster speed.
With all lights on and specular enabled I get slightly over 100fps on my GeForce6 Ultra. I get around 120 fps without specular. The deferred renderer also runs twice as fast as the forward renderer (due to the large number of lights).
Author
Quote:Original post by blue_knight
With all lights on and specular enabled I get slightly over 100fps on my GeForce6 Ultra. I get around 120 fps without specular. The deferred renderer also runs twice as fast as the forward renderer (due to the large number of lights).
Yes, forward renderer is more of a quality comparison for deferred renderer. It's not optimized at all from geometry point of view like finding only closest objects in the scene which is a must for every considerable forward renderer. The only optimization it uses is scissor test, which saves huge amount of fill rate in my case.
Regarding the debug and release D3D versions - the version that is currently to download is compiled in release mode of D3D. The performance on my machine stays the same though.
For what you are doing, the easiest way to get stencil culling to work is to do the following.
a) don't change your stencil test, mask or reference value during the frame, you can enable and disable stencil though. In other words, do it like stencil shadow volumes.
b) don't ever write stencil while testing stencil. For instance, it's faster to do a separate stencil clear that it is to clear a stencil value after testing it
c) be sure to clear stencil at least once each frame
If these things don't fix it, let me know.
a) don't change your stencil test, mask or reference value during the frame, you can enable and disable stencil though. In other words, do it like stencil shadow volumes.
b) don't ever write stencil while testing stencil. For instance, it's faster to do a separate stencil clear that it is to clear a stencil value after testing it
c) be sure to clear stencil at least once each frame
If these things don't fix it, let me know.
First, thanks for sharing, and good work!
I spent the last year working on a deferred renderer, which will be used in a few soon-to-be-released games, so i thought i could contribute to this thread.
We're having the exact same problem. It affects the 6600 series, does not happen on 6800s! We've submitted a test-case to the nvidia test labs a few weeks ago, if you're interested, i can share the feedback when they get back to us. As i observed it's got to do with the order of allocations (as you already mentioned), but on the size of the target, too! A few pixels (like 2-4) difference can suddenly "click" it back to normal operation. I recommend using the NVPerfHUD tool - it's very obvious on the graphs when something's wrong.
Another thing, a recommendation, based on my findings: dont rely on packing floats to r8g8b8a8 quads (or anything similar). It's not very precise, and differs from vendor to vendor - i could never get it "right". (and i _have_ tried - it was just never robust enough)
I spent the last year working on a deferred renderer, which will be used in a few soon-to-be-released games, so i thought i could contribute to this thread.
Quote:Original post by MickeyMouse
Your frame rate is a little surprise to me, because on GeForce 6600 I get between 30-40 (with default settings) and my card shouldn't be twice slower.
We're having the exact same problem. It affects the 6600 series, does not happen on 6800s! We've submitted a test-case to the nvidia test labs a few weeks ago, if you're interested, i can share the feedback when they get back to us. As i observed it's got to do with the order of allocations (as you already mentioned), but on the size of the target, too! A few pixels (like 2-4) difference can suddenly "click" it back to normal operation. I recommend using the NVPerfHUD tool - it's very obvious on the graphs when something's wrong.
Another thing, a recommendation, based on my findings: dont rely on packing floats to r8g8b8a8 quads (or anything similar). It's not very precise, and differs from vendor to vendor - i could never get it "right". (and i _have_ tried - it was just never robust enough)
Author
Thanks for your tips rept,
I used it a bit while working on this demo, but the graphs didn't really help mu much - I just see the graphs sometime jump with no real reason. My app is too simple to be software bound and the bottleneck is obviously in the drivers.
As I switch to new rendering mode (and so release 4 old render targets and create 4 new ones) the FPS usually jumps up for few times (the more fill rate, the more jumpy it is), then after some time it's more or less stable - depends on real fill rate. Here's quite typical shot from the NVPerfHUD graphs after switching to new rendering mode:
@SimmerD
I'll try your hints soon. They look like some dirty hacks implemented by NVIDIA especially for John Carmack, aren't they? ;-)
Quote:Original post by rept
I recommend using the NVPerfHUD tool - it's very obvious on the graphs when something's wrong.
I used it a bit while working on this demo, but the graphs didn't really help mu much - I just see the graphs sometime jump with no real reason. My app is too simple to be software bound and the bottleneck is obviously in the drivers.
As I switch to new rendering mode (and so release 4 old render targets and create 4 new ones) the FPS usually jumps up for few times (the more fill rate, the more jumpy it is), then after some time it's more or less stable - depends on real fill rate. Here's quite typical shot from the NVPerfHUD graphs after switching to new rendering mode:
@SimmerD
I'll try your hints soon. They look like some dirty hacks implemented by NVIDIA especially for John Carmack, aren't they? ;-)
Worked great, 100+ fps with deferred shading at good quality, 50+ fps with forward shading.
AMD Athlon XP 2800+
1 GB PC 3200 memory
AGP 8X ATI Radeon 9800 Pro 128 mb
AMD Athlon XP 2800+
1 GB PC 3200 memory
AGP 8X ATI Radeon 9800 Pro 128 mb
MickeyMouse,
that "spiky" graph is the problem - it shouldnt be like that, and it's definitely not like that on 6800s. switch to windowed mode, and try resizing the window, sooner or later it will stabilize itself. almost randomly, i'd say, thats why we asked nvidia's help with it.
that "spiky" graph is the problem - it shouldnt be like that, and it's definitely not like that on 6800s. switch to windowed mode, and try resizing the window, sooner or later it will stabilize itself. almost randomly, i'd say, thats why we asked nvidia's help with it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
