Well, think about it. It should take roughly the same number of transistors for 4 FP ALU's as it takes for 8 Int ALU's. Much higher peak performance can possibly be achieved if some integer precision is used. Depending on what sorts of programs are necessary for shader calculations, going this way could mean significantly higher performance.
NV30 fragment processor test results
- Thread starter thepkrl
- Start date
What is "superior"? Offering more features, or more speed? It doesn't seem to do both at the same time.Uttar said:
1. It is superior if you remove dynamic range and precision data during operations? Isn't that a bit contradictory to the label "superior" and to proposing shader length advantage?
2. With "few registers used", you are either ignoring integer processing (which reintroduces the performance issues and eliminates the assertion that it competes well in speed), or are just repeating 1.
3. "little scalar" precludes claiming quality advantage without drastic performance deficit, and doesn't facilitate claiming performance advantage without the above items being included as well.
You usually make sense, Uttar, but I don't see it here. "not THAT hard" after listing a set of criteria that seems to contradict the premise of "the NV30 is superior to the R300"?
It is? What are these cases? Again, I see it ranging from being "ps 1.3" functional and faster, or "ps 2.0 extended" and much slower. Note that the extended features keep being proposed as being significant, but are proposed without discussing R300 instruction and functionality advantages.
It is also a problem because it offers inferiority, both in tangible and in theoretical results, to the R300. 3dmark 03, shader benchmarks, and John Carmack's discussions all seem to support this (a 500 MHz part using a custom tailored path at reduced quality barely edging out a 325 MHz part using a generic path does not establish superiority).
Where did this jump from "nv30 is competitive when using integer" to "nv30 is superior" come from all of a sudden? The support seems to be predicated on a theoretical situation and ignoring factors outside of that case.
Using fp16, it is still slower than the R300. If it is using intermixed integer ops, and thereby freely dropping the advantages of fp16 in intermixing ops, that performance parity can indeed be somewhat addressed in a realistic workload. However, PS 1.3 functionality is not clearly superior to PS 2.0 at fp24 with a performance lead, nor is "extended" functionality with integer precision (what we just mentioned) clearly superior to PS 2.0 at fp24 with intermittent performance parity, nor "extended functionality" with fp16 precision compared to PS 2.0 at fp24 and significantly slower performance. And all these situations are with a significant clock speed advantage.
It looks to me like a series of tradeoffs where a good case can also be made for the nv30 being inferior, and these are the best case situations for what you seem to be trying to propose as "superior".
Well, unless you are disregarding performance completely and want to discuss fp32 alone (though that seems odd in a discussion involving the performance offered by the integer pipeline), though that does seem to leave the door open for CPUs to compete.
Except if each unit was totally flexible like this, then it couldn't work on FP and Int together so well.Uttar said:
But we have known for some time that graphics cards are highly-pipelined. This is the only way to reach higher clock speeds, and is also necessary for hiding memory latencies (which is possible with smart caching and prediction). This is nothing new.
Sure, but only for calculations that don't need them. Why run at full precision for all calculations, if not all calculations need full precision? This makes whether or not the FX is superior dependent upon the nature of the shader being calculated (except in DirectX, where Microsoft has screwed nVidia). Unless you want to comment on precise shaders that would be used on significant portions of a game scene and require FP precision throughout for maximum quality, then go ahead. But just stating more precision for the sake of more precision is meaningless.demalion said:
Rather, it is superior for a select class of shaders. That means that it cannot be said that it is absolutely inferior. Exactly how well it will match up to the R3xx architecture depends hugely upon the application. Since most games will likely use similar shaders, it seems likely that one company made the right decision, and the other made the wrong one. What I don't see is any evidence in this thread which company that is.
Moved to this thread.Hey, Chalnoth and Uttar, why don't we take this to another thread where detailed technical analysis isn't occurring?
EDIT: OK, did. I do think my post is based on this analysis in a factual way, but I don't view the discussion being generated as anything to do with the thread topic (except for things I've already said).
Just click on the link in the post above to see if you agree.
EDIT: OK, did. I do think my post is based on this analysis in a factual way, but I don't view the discussion being generated as anything to do with the thread topic (except for things I've already said).
Just click on the link in the post above to see if you agree.
OpenGL guy
Veteran
A tenuous argument at best. You can emulate all the legacy features with floating point pixel shaders, just like on the R300, and the application need never know.LeStoffer said:
OpenGL guy
Veteran
My take is that nvidia's driver philosophy (any driver should work on any card) has finally failed them. I mean, it doesn't matter if old driver XX.XX doesn't work on new card Y: That's what driver developers get paid for. Hardware bring up is a fact of life for a driver engineer and new hardware will ship with new drivers so the fact that old drivers don't work is meaningless.LeStoffer said:
Also, all this unneeded complexity in the chip must make validation very difficult because of all the extra vectors that need to be tested.
Just my opinion.
I'm not so sure, Dave. First of all, weren't the NV2x chips only capable of one register combiner op per pixel pipeline per clock? This would make the NV3x have twice the integer processing power as the NV2x chips. Even if the NV2x did have 2 register combiner ops per pixel pipeline per clock, the FP portion of the NV3x could easily have picked up the slack.
In short, I don't really see backwards-compatibility being the entire reason.
I think that perhaps the best thing nVidia could have done is gone for 8 float ops + 4 int ops (instead of 4 float + 8 int). But, given the problems nVidia had manufacturing the NV30, I seriously doubt this was feasible.
In short, I don't really see backwards-compatibility being the entire reason.
I think that perhaps the best thing nVidia could have done is gone for 8 float ops + 4 int ops (instead of 4 float + 8 int). But, given the problems nVidia had manufacturing the NV30, I seriously doubt this was feasible.
Chalnoth said:
Yeah, but I'd guess the reason for doing 4 float + 8 int is more because of transistor cost. Although nVidia is traditionally VERY good at optimizing their cores for refreshes, enabling them to add a second unit of something. Wanna bet the NV35 will have 8 float, and at least 4 int ops/cycle?
Uttar