Joe DeFuria said:
Where does he say he's currently supporting and developing the NV30 pipeline?
Carmack's comments on NV30 vs R300, DOOM developments
- Thread starter boobs
- Start date
Where does he say he's currently supporting and developing the NV30 pipeline?
Mintmaster said:
I agree that something seems 'off' given nVidia otherwise excellent driver reputation.
I have this odd feeling that the 3 levels of precision (fixed, FP16, FP32) in the pixel pipeline is the issue here: I would guess that they have the fixed function pretty under control by now (it's the old beloved register combiners from GF3/4 after all), but they still need to work on the two other levels - and I don't think that speed at FP 32 is were the focus is right now.
Johnny Rotten
Regular
Joe, perhaps the performance differences between the various vertex modes didnt/doesnt warrant the maintenance of seperate vertex paths whereas the performance differences in the shader paths (upto 50%) does? That is my impression at any rate.
Joe DeFuria
Legend
*slap*
Does that need to be explicitly said? Do you honestly believe that's not the case? If you believe that, then you have some nerve calling my conclusions "far reaching."
But if we are going by "what was actually said:" he did say:
Since the NV30 "can run" doom in five modes, and one of them is NV30 mode, I'd say that qualifies.
Russ,
Instead of trying this approach of repeatedly trying (I assume) to discredit my speculation by nitpicking at semantics, why don't you try and come up with a plausible alternative for maintaining NV30 path support.
Cripes, even I HAVE THOUGHT of an additional explanation....
Joe DeFuria
Legend
Exactly. Point being, if Carmack was confident that the NV30 fragment paths WOULD close the performance gap...what incentive would there be for still supporting the NV30 fragment path?
What I find so fascinating about all this isn't wether the NV30-specific codepath uses this or that shader precision mode or wether ATI or Nvidia has the more powerful shader implementation... No! I was expecting the NV30 to eat the R300 alive on mere basis of its vast fillrate advantage and Doom3's heavy use of stencil volumes! (And also, Nvidia's claim of a 40% advantage on their own proprietary map played some part in that also I might add.)
By the time the game actually lays down any pixel shader stuff at all, it's already done a Z-only pass so there'll be no overdraw (except for transparencies of course, but those are handled in a different manner from opaque surfaces it seems that probably is less costly), so I didn't expect pixel shaders to be much of a limit at all as far as performance is concerned, and anyway, Doom3s pixel shaders aren't very complicated. PS1.4 can do them in one pass after all, so with a 2.0 implementation I figured it would be a breeze.
On the other hand, we've seen what an enormous performance-hit stencil shadows brings just in a game like Q3A where only characters have such shadows (and they don't have many polys at all comparatively). Doom3 uses stencils *everywhere*! NV30 with its high clock speed should burn through those stencils like no tomorrow I assumed. Maybe it's true, except obviously they're not as big a factor in overall performance as pixel shader speed.
Guess that's because the game redraws the entire screen with pixel shaders at least once per light source (more using pre-PS1.4 shaders or god forbid, no shaders at all), and with many sources that'll be quite a bit of shading there. (Probably the reason why the game's so bloody dark, heh heh.) On the other hand, the stencils seems to be rendered just once (well, front and back side of models, but DX9 cards can do both at once I think I read somewhere).
So in the end, it turns out the game is limited in performance in completely different ways than I had anticipated...! Who coulda thunkit! So is it basically true then, what XBit labs wrote a while back, that NV30 issues just one PS fp op per clock (or two texture reads)? Or how else can this apparent deficiency in performance be explained?
*G*
By the time the game actually lays down any pixel shader stuff at all, it's already done a Z-only pass so there'll be no overdraw (except for transparencies of course, but those are handled in a different manner from opaque surfaces it seems that probably is less costly), so I didn't expect pixel shaders to be much of a limit at all as far as performance is concerned, and anyway, Doom3s pixel shaders aren't very complicated. PS1.4 can do them in one pass after all, so with a 2.0 implementation I figured it would be a breeze.
On the other hand, we've seen what an enormous performance-hit stencil shadows brings just in a game like Q3A where only characters have such shadows (and they don't have many polys at all comparatively). Doom3 uses stencils *everywhere*! NV30 with its high clock speed should burn through those stencils like no tomorrow I assumed. Maybe it's true, except obviously they're not as big a factor in overall performance as pixel shader speed.
Guess that's because the game redraws the entire screen with pixel shaders at least once per light source (more using pre-PS1.4 shaders or god forbid, no shaders at all), and with many sources that'll be quite a bit of shading there. (Probably the reason why the game's so bloody dark, heh heh.) On the other hand, the stencils seems to be rendered just once (well, front and back side of models, but DX9 cards can do both at once I think I read somewhere).
So in the end, it turns out the game is limited in performance in completely different ways than I had anticipated...! Who coulda thunkit!
So is it basically true then, what XBit labs wrote a while back, that NV30 issues just one PS fp op per clock (or two texture reads)? Or how else can this apparent deficiency in performance be explained?*G*
Joe,
if Carmack has developed a NV30 path, maybe just for plain curiousity, there's no reason for him to get rid of it if that path has an advantage. He may drop it in the end if it turns out the ARB2 is just as fast or close, but he cannot at this time be certain. Thus he keeps it. I see nothing wrong there, and it doesn't neccesarily need to mean he's not confident that the ARB2 path will reach the same speed. It may be the case that he's not confident, but that he keeps the NV30 path doesn't prove that. If the NV30 path has a high performance advantage today I'd continue developing it if I were in his position. It's not any more fun developing with low performance than gaming with low performance. Either way it slows your productivity down, at least for me, I'm certainly more productive at 60fps than 30fps.
Also, at this point I don't think there is going to be a whole lot of changes to the fragment programs until the release of the game. I think Carmack spends more time on other things right now, so in the end I don't think the NV30 path or any other path either will need a whole lot of work to keep current.
if Carmack has developed a NV30 path, maybe just for plain curiousity, there's no reason for him to get rid of it if that path has an advantage. He may drop it in the end if it turns out the ARB2 is just as fast or close, but he cannot at this time be certain. Thus he keeps it. I see nothing wrong there, and it doesn't neccesarily need to mean he's not confident that the ARB2 path will reach the same speed. It may be the case that he's not confident, but that he keeps the NV30 path doesn't prove that. If the NV30 path has a high performance advantage today I'd continue developing it if I were in his position. It's not any more fun developing with low performance than gaming with low performance. Either way it slows your productivity down, at least for me, I'm certainly more productive at 60fps than 30fps.
Also, at this point I don't think there is going to be a whole lot of changes to the fragment programs until the release of the game. I think Carmack spends more time on other things right now, so in the end I don't think the NV30 path or any other path either will need a whole lot of work to keep current.
Johnny Rotten
Regular
Joe DeFuria said:
I think the impression you're giving is that you think Carmack is implying (indirectly) that the ARB2 shader performance wont be improved in nvidias drivers anytime 'in the near future'. At least thats what I'm picking up reading your posts. I dont think you can read too much into the fact (that he's mainting the seperate NV30 path) other than that as of today its alot faster than the ARB2 path in nvidias driver.
surfhurleydude
Newcomer
FYI, Doom III is going to be released in May at the absolute latest, as Carmack said he did NOT want to show Doom 3 at multiple E3s...And what Carmack doesn't want, doesn't happen.
Joe DeFuria
Legend
Agree, 100%. This does not contradict my opinion!
I don't get why Russ is so upset over this. The key is as you said: at this time he cannot be certain. In other words, he does not have enough confidence that it will be practical to drop NV30 path.
Neither do I!
Thank you...that's ONE reason so far. Something Russ has yet to present to me. However, IMO, that is a bit weak for a few reasons:
1) Even if it's currently faster, why continue to develop / maintain if in the end, you believe it won't provide any real benefit?
2) Is performance of ARB2 THAT bad? I don't see how rendered FPS performance during development is a big issue. CPU speed (compiling), absolutely. I don't really see how prototyping stuff, and generating either 60 or 30 or 15 FPS makes much of a difference.
3) Isn't he still going to have to develop the ARB2 on GeForecFX regardless of whether he develops NV30 path or not?
See number 2. Could you explain how? 60 FPS vs. 60 seconds per frame I could understand.
Not 60 FPS vs. 30.Joe DeFuria
Legend
Yes, and that's almost exactly what I'm trying to convey. This is one major clarification to make though.
I'm not saying that the implication is that they simply won't be "considerably" improved in the near future. I'm saying the implication is that they won't be improved to the point where it makes the NV30 path redundant. I could see a 50% improvment in the ARB2 path for example, (which is HUGE) in the near future, but that 's still only 75% of the NV30 path performance. And that would still be large enough I would think to want to have the two separate paths.
The problem with your argument as I see it, Joe, is that of all the reasons for supposing that NVidia will not be able to radically speed up the NV30's FP shader performance, the fact that Carmack is maintaining a separate NV30 path for Doom III is perhaps the least significant
Joe DeFuria
Legend
Yeah, I can agree with that. But I still don't understand why some people are apparebntly so upset with the argument.
Again, this is not just about speeding up the performance. It's speeding up the performance to the point where it is 100% higher than it is now...to math the NV30 path.
Johnny Rotten
Regular
Joe DeFuria said:
Personally I think that interpreting the existance of specific shader paths as some sort of prediction/indication of future promise (or lack thereof) is a mistake. I mean its not like Carmack took OUT the distinct vertex paths 4 months in advance because he knew or believed that x days down the line performance between them would all converge. Rather I assume he maintained the seperate paths until a point came where it was no longer worthwhile. I imagine the same is thje case for the shader paths.
My definition of "supporting": code path exists.
My definition of "developing": continuing to optimize and add features outside of "bug fixes".
I think Carmack would use the words this way.
He indicates that the nv30 uses ARB2 extensions for vertex shading, and dropping vendor specific support for this was encouraged by both ATI and nVidia.
He said he is "supporting" the nv30 fragment shading development path currently. He did not say he is "adding features" to it.
He said he is adding features and tweaks to the ARB2 path.
It seems to me believing that he is adding features to the nv30 fragment shader path based on the .plan file does not seem reasonable. Not necessarily wrong, but not what his statement imply. Note my track record regarding the implications of Carmack's text is, however, not the best.
...
Joe interprets this as "supporting and developing", Russ does not.
Both interpretations seem reasonable use of the phrase to me, because of a confusion of the usages of the words.
....
With regards to the dispute:
Joe is talking about the fragment shader path, Russ is confusing comments about the vertex shader path with comments about the fragment shader code.
Russ started out by saying "supporting". I disagree, unless he means vertex shading and not fragment shading.
Joe later stated that he is developing the nv30 specific path. I disagree, I don't see him mentioning that he is adding features to the nv30 specific fragment shading path. I do think if the features are added to the ARB2 vertex shading path, it will affect the nv30 specific fragment shading path's performance. Again, that is my reading of the implications of his comments concerning the fragment shading enhancement.
Joe said he saw "no valid reason for still supporting the nv30 path." I'd disagree, and say I see no valid reason for developing the nv30 specific fragment shading path. I'd also state that we can't say for sure that he is, and I tend to believe he is not. I do think supporting it is fine, however, due to performance issues, and is not unreasonable.
What seems to be the case is that Joe is interchanging the concepts of "developing" and "supporting" I delineate above.
It also seems that Russ is confusing dropping nv30 specific vertex shading with dropping nv30 specific fragment shading. In regards to vertex shading, he seems to be correct with regards to fragment shading, he does not.
My take on things.
My definition of "developing": continuing to optimize and add features outside of "bug fixes".
I think Carmack would use the words this way.
He indicates that the nv30 uses ARB2 extensions for vertex shading, and dropping vendor specific support for this was encouraged by both ATI and nVidia.
He said he is "supporting" the nv30 fragment shading development path currently. He did not say he is "adding features" to it.
He said he is adding features and tweaks to the ARB2 path.
It seems to me believing that he is adding features to the nv30 fragment shader path based on the .plan file does not seem reasonable. Not necessarily wrong, but not what his statement imply. Note my track record regarding the implications of Carmack's text is, however, not the best.
...
Joe interprets this as "supporting and developing", Russ does not.
Both interpretations seem reasonable use of the phrase to me, because of a confusion of the usages of the words.
....
With regards to the dispute:
Joe is talking about the fragment shader path, Russ is confusing comments about the vertex shader path with comments about the fragment shader code.
Russ started out by saying "supporting". I disagree, unless he means vertex shading and not fragment shading.
Joe later stated that he is developing the nv30 specific path. I disagree, I don't see him mentioning that he is adding features to the nv30 specific fragment shading path. I do think if the features are added to the ARB2 vertex shading path, it will affect the nv30 specific fragment shading path's performance. Again, that is my reading of the implications of his comments concerning the fragment shading enhancement.
Joe said he saw "no valid reason for still supporting the nv30 path." I'd disagree, and say I see no valid reason for developing the nv30 specific fragment shading path. I'd also state that we can't say for sure that he is, and I tend to believe he is not. I do think supporting it is fine, however, due to performance issues, and is not unreasonable.
What seems to be the case is that Joe is interchanging the concepts of "developing" and "supporting" I delineate above.
It also seems that Russ is confusing dropping nv30 specific vertex shading with dropping nv30 specific fragment shading. In regards to vertex shading, he seems to be correct with regards to fragment shading, he does not.
My take on things.
Joe DeFuria said:
I don't see what's stopping Nvidia from using fp16 in the ARB2 extensions if they can't speed up the fp32 path. Or at least use fp16 wherever they have to to gain performance. The could always make the excuse that the fp32 is for professional cards.
With that said (assuming that that's the case of course), the only reason as to why Nvidia wouldn't manage to speed up the the ARB2 path up to the level of the R300 would be if the fp16 implementation was slower then the R300 fp24 implementation. And i doubt that but who knows..
Joe DeFuria
Legend
*Scratching head*
Yes, I agree. He didn't take out the distinct vertex array paths until after they did converge, and after implementation and testing he determined that the vendor specfic paths were redundant.
I understand your point though....that basically you're saying that even in Carmack had 99.99% confidence that nVidia would release ARB2 drivers tomorrow that doubles performance, he still wouldn't take out NV30 the NV30 path today.
Well, then I might argue if he really had 99.99% confidence in that.
Joe DeFuria
Legend
Yeah...I know. All I'm asking for is a counter example, instead of all the bullsh*t semantics stuff.
So, I'll now give my own counter-example that I hinted at earlier. (It's OK Russ, I'll do the arguing for you...)
Perhaps nVidia has a future chip coming that will support the features of the NV30 path in Doom3, but not the ARB2 path?
If we go with the assumption that the NV30 path takes advantage of NV3x's increased pipeline flexibility, but not really all the floating point pieline stuff, it seems plausible to me that nVidia could introduce a chip that is compliant with the NV30 fragment path, and at the same time not compliant with the ARB fragment path.
I fully expect the NV31 to in essence support the same features as the NV30. However, there has been talk that the NV34 is a severly cut down NV30, and IIRC, it's been even mentioned to be a sort of DX8/DX9 hybrid of sorts.
That would certainly be a valid reason to maintain the NV3x path...irregardless of the relative performance present or future of the NV30 using the ARB2 path.
It would not be surprising to me if the NV34 can support the parts of the NV30 path critical for performance enhancements, but not the complete ARB2 path.
