NV40: 6x2/12x1/8x2/16x1? Meh. Summary of what I believe
- Thread starter Arun
- Start date
Ailuros said:
Same old broken record. Someone's additional transistors aren't helping them much if the "degrade IQ to boost benchmark scores" routine continues:
I wonder if Nvidia's HW engineers ever get pissed that their driver team keeps deactivating and idling big chunks of their pipe. 
Isn't it possible that the NV30 has way more transistors because of the libraries and/or design software NVidia used vs ATI's "hand tweaked" pipes? Like if I write a bit of code in assembly, vs C++, my assembly code will be alot smaller. ATI because of their process, had a lower transistor budget than NVidia, so they had to use it more wisely?
If I give you 1mb of RAM and tell you to write a game, or give you 2mb of RAM and write a game, you might be alot more wasteful of your resources in the latter scenario. This is not to say that "high level programming is BAD", since it is often more productive (can finish code quicker with less bugs and easier to maintain/test), just that perhaps NVidia's chip isn't as gate efficient as ATIs and that this could account for some of the size difference.
But I also agree that having long instruction limits, control logic for multiprecision, zixel modes, FP32, predication, etc could also account for some of the difference as well.
Isn't it possible that the NV30 has way more transistors because of the libraries and/or design software NVidia used vs ATI's "hand tweaked" pipes? Like if I write a bit of code in assembly, vs C++, my assembly code will be alot smaller. ATI because of their process, had a lower transistor budget than NVidia, so they had to use it more wisely?
If I give you 1mb of RAM and tell you to write a game, or give you 2mb of RAM and write a game, you might be alot more wasteful of your resources in the latter scenario. This is not to say that "high level programming is BAD", since it is often more productive (can finish code quicker with less bugs and easier to maintain/test), just that perhaps NVidia's chip isn't as gate efficient as ATIs and that this could account for some of the size difference.
But I also agree that having long instruction limits, control logic for multiprecision, zixel modes, FP32, predication, etc could also account for some of the difference as well.
Luminescent
Veteran
I agree with DemoCoder's belief in custom/specialized vs. library based/generalized logic as a possible reason for transistor count differences in R300 and NV30/35, but is it enough to explain the 20+ million transistor discrepancy?
NV30/35 use fp32 capable alu's that have extra built in functions like sin/cos/ddx/ddy, etc., but they concurrently serve as texture address processors, unlike the discrete shader alu's and texture addressing units found in R300. It seems the control (gatekeeper), pixel alu predication, and vertex alu branching logic, and more extensive texture filtering implimentation account for functions R300 does not include, although the presence/absence of similarly built-in features in R300 cannot be determined conclusively.
P.S. I forgot to note the more complex AA algorithm which R300 features. Thededication of transistors to such an algorithm may offset the difference in transistor count between the texture filtering implementation of both processors. Gate and transistor counts for these features remain unknown...speculation seems to lead no where, but it is interesting nonetheless.
NV30/35 use fp32 capable alu's that have extra built in functions like sin/cos/ddx/ddy, etc., but they concurrently serve as texture address processors, unlike the discrete shader alu's and texture addressing units found in R300. It seems the control (gatekeeper), pixel alu predication, and vertex alu branching logic, and more extensive texture filtering implimentation account for functions R300 does not include, although the presence/absence of similarly built-in features in R300 cannot be determined conclusively.
P.S. I forgot to note the more complex AA algorithm which R300 features. Thededication of transistors to such an algorithm may offset the difference in transistor count between the texture filtering implementation of both processors. Gate and transistor counts for these features remain unknown...speculation seems to lead no where, but it is interesting nonetheless.
Chalnoth said:
We aren't underestimating the results then after all are we?
John,
W/o being 100% sure I think the engine of Microsoft's recent Flight Simulator series, uses some sort of dynamic LOD (in order to sustain the framerate set in the game's options). I've no idea what exactly is going on there, fact is that it looks bad. In all fairness though I don't think FS2k4 is a good candidate to investigate any differences.
Ailuros said:
I am happy to see some of you guys trying to keep it fair...
John, did you seriously think you would made a usefull contribution to the issue by posting such a pic there the way u did ?
If anyone wants to compare the AF implementations between NV3x and R3xx i suggest them to have a look at 3DCenter. They have a pretty neat, detailed comparison over there. Having used both cards, IMO the differences are pretty big and i like the NV3x more.
nobie said:
Well, those temporary registers should be enough if they wouldn't have 100+ cycle latency in their arithmetic unit and it'd executed non-dependent instructions paralelly (because that's what pipelines are for).
Making this wrong is I think is the single worst design failure of the NV3x architecture. I mean there's no excuse for it.
If they'd got it right there wouldn't even have to be FP16 support in there and in the end they might even saved transistors because of that.
DoS said:
On the flipside of things the pic does come from one of Brent's recent reviews. I have severe doubts that he willingly falsifies what he experiences in games or that the feedback is inaccurate.
There's quite a difference between what a specific driver displays in a filtering testing application and under real time gaming conditions. My point was rather concentrated on the specific game, since it's not exactly easy to see what really is happening there.
Ailuros said:
I didn't know that, still that pic shows absolutely nothing about how the two chips perform AF.
Ailuros said:
That's why the above pic is completely irrelevant...
Ailuros said:
Now here i scream Fault !!! Do you remember what the discussion was about ? let me refresh your memory...someone here speculated that NVIDIA spent more transistors for filtering in NV3x than ATi did in R3xx. That was the original point here, not how each driver team uses the hardware and certainly not specific game optimisations. The latter point has being talked to death, and frankly i am not going to get into it again. Regarding the original point, i have read that NVIDIA calculates LOD based on the Euclidean distance, while ATI uses a weighted Manhattan distance. Make of that what you like...
I didn't make myself clear enough: the driver could very well contain a bug and not enable any AF at all for the specific game, whereby an AF testing application will show you that you DO get 8xAF when you set the driver to 8xAF.
I'm usually way too naive to immediately think of intentional "quirks" and I'm not really fond of conspiracy theories either, unless there's solid proof provided.
Ailuros said:
No, you made yourself perfectly clear. I probably didn't though, so i ll try again. I agree with you on all the points you made. However the original point of discussion was the differences in quality of filtering between the two chipsets, and if NVIDIA when designing NV3x put more transistors into it than ATi did in R3xx. IMO they problably did, right or wrong it doesn't matter.
DoS said:
My point is that Chalnoth has belabored the texture filtering issue to its absolute death, and it was borderline silly to mention it in this discussion because I highly doubt it had any significant impact on the difference of millions of transistors between R3xx and NV3x hardware. And one could certainly counter it with gamma corrected AA that "does more".
DoS said:
Want to see the loophole in your own logic then?
Allow me:
Considering the highlighted part, texture filtering implementations between ATI and NV have also been debated endlessly (see also JR's prior post). Both are eventually old and tired issues, so where would the scale would have to weigh over this time?
What the transistor count now concerns or the 5-bit LOD accuracy or whatever else people have been riding on endlessly lately while resulting to nothing else but speculation, I'd rather take it all with a pinch of salt as long as there isn't any solid proof that speaks for it. If someone is willing to sit down and start doing complicated math where each little transistor went to, I am willing to bet that he'll never hit the nail on the head unless he holds confidential material in his hands. May I also remind you that the amount of instruction slots on NV3x is way higher than on R3xx?
We all know by now what the advantages or disadvantages of each sollution, as of course implementations of various algorithms are and a reasonable and objective consumer will pick that one that will cover his preferences/needs best. Fair enough?
AndrewM said:
I think his point is that the open gl panel did not vote this in . So you saying its a shame its not in d3d is stupid. As its not in open gl . If the panel felt it was important enough to be in open gl they would have voted it in . But only nvidia seems to want it in .
That is what I think he is trying to say
