Ok after sifting the reality from the marketing-speak:
1) Vertex shader capabilities are virtually identical to the R300, including length.
2) Pixel shader capabilities have finally caught up to ATI's. Again, these are also virtually identical to R300 but do have some very nice new functionality like high precision sin/cos, pack/unpack etc. As others have pointed out the additional program length is nice but from a performance perspective is virtually useless.
3) Given the 4-5 month lead time of the R300 and the fact that the NV30 limits exceed DX9 specs, are we going to see a repeat of R200 vs NV20? Same situation as before but reversed. R200 had considerably nicer pixel shaders but nobody utilized them.
4) Sounds like damage control to me. "Oh yeah we do all those funky things that R300 does too". I don't see a whole lot that's better other than the longer pixel shader program length and the usefulness of that is debatable. Regardless, if you did have a very long program (eg. renderman conversion), this additional length will give it a performance advantage over R300 since it wont have to break it up into as many passes.
Now what about these new pixel shader operations?
1) Is anyone going to use these high precision NV30 specific sin/cos functions when you can get a "good enough" result using DP4 (taylor series) on ALL hardware? Especially if sin/cos is not a single cycle operation and stalls the pipe?
2) Ok so what do you guys think these new pack/unpack operations do? At first I was thinking along the lines of OGL 2.0 pack/unpack but I don't this has that type of permutation flexibility. First thing is PK2 vs PK4 which might refer to 16 vs 8 bit packing. Then half the operations have "U" which may refer to unsigned vs signed, which would be important for unpacking so you could extend the signed bit. Not sure what the "H", "S", "B" or "BG" might stand for though.
1) Vertex shader capabilities are virtually identical to the R300, including length.
2) Pixel shader capabilities have finally caught up to ATI's. Again, these are also virtually identical to R300 but do have some very nice new functionality like high precision sin/cos, pack/unpack etc. As others have pointed out the additional program length is nice but from a performance perspective is virtually useless.
3) Given the 4-5 month lead time of the R300 and the fact that the NV30 limits exceed DX9 specs, are we going to see a repeat of R200 vs NV20? Same situation as before but reversed. R200 had considerably nicer pixel shaders but nobody utilized them.
4) Sounds like damage control to me. "Oh yeah we do all those funky things that R300 does too". I don't see a whole lot that's better other than the longer pixel shader program length and the usefulness of that is debatable. Regardless, if you did have a very long program (eg. renderman conversion), this additional length will give it a performance advantage over R300 since it wont have to break it up into as many passes.
Now what about these new pixel shader operations?
1) Is anyone going to use these high precision NV30 specific sin/cos functions when you can get a "good enough" result using DP4 (taylor series) on ALL hardware? Especially if sin/cos is not a single cycle operation and stalls the pipe?
2) Ok so what do you guys think these new pack/unpack operations do? At first I was thinking along the lines of OGL 2.0 pack/unpack but I don't this has that type of permutation flexibility. First thing is PK2 vs PK4 which might refer to 16 vs 8 bit packing. Then half the operations have "U" which may refer to unsigned vs signed, which would be important for unpacking so you could extend the signed bit. Not sure what the "H", "S", "B" or "BG" might stand for though.
