For The Last Time SM2.0 vs SM3.0
- Thread starter Blacklash
- Start date
Go to the introduction link here for an overview of what it is (although not how its implemented in modern graphics boards):
http://www.debevec.org/HDRShop/
Download the Fiat Lux video as well.
http://www.debevec.org/HDRShop/
Download the Fiat Lux video as well.
There's a significant difference between your thread title and your actual question.malficar said:
The X800 series is not limited to shader version 2.0. It can do shader version "2.x", and is a "2_b" shader compiler target.
Version "2.x" in itself doesn't say much, because it is sufficient to exceed a single "2.0" requirement to claim "2.x". You need to look at where and how a chip exceeds version "2.0".
The X800 can execute shaders up to the maximum length DX9 allows for "2.x", that is somewhere between 511 and 1532 operations, depending on instruction mix. This is a significant step up from version "2.0". X800 is still limited to four levels of indirection ("dependent texture fetches"), which is the same as R3xx class hardware, and may be its biggest overall flaw.
(Pixel) Shader version "3.0"'s most significant benefit is dynamic branching, which is primarily useful for skipping over computations that aren't necessary for the current fragment, which obviously saves computational resources (=effective fill rate). Dynamic branches can also, theoretically, lower CPU load because fewer shader changes are needed per frame (state changes in general are expensive in DX9).
How useful this really is depends on implementation. There currently appear to be significant penalties for dynamic branching on NV40. I'm not claiming that this makes it counterproductive generally, but it's again important to note that there are differences between theoretical value of a shader model, and the actual value of implementations.
Otherwise I'd just like to point out that a shader that must execute 511 instructions per fragment is going to run slow as dog, with fillrates in the "less than a Voodoo 1" ballpark. No matter what hardware or shader model you use. This also means that a very long pixel shader can be multipassed without much penalty because multipassing consumes bandwidth and geometry resources, and both of these resources are heavily underused by very long pixel shaders. You'd get a multipass split basically for free, so for pixel shaders without lots of conditionals, you don't really need SM3.
Re VS3.0: pure nicety, if filters were supported. Unfortunately NV40 does not support filtering of vertex textures and this makes vertex texturing useless IMO. You can just as well use another vertex attribute stream, or indexed constant storage in lieu of a vertex texture. You'd pick one of the two depending on the amount of data in the vertex texture and its fetch locality.
Another vertex level capability of NV40 is the stream frequency divider, marketed as "geometry instancing". Most useful for rendering many objects with low polygon counts. Draw calls are expensive in DX, so this allows the chip to, in a nutshell, generate the draw calls itself internally, under restricted circumstances.
I don't think this is very useful. I may be wrong
In summary, NV40 can not render effects that aren't possible at all on X800, but it may very well be more efficient at rendering the same effects once they
a)reach a certain complexity
b)contain many conditionals
and/or
c)require many levels of texture indirection
Re 3Dc (just because it has been brought up): it just (de)compresses two-channel textures in a format suitable for normal maps, it does not enable any new effects. The compression gain is fixed at 50%. While it does save storage space and bandwidth, it is unlikely to enable higer resolution normal maps to fit on the same card. That would be a sensible claim to make for a 4:1 (or better) compression, but IMO not for "3Dc".
Wow! Great post Zeckensack, I feel better educated on the subject now.
Thanks!
Thanks!
zeckensack said:
Nop...
Forgot FP16 blending and FP32 textures (all targets except 3D I think), that include trilinear and anisotropic filtering.
Like proven with FarCry, no one is going to simulate HDRI by rendering to a FP RT, and read back from pshader... Keep it simple and use FP blending...
To malficar: NVIDIA doesn't need to upgrade until DX10. There is nothing that it doesn't already support in the NV40. Well, except 3Dc...
Sigma said:
I may be wrong, but I though filtering was only supported on FP16 textures?
UnrealEngine3 will implement this as one method for HDR, as does HL2.
DaveBaumann said:
What I meant was FP16 blending. And FP16/32 textures.... DaveBaumann said:
Unreal? Are you sure? I remember they specificly talking about FP blending on the presentation...
As for HL2, well, they don't have any choice, know do they? We are talking of ATI/Valve: and they make a nice couple....
EDIT: I think Carmack talked about waiting for FP blending too, since with dynamic lighting, having to render to a FP RT and read back for each light is very slow...
And since HL2 is still very "lightmaped", maybe this is why they can afford to have HDRI. They probably do everything in one render pass...
You're right, I forgot to mention that. It is not inherently tied to the shader model, texture caps should be orthogonal (ie you can use FP32 textures in fixed function "DX7" multitexture setups, if you want to). I'm a bit fuzzy on DX related details though, so there may be artificial limitations imposed by the API.Sigma said:
But as I was trying to discuss R420 vs NV40, and not specifically SM2 vs SM3, this is a good point.
Note that R300 and R420 both support FP16 and FP32 textures, they just cannot filter them at all. I agree that this is a significant limitation.
See Dave. rthdribl uses the same technique, and was the first publically available example of "HDR" rendering IIRC.Sigma said:
Of course this is going to be slower than if you had FP texture filtering at your disposal. I already commited to this:
Add:myself said:
d)involve blending on floating point targets
Sigma said:
FP16 filtering and blending, fair enough - FP16/32 textures (without filtering) have been supported in R300 upwards since day 1.
According to the discussion I had with Tim Sweeney last week, yes. HDR will be implemented for non FP16 blending capable parts as a fallback method.
As for HL2, well, they don't have any choice, know do they? We are talking of ATI/Valve: and they make a nice couple....
Lets deal with the facts shall we, and this is not "no one" as you initially stated. Valve are already supporting HDR to in integer texture for the FX series, as well as float for ATI's shader 2.0 parts - we don't know if they are going to use blending or not yet.
Textures filtering would be nice, but lacking of that doens't make texture sampling in the VS pipeline useless.zeckensack said:
There are plenty of (very interesting and exotics by now) things you can do just with point filtering!
Last time I checked vertex attributes and shader constants weren't filtered entities
It could be very useful in some applications/games. I would like to know how geometry instancing is used in FarCray. Maybe they use it to render things like rocks, vegetation, grass and so on..Another vertex level capability of NV40 is the stream frequency divider, marketed as "geometry instancing". Most useful for rendering many objects with low polygon counts. Draw calls are expensive in DX, so this allows the chip to, in a nutshell, generate the draw calls itself internally, under restricted circumstances.
I don't think this is very useful. I may be wrong
ciao,
Marco
Ta.
Yes, I won't dispute that. My point was that you can do all of them without vertex textures.nAo said:Textures filtering would be nice, but lacking of that doens't make texture sampling in the VS pipeline useless.zeckensack said:
There are plenty of (very interesting and exotics by now) things you can do just with point filtering!
"Nearest" filtering is the same as no filtering at all. Vertex textures on NV40 aren't "filtered entities" either.nAo said:Last time I checked vertex attributes and shader constants weren't filtered entities
Whatever texture coords you'd like to use in the vertex shader to lookup a vertex texture, you can resolve them on the host and put the "lookup" result into another vertex attribute stream.
This works brilliantly for texture coords that are invariant wrt result position (like all forms of displacement). It won't work well with texture coords that depend on the transform matrices (like fish-eye lens distortion).
This was another thing I forgot about
Simon F said:
Well, I assume that it means nearest neighbor filtering, but maybe I have spend too much time in Photoshop?
Edit: Yes, probably too much PS. I think that Simon is right that with "nearest filtering" nVidia just mean nearest-point sampling (not filtering). Sorry for that.
You can do everything on the host, even render a full frame if you like it. That doesn't mean we want to do that. How many games that employ displacement mapping or geometry images techniques did you play with recently?zeckensack said:
Nevertheless GPU that can push a lof of pre-baked primitives are here since years..
ciao,
Marco
