Nvidia and ARB2
- Thread starter micron
- Start date
Very interesting post, Dave. But I'd like to comment on this statement:
Why do I think the NV40 will have a unifed pipeline setup? The answer lies in the spec of the NV_fragment_program extension. Specifically, the NV30 has already unified most of the instructions available. Within this architecture, the vertex pipeline and the fragment pipeline are very, very similar already. It remains only a small step to make them the same.
One has to wonder what the best scheduling technique would be on such an architecture, but hopefully that's been researched well enough that it won't be a significant issue.
As you pointed out, the primary transistor count differences between FP32 and FP24 are in the multiplier, not in the registers and other required components. Since the problems with the NV3x pipeline are clearly not related to the structure of the functional units themselves (except perhaps, as you stated, the pipeline depth, but again, that's a separate design decision), I'm not sure this argument is a valid one.
Said another way, I think you put out a significant enough argument that could easily explain the register usage penalties of the NV3x architecture without having to resort to them being due to transistor count constraints from the FP32 support.
I'm not sure that's likely. Instead, I find it very likely that the NV40 will have a unified vertex and pixel pipeline. This will require all execution units to support FP32.Dave H said:
Why do I think the NV40 will have a unifed pipeline setup? The answer lies in the spec of the NV_fragment_program extension. Specifically, the NV30 has already unified most of the instructions available. Within this architecture, the vertex pipeline and the fragment pipeline are very, very similar already. It remains only a small step to make them the same.
One has to wonder what the best scheduling technique would be on such an architecture, but hopefully that's been researched well enough that it won't be a significant issue.
I'm not sure this is the case, either, as I feel the NV35 shows. Specifically, the NV35, apparently, has as many FP32 units as the R300 and R350. This argument may have held up if only the NV30 was available, but the NV35 has been put out at hardly any additional transistors.
As you pointed out, the primary transistor count differences between FP32 and FP24 are in the multiplier, not in the registers and other required components. Since the problems with the NV3x pipeline are clearly not related to the structure of the functional units themselves (except perhaps, as you stated, the pipeline depth, but again, that's a separate design decision), I'm not sure this argument is a valid one.
Said another way, I think you put out a significant enough argument that could easily explain the register usage penalties of the NV3x architecture without having to resort to them being due to transistor count constraints from the FP32 support.
Dave H said:
Brilliantly good theory, Dave H! 8)
NV3x's ability to do a lot of dependent texture reads and the ability to do constant branching in PS should be more than enough hint for us as to why nVidia had to make some sacrifice with those registers. It had to be a design choice/limitation rather than a bug IMHO.
Bouncing Zabaglione Bros.
Legend
Dave H said:
This is the crux of the matter. Nvidia made a compromise that pleases no one. It seems they did this because they had a solution and then went looking for a problem to apply it to.
Like the man who fails his exam by not reading the question properly, and so produces a brilliant answer - to a different question - so too Nvidia have misread the market and it's direction completely.
Whether Nvidia were arrogant to think they could pull the market their way, or whether they simply produced something Nvidia wanted to make, rather than what the market they were addressing wanted to buy, who knows? I doubt we'll find out the details of what really went on for a while yet.
I am still surprised by how far out of step Nvidia is with what the market wants, which I guess explains things like the NV30 fan. I suppose they have just lost touch with the gaming market, and not realised that we don't want a non-real-time broadcast graphics generator to play our games on.
I'm not sure that thread explains anything.DaveBaumann said:
The point is, the NV35 core has similar functional units, at FP32, as the R300/R350 does at FP24. Will this require more transistors? Yes. Does the NV35 core have more transistors? Yes.
But there are too many other differences to directly compare the cores, or narrow the differences down to a simple difference of precision support.
I'm not tlaking about the transitor differences, I'm talking about the supposition that NV35 has more FP units.
1)nVIDIA created a very special architecture and they thought everyone will accept is as easy as JC did and program especialy for it using their CG language .
The thing is that ATi's DX9 architecture was chosen as the sample of initial DX9 hardware guidlines and it suited that much better . The game developers will still use DX9 direct coding instead of CG , at least for know .
Maybe if game developers will start using CG in the future , let's say in 2004 , we will probably se a great improvement in NV3x's performance , but only in that king of coding ( CG related ) .
2)Also , nVIDIA fell in the sin of 3DFX . They thought people will never care about qualty rendering but only about frame rate . This belief gives birth to so many troubles for them :
-nobody care about framerates in the 200's anymore as you can't see more than the monitor's refresh rate is showing you , that's a (-) for the marketing departament ;
-new games are especialy about increasing the IQ and the level of detail showed and this contrasts a lot with nVIDIA's tendency to go after the frame rate ;
-before this generation , they've fixed everyting with better optimised drivers that were not showing any or were showing acceptable loss of quality due to the simplicity of the games , now they can to that but people ask to see the beauty of the graphics not the frame rates and if they show the real graphics they loose the performance below the acceptable playability level .
The thing is that ATi's DX9 architecture was chosen as the sample of initial DX9 hardware guidlines and it suited that much better . The game developers will still use DX9 direct coding instead of CG , at least for know .
Maybe if game developers will start using CG in the future , let's say in 2004 , we will probably se a great improvement in NV3x's performance , but only in that king of coding ( CG related ) .
2)Also , nVIDIA fell in the sin of 3DFX . They thought people will never care about qualty rendering but only about frame rate . This belief gives birth to so many troubles for them :
-nobody care about framerates in the 200's anymore as you can't see more than the monitor's refresh rate is showing you , that's a (-) for the marketing departament ;
-new games are especialy about increasing the IQ and the level of detail showed and this contrasts a lot with nVIDIA's tendency to go after the frame rate ;
-before this generation , they've fixed everyting with better optimised drivers that were not showing any or were showing acceptable loss of quality due to the simplicity of the games , now they can to that but people ask to see the beauty of the graphics not the frame rates and if they show the real graphics they loose the performance below the acceptable playability level .
LeStoffer said:
Well, assuming this theory is the correct one, then it would also appear that computational flexibility was more important than 3d performance in the design, especially as it concerns fp32, and that the chip designers at nVidia started taking the "gpu" concept a little too seriously and were thinking more like general cpu designers...
But if this was actually a conscious decision I'm having difficulty seeing what they gained from it...?Dave H said:
In general, a from-scratch design takes on the order of 3 years from architecture spec to production. However, GF's have never had a from scratch design that I can see. Evolutionary instead (which is not bad -- don't get me wrong; it has pros & cons). Consequently, the design cycle is probably shorter. Both ATI & NV had plenty of input into DX9, as well as a good (not great) amount of time to incorporate needed changes.
Lots of stuff in there. The computation / bandwidth ratio is interesting, but I'm not sure it makes that much sense. The raw pixel BW required is not determined by the format of your internal computation engine, but more about the actual surface requirements per pixel. R300 was an 8 pixel pipe before it was FP24 in the pixel shader. For that matter, 90% of the R300 pixel pipe is FP32 or higher. Just when you get down to the ALU does it go to FP24, since at that point, FP24 is reasonable (i.e. from a texture addressing standpoint, if nothing else). While FP16 is actually a step back from FX12 in the [0,1] color range. Honestly, the area increase from 24b to 32b would not cause you to go from 8 to 4 pixels -- It would increase your overall die cost, but not *that* much. It's just a question of would it justify the cost increase? For today, it doesn't.
Actually, the performance difference appears to be 2~5x, when running complexe shaders. It's not just register usage (though that's a big one).
BS. The R300 has no performance hit at 1,2 and sometimes a slight performance when hitting 3 and 4 levels of dependancy. The performance hit an NV3x gets in just defining 4 temporaries is much larger than the R3x0 gets in doing 4 levels of dependancies. The worst 4 levels perf hit I've ever seen is in the 10~15% range. The R3x0 is VERY good at hiding latencies.
Dave H said:
As far as the second quote relates to the first I could only agree if the non-game market was large enough to make this a good compromise. Otherwise I would chalk it up to a grave mistake. If the cinema/television market is so important why not make a second GPU tailored for that and let the programming API be what ties them togther.
Chalnoth said:
Eh? As far as we know so far NV35 has a full combined ALU & texture address processor and two smaller ALU's for each of its 4 pipes. R300, ignoring the Vec/Scalar coissue, has an FP texture address processor a full ALU and a small ALU for each of its 8 pipes. Thats 12 FP processors for NV35 and 16 for R300, excluding the texture address processor, 24 including.
