Deferred rendering is not a ‘high end’ technique, SM2 is a reasonable target for deferred rendering, and arguably HDR. Any SM3 board is viable (so pretty much anything under 5 years old), the question is more about engine architecture and content. Unity’s deferred renderer is very new, not even released, so I’m not surprised that it’s not performing up to par. This demo does seem to run a slower than it should, not sure why, but looking at it in NVPerfHud the lighting shader did seem more complicated than it should be, and other things that strike me as bad, but those shouldn’t have any real impact on this scene. Hopefully they’ll allow us to replace the lighting shader, with deferred rendering, that’s very reasonable and will not suffer from shaderlab’s shortcomings. I’d mark the performance issues you see up to it being in testing, then bitch if it’s still slow on release :).
What matters most is that in real scenes you should experience minimal impact from adding more lights, adding many surface modifications and effects won’t require new shader permutations, and significant improvements for outdoor stuff. This particular scene is kindof a worst case example for deferred rendering, only the floor and ceiling really benefit, and they’re thrown out in forward renderer. But if doing an outdoor scene, you have the ability to do, say, image based environment lighting with cloud shadows as one screen pass, and the complexity of the terrain won’t affect it (so adding lit, projected decals isn’t an issue).
In the end it’s not about pure performance gains on simple scenes, it’s about allowing you to produce scenes with complex surface pixels and effects that would be a nightmare to develop in a forward renderer (especially a hand coded one like Unity’s) and have an unacceptably slow and inconsistent frame rate. At this point you can develop your scenes with deferred rendering as your target if not doing Wii/iphone, then just let it look bad in forward rendering mode (people with hardware that old don’t care how your game looks, or likely can’t buy it anyways).
The hardware hint was not about who can technically run it but who you would normally target with a deferred path and the associated content
you don’t push low end visuals into deferred just for the sake of having lower requirements, at least not unless its a game that uses realtime lights and shadows as a fundamental game play element where it might work out better
And yeah I expect it to get faster. Aside of the invisible shaders (not exposed in any way) most seem to be autoupgraded ones which have little to no chance to run anything but worse due to being suboptimal to nightmarish with the surface shader system.
Also if you go for deferred, expecting at least SM3 if not higher is a given (sm2 systems could potentially do it but the vast majority of SM2 cards neither have the bandwidth nor fillrate to pull off deferred with light shadow calculations at all. depending on the effects used that though also holds for half the SM3 cards and nearly all intel cpu to dvi adapters), so the shaders you use in your game can correspondingly be opted for SM3 targets in case of the deferred path
Lots of optimization and flexibility there in that environment and I’m looking forward to lose sanity while working with and fighting against it
Right, and that’s SM3, not SM4. There have been a decent number of games that have used it, good looking ones, and targeted at SM3. It’s natural for software to lag behind hardware since clearly the hardware needs to hit first, so keep that in mind, just because you’re seeing a new technique doesn’t mean it needs new hardware. Heck, Stalker was out in early 2007 and was in development for a while, early work was likely done on SM2 hardware. ATI cards were capable of doing it, they had the fill rate (I got good results on 9800s, maybe acceptable on 9500), but I wouldn’t have advised it on NVidia boards, their SM2 crop sucked, hard.
Hehe, I might be overly optimistic, but I’m looking forward to it. As long as I have sufficient access to lighting shaders and lighting terms, I think that’ll mitigate my shaderlab woes since I could do a lot of cool stuff with that, and not have the permutation issues.
True, but we talk about Unity here, not CryTek and not some 50 programmer teams like the team behind starlker, so the comparision should be brought back into the scale of what we use and pay for what we use.
Also UT offers support for more than just highend, so any attempt to bring leadwerks highest end only engine onto the plate is assumed to fail too
I don’t expect to see deferred running performant on anything older than GeForce 7600+ / Radeon 3800+ as more than a still rendering at all (and no intel as a matter of facts)
I’m aware that the software lacks behind tech normally. But neither stalker nor crysis did, they were on generation at their release and thus 2-3 years ahead of mainstream usability.
Stalker for shit end cards has a hybrid / forwad approach, doesn’t it, similar to crysis.
The full deferred mode is only used on high and ultra settings not on those settings that run below high end SM3 SM4 cards. Crysis as a matter of fact disables those quality settings completely if you approach it with such a joke GPU and has some stuff cut if you are not running it in DX10 mode at all.
In the end it should be pretty much no problem at all though, should it.
For 2 years even integrated were dx10 capable, the majority happily was no longer intel and even if, they can thanks to UTs desire to support broad not high end only, still fallback to forward rendering.
that will cost them stuff like point based light shadows and alike which in U3 are cut from the forward rendering but if a system had to fallback to forward it wouldn’t want to have them anyway
at least for the lighting we know we have, there is even an example on how to implement your own
thats the nice and massive gain from the surface shader system. as you no longer write complex interrelated messes, it will become much easier to implement own stuff …
looking really forward to somewhen later this year / early next year when I hope to work on a toonish set of shaders given they don’t exist by then
I agree, this scene is a worst case scenario. You would be hard pressed to think up a need for this many real time lights in a hallway, unless you were building a lightning bug hunting game or something.
In a real scene with a long hallway like this, you would probably have a bunch of static lights in the ceiling or as sconces on the wall, which could all be baked in using Beast. You might have one or two real-time lights flickering or moving to add some life, and maybe some lights on NPC’s. You could adjust the size of the real-time lights and their location to avoid as much rendering cost as possible.
Outdoor daytime scenes would probably have one primary directional light and a handful of spotlights or point lights scattered about. So the primary cost would come from the directional light.
Hopefully though, this demo gives a data point on the boundary of deferred shading’s capabilities and costs, to help figure out what the new rules for scene optimization are when you can have a bunch of real time lights.
Umm, I had the smallest programming team possible, and pulled it off. Let’s not say that every missing feature in Unity is solely because it’s not the largest team in the industry. It’s in fact pretty big, and the technique is not that hard.
Adding an option to an engine does not force it’s exclusive use, and as mentioned, it’s not been highend for many years. You might assume it’d fail, but your assumption seems to be that because Unity doesn’t have it it’s a bad idea to have it. I like Unity alot, they have elegant solutions in most cases, and that’s something to be proud of. Shaderlab and the shader architecture of their lighting system do not fall into that category (lighting is in fact as inefficient as it can possibly be without trying, as far as shaders are concerned). All designers have their failings, heck, IMO if you don’t have failings then you haven’t taken enough chances. But no matter what, the lack of quality lighting in Unity is not a requirement of supporting lower end systems, nor is it a failing of team size, and I think the guys at Unity are big boys and can handle it if a mistake is called a mistake.
Their being ‘high end’ was not purely because of using any particular rendering technique, that was their content. And it’s not bad anyways, sure not being ‘mainstream’ is bad if evaluating potential playerbase, but there are alot of sales gained by being perceived as ‘cutting edge’.
I’ve no idea, I didn’t play stalker or crysis, neither looked fun to me. But as I said before, where deferred rendering is faster is content dependent, neither technique can be called faster or slower across the board. Deferred rendering has a kind of ‘up front cost’ then cheaper content, that’s the core difference in terms of speed, IMO.
Hehe, yea, I was thinking along similar lines, at least in terms of developing less ‘realistic’ effects.
with my laptop’s geforce 9600m gs and core 2 duo t9400 2.5ghz, 4 gb of ram, on windows 7 64 bits
with deferred rendering with shadows on, 9 fps, with shadows off 30-40fps,
forward rendering had no shadows and in all cases it gave between 60 and 80 frames per second
so its a very resource heavy method to render stuff…
i personally would not use referred rendering for my projects as my target audience is more casual than hard core and without shadows it seems to render the same thing but with half of frames per second
its beta (so not fully optimized yet) + low end hardware (9600m gs) that hit you there, especially if you have something like 1400+ screen resolution on such a gpu
And yeah the no shadow is expected. Point type lights in U3 no longer have dynamic shadows in forward rendering, only directional lights have
The demo looks nice, polytropio. I get 18 FPS when viewed from from the same place you show in your image (on my GeForce 9600M GT). Roughly how many polygons and lights do you have in your scene?
Well, it should also be noted that this is more of a deferred rendering hybrid, not full MRT based deferred shading, which is what I prefer, and likely what many other devs mean when they say deferred renderer. With the example shown here, it still draws the objects twice, both passes featuring kindof half of the lighting and terms, instead of lighting terms being generated in one pass then lighting when lights are drawn. It’s not going to perform as well as one that only does one pass per object, or two passes where the first is just depth/z (at least with ‘real’ content). I’m not sure what benefits there are to this approach, but it doesn’t seem to be built with performance on the surface content as a primary goal. I don’t like this approach regardless because if you have dependencies between normals and other lighting terms (which I found useful for advanced terrain shaders, which often takes the lion’s share of screen space) then this system basically makes you pay for more than two full passes up front, more than killing any performance gains.
With the content presented here, it’d clearly do much better with a deferred shading architecture that drew the surfaces only once. No matter what, their deferred renderer doesn’t look nearly refined enough to make judgments on ATM.
Unhappily Unity is not a windows - ps3 - xbox only technology, there is also OSX and Apples outdated, broken and/or not fully implemented OpenGL implementation.
If I recall right, the two half pass approach one of the possible approaches to overcome this apple problems, as 16bit RTs work nice and performant unlike the 32bit RTs
While I haven’t loaded the U3 beta (don’t wanna get sidetracked, and that would be a significant distraction), if they have the materials abstracted adequately, then it’s easy enough to add multiple architectures that can be chosen based on platform/content. Can always hope, at least.
Im a little surprised by
A: The demos performance, are you using a proper composited deferred rendering mechanism (ie, one or two shaders with different layer passes?) or are you doing something else?
B: The whole AA doesnt work with deferred rendering - this is such a common misnomer its not funny. You CAN use AA as much as you want!!!
To explain, deferred rendering simply refers to the concept of rendering you scene in layers of output and compositing the scene later (deferring the render). Deferred lighting works in the same way - you have shadow layer pass, a lighting layer pass an so on. These techniques are old. And even the very early original GF3 cards could do basic deferred rendering easily at 60fps. I have demos that run in BlitzBasic if youd like.
The performance problems here I suspect are because you are using too many shaders. For example most deferred rendering systems use a minimal number of shaders and have switch paths in them for each layer. The reason behind this is so you upload the geometry and textures once and run your passes on the card as many times as you need. Additionally many deferred shaders are capable of generating multiple layer outputs in a single shader render pass - see CryTeks.
For those most interested in how one method was used have a read, its not overly difficult, and the reason many companies use it is because of its lighting model and standardised rendering pipeline (no specialisation, everything is treated in a similar way). http://www.guerrilla-games.com/publications/dr_kz2_rsx_dev07.pdf
Additionally deferred rendering allows you to do some pretty impressive effects at a minimal cost. Ok, so why not forward render? Simple… state changes. With deferred rendering you can literally guarantee how big you state change cost will be over any frame. With forward rendering with multiple shaders you cannot easily (without some uber shader). And you get far more flexibility with deferred rendering, you can easily change a composite method and change the entire look of the game, without touching a single asset. Thus the game designers and artists get a much better control over their output.
Oh note on AA. I have seen some excellent tricks using AA with deferred rendering - you can do a normal geometry render with an AA pass… then composite!! The problem people are talking about are not related to deferred rendering, but to GBuffers. Where people use their own pixel format to describe the layered data. You DONT have to do this. Its a method widely used on consoles to save GPU mem, on PC’s… this is hardly an issue anymore
Hope this helps. I might convert some of my Blitz Basiz tutorials over to Unity and help people try out their own.
The technique this demo uses is not a common deferred renderer/shader, it is one that seems designed around an aversion to using MRTs. Likely the reason it’s performance suffers is not even related to that, as the lighting pass is overly expensive due to this, but not dramatically so. IOW, even a good deferred shader is going to perform worse than the forward renderer in this case (since floors/walls are throwing out the expensive part in FR). If the forward renderer was actually doing the same work as the deferred (lighting floors/walls properly), then this demo would be faster in deferred mode even with Unity’s deferred solution. Deferred shaders excel as the time to render a pixel grows, and those pixels are being calculated more than once, and this content doesn’t fit that description.
And with AA, yes, there are many tricks to AA, but usually when people talk about it they’re talking about hardware MSAA, which is not doable with deferred rendering outside DX10 (and I’ve no experience with DX10, but from what I’ve read, it’s possible there). The problem is as long as lighting is separated from surface calculation, you can’t combine those pixels in the separate passes, do the lighting, and get the correct result. The math is actually quite simple, (ab)+(cd) is not the same as (a+c)*(b+d). While that is an oversimplification of what’s going on generally, it’s a pretty good analogy. Also, it’s possible that the artifacts wouldn’t be that bad, I’ve never experimented with that.
From the little I’ve read, DX10 allows for the reading of those multiple sampled pixels at the lighting pass, so you can work with the ‘real’ MS pixel data, rather than the additive result.
This demo doesn’t implement the deferred shading algorithm itself. It is using Unity 3.0’s built in deferred shading logic. As such, I don’t have any control over how the buffers are being rendered, or how Unity optimizes the calculations. The deferred shading algorithm used by Unity 3.0 is a black box to me. I am simply using it as is out of the box, and looking to get an idea of how it performs and what the performance rules are.
This is also the reason I say that AA is a limitation, since Unity’s current solution does not support AA out of the box.
Here is the only information we have seen so far on how Unity 3.0 is handling deferred shading:
I would love to hear Aras’ thoughts on this thread. Aras?
