Quoted from Azaroth11 and he himself names that he has gathered it from this forum and Dave Baumann here at beyond3d and Demiurg from 3dcenter.de
But the thing is do you think this is a nice summarization on the use and importance of shader model 3 in todays video cards (NV40 and R420)?
To me it made a lot of sense but what do you guys think?
Post 1
PS3 and VS3 (aka Shader Model 3, aka SM3) allow for loops, thus you may execute potentially infinite shader instructions. Right. The problem is, your card won't be able to run long shaders in realtime It won't be FPS but SPF. X800 will run any shader of performance-wise reasonable length. nV's 65k instruction length limit is utterly pointless for many years to come, even X800's current limits are hopelessly overfeatured. So, instruction count is not it.
What is it then? Well, loops are implemented by branching conditionally. A SM3 shader may first calculate if it is reasonable to calculate the pixel value at all (it may be hidden or in deep shadow) and, based on that, either do the whole complex calculation or simply use e.g. black. Otoh branches don't come for free. They have the potential to flush the whole pipeline and, if not used carefully, SM3 shaders may severely decrease performance.
SM3 is SM2 plus some instructions and capabilities plus some limits relaxed. There is no visual difference between PS2 and PS3. You may create any effect in both models, and if you know what you are doing very well, you may make it running faster in SM3, at least in some cases. From a programmer's point of view SM3 is certainly more elegant, though.
And regarding displacement mapping: that's a Vertex Shader 3 feature. It makes a difference, but it is not used in any game, not even the Unreal Engine 3 demo. Real displacement mapping generates additional geometry (i.e. triangles) to be textured, filtered, etc. Even NVIDIA's new cards are only a first shot at it, because they lack a tesselation unit. That means, they can shift vertex positions dependent on texture lookups, but they cannot create vertices out of thin air. As far as I understand, on 6800 cards you may displace vertices of an already fine but flat mesh. So all the geometry must already be there.
What FarCry and UnrealE3 do is called Virtual Displacement Mapping. That's perfectly possible on any SM2 machine, and it doesn't need even many PS instructions. In fact that's the only reason why it can be done in realtime at all. The illusion it creates is quite good as long as you don't look at the surface from a very flat angle. If you do so, you notice that it's really flat but "painted".
The only reason why we probably wouldn't see Virtual Displacement Mapping on Radeons could be, that Crytek implement VDM via SM3 instructions only because they get payed to do so. Otoh, they want to sell their engine, so why should they purposefully p*** off ATI customers? Does not make sense to me.
Hope things are clearer now.
Post 2
Sorry for the "oh my goodness", but, while following the technical discussions on www.beyond3d.com and www.3dcenter.de vividly, I see that NVIDIA's propaganda already works all too well.
As regards instruction count, you will certainly have seen pictures of ATI's Ruby demo. Now, that is code that won't run on R300/R350 any more, at least not without a wrapper that replaces some shaders with slightly simpler ones. Same with nV's Mermaid. Still, those demos use shaders of not much over 100 instructions. With about 1000 instructions you can make "Finding Nemo" and "Final Fantasy" (the movie), and that takes hours per frame on a rendering farm. That's for 65k instructions being pointless in realtime
Some more thoughts about real SM3 displacement mapping:
Have you ever tried to model something in Maya or 3DSmax? Say, a rock? I have. Do you know how many triangles it takes to let something look round? Well, let's suppose we need 100 triangles for a rock like those in the foreground of jakup73's second shot. How many of them do you have on a beach? 10000? Now multipy. That's what real VS3 displacement mapping would have to generate on the fly. That's what would have to be textured, filtered, lit, etc. That's what with NVDIA's current implementation would already have to be there, because the hardware can't create new vertices!!! Impossible.
OK, you could do some LOD magic, i.e. only do it in the foreground, but I guess you would have to do that in the CPU, thereby making an already CPU-bound game even more so. And you wouldn't even be able to do it that way on current NVIDIA hardware, because, you guess, "no new vertices"!!!
From this point of view nV's VS3 seem pretty pointless also, because they don't save triangles, not even in the non-displaced case. That's not entirely true though. While I can't think of things that can't be done in normal VS2 programs, it may be much easier for the developer. I mean, it's a difference whether you have to specify a relief as mathematical opertions or as an image you can paint. The latter may be even done by an artist. Again I think the main advantage of SM3 (at least in nV's restricted implementation) is convenience for the developer, not that it won't run as well otherwise.
All in all it boils down to the question whether developers will use what is most convenient for them or what reaches the biggest group of customers. And that's where money gets in. I can't imagine a publisher not pressing the developers to use SM2 when that's what the masses have and that's where the money is.
In other words: I strongly expect to see SM3-only code in some nV demos, but not in any game before, say, 2006, maybe later. And by that time games will crawl on even the most advanced current hardware anyway.
But the thing is do you think this is a nice summarization on the use and importance of shader model 3 in todays video cards (NV40 and R420)?
To me it made a lot of sense but what do you guys think?
Post 1
PS3 and VS3 (aka Shader Model 3, aka SM3) allow for loops, thus you may execute potentially infinite shader instructions. Right. The problem is, your card won't be able to run long shaders in realtime It won't be FPS but SPF. X800 will run any shader of performance-wise reasonable length. nV's 65k instruction length limit is utterly pointless for many years to come, even X800's current limits are hopelessly overfeatured. So, instruction count is not it.
What is it then? Well, loops are implemented by branching conditionally. A SM3 shader may first calculate if it is reasonable to calculate the pixel value at all (it may be hidden or in deep shadow) and, based on that, either do the whole complex calculation or simply use e.g. black. Otoh branches don't come for free. They have the potential to flush the whole pipeline and, if not used carefully, SM3 shaders may severely decrease performance.
SM3 is SM2 plus some instructions and capabilities plus some limits relaxed. There is no visual difference between PS2 and PS3. You may create any effect in both models, and if you know what you are doing very well, you may make it running faster in SM3, at least in some cases. From a programmer's point of view SM3 is certainly more elegant, though.
And regarding displacement mapping: that's a Vertex Shader 3 feature. It makes a difference, but it is not used in any game, not even the Unreal Engine 3 demo. Real displacement mapping generates additional geometry (i.e. triangles) to be textured, filtered, etc. Even NVIDIA's new cards are only a first shot at it, because they lack a tesselation unit. That means, they can shift vertex positions dependent on texture lookups, but they cannot create vertices out of thin air. As far as I understand, on 6800 cards you may displace vertices of an already fine but flat mesh. So all the geometry must already be there.
What FarCry and UnrealE3 do is called Virtual Displacement Mapping. That's perfectly possible on any SM2 machine, and it doesn't need even many PS instructions. In fact that's the only reason why it can be done in realtime at all. The illusion it creates is quite good as long as you don't look at the surface from a very flat angle. If you do so, you notice that it's really flat but "painted".
The only reason why we probably wouldn't see Virtual Displacement Mapping on Radeons could be, that Crytek implement VDM via SM3 instructions only because they get payed to do so. Otoh, they want to sell their engine, so why should they purposefully p*** off ATI customers? Does not make sense to me.
Hope things are clearer now.
Post 2
Sorry for the "oh my goodness", but, while following the technical discussions on www.beyond3d.com and www.3dcenter.de vividly, I see that NVIDIA's propaganda already works all too well.
As regards instruction count, you will certainly have seen pictures of ATI's Ruby demo. Now, that is code that won't run on R300/R350 any more, at least not without a wrapper that replaces some shaders with slightly simpler ones. Same with nV's Mermaid. Still, those demos use shaders of not much over 100 instructions. With about 1000 instructions you can make "Finding Nemo" and "Final Fantasy" (the movie), and that takes hours per frame on a rendering farm. That's for 65k instructions being pointless in realtime
Some more thoughts about real SM3 displacement mapping:
Have you ever tried to model something in Maya or 3DSmax? Say, a rock? I have. Do you know how many triangles it takes to let something look round? Well, let's suppose we need 100 triangles for a rock like those in the foreground of jakup73's second shot. How many of them do you have on a beach? 10000? Now multipy. That's what real VS3 displacement mapping would have to generate on the fly. That's what would have to be textured, filtered, lit, etc. That's what with NVDIA's current implementation would already have to be there, because the hardware can't create new vertices!!! Impossible.
OK, you could do some LOD magic, i.e. only do it in the foreground, but I guess you would have to do that in the CPU, thereby making an already CPU-bound game even more so. And you wouldn't even be able to do it that way on current NVIDIA hardware, because, you guess, "no new vertices"!!!
From this point of view nV's VS3 seem pretty pointless also, because they don't save triangles, not even in the non-displaced case. That's not entirely true though. While I can't think of things that can't be done in normal VS2 programs, it may be much easier for the developer. I mean, it's a difference whether you have to specify a relief as mathematical opertions or as an image you can paint. The latter may be even done by an artist. Again I think the main advantage of SM3 (at least in nV's restricted implementation) is convenience for the developer, not that it won't run as well otherwise.
All in all it boils down to the question whether developers will use what is most convenient for them or what reaches the biggest group of customers. And that's where money gets in. I can't imagine a publisher not pressing the developers to use SM2 when that's what the masses have and that's where the money is.
In other words: I strongly expect to see SM3-only code in some nV demos, but not in any game before, say, 2006, maybe later. And by that time games will crawl on even the most advanced current hardware anyway.
