GeForce FX: 8x1 or 4x2?

I'm doing such shader test at the moment, see :

http://www.beyond3d.com/forum/viewtopic.php?t=4614

I'll try some texture + integer shaders ans post some results.

 

Well, pong was very popular. Just like this thread.

 

Yeah... I can already imagine one of nVidia's marketing points for the NV35:

"2nd Generation Flexible Pipeline Architecture, based on the world's most talked about pipeline organisation EVER!"


Uttar

 

If they'd operate like ATI, they'd just tell us what the hell the chip was doing. ATI was very clear: All ops are going through an FP24 pipeline, which can do a texture op and a vector op per cycle, and a bonus scalar op if the vector op only requires 3 components.

 

Yeah someone is prolly having a good laugh somewhere.

 

BTW, that last Inquirer story should probably credit B3d as well.

 

I thought they did give B3D credit?
(I still don't even know who runs the site LMFAO!!! I know it's sad )

 

the editor and chief is the same guy from the register. not that it is hard to tell when comparing the two sites.

 

An R300 fragment pipeline can do a 4-component vector color op (RGBA) along with a complex scalar op (on one of the vector components) in parallel (per cycle).

See the bottom post of this thread for the details: http://www.beyond3d.com/forum/viewtopic.php?t=3042&highlight=4+component

Just a little insight on the R300.

 

Fact remains: This info has been released to us.
Question: When will nVidia come 100% clean to us with the NV30's architecture?

 

Sometime after the NV35 is available

 

Nope:

 

i think sireric wins by defualt.

 

I doubt nVidia will ever fully-disclose the low-level aspects of the FX architecture. The only chip that they've done so in the past for has been the NV2A (X-Box chip), and it made sense to do so for that chip since it was made for a console, where the developers are encouraged to do very low-level optimizations.

Regardless, the actual low-level architectural specifics really aren't necessary for anybody outside of nVidia to know. They're just interesting for people like us. So, while you may complain about it, you really have no reason to "cry foul" about nVidia not fully-disclosing the low-level architecture except for your own desires.

What is important for nVidia with respect to the FX:

1. Dramatic performance improvements for PS 2.0 and ARB_fragment_program.

2. White papers on "how to optimize" for the architecture.

All of the relevant performance characteristics can be discovered through benchmarks. The theoretical figures are only useful in discovering how close real-world performance comes to the supposed "future potential" of the chip.

 

You've got it backwards...nVidia shouldn't require developers to have to sit there and read all these papers to get acceptable performance out of a sub-performing chip...

No...nVidia should engineer the thing in such a way that developers do not need to spin cycles in such areas...so that they can concentrate on bigger things...like, er, the games themselves.

 

from what I understood nVidias always been very good and helping devs optimize for their chips....much to many fanATIcs chagrin.

 

Yes, but I doubt that's what Typedef was saying.

nVidia has a habit of doing things their way and forcing it down the developers' throats. They've gotten away with it in the recent past because they were really the only cards you had to target, so developers would build their apps to work well on nVidia cards, and thus all the other minority IHVs had to develop their cards to meet the same requirements. Or in other words> nVidia is used to setting standards, not adopting them. (which, if you'll remember, was exactly 3dfx's problem as well)

Now the standards and nVidia's methodology are diverging. Targetting the standards for best performance means best (or atleast really good) performance on all the other IHVs cards, but to get optimal performance on nVidia's hardware you have to target their deviation.

The point is, you shouldn't need white papers on "how to optimize for nVidia hardware", or ATi hardware, or SiS hardware, or any other hardware; writing optimally for the standards ( ARB & D3D9 ) should equate to writing optimally for any cards that adopt those standards.

 

OK, I'll bite.

If nVidia has a habit of doing things their way and forcing it down the developer's throats, then you will be easily able to mention at least two concrete instances in which they have done this in the recent past? I thought so.

 

Exactly what I was going to suggest.
Game devs should concentrate on using ARB and DX standards and not on using specific codepaths for only 1 or 2 chipsets.
John Carmack has stated that the NV30's ARB2 path is much slower than the R300's ARB2 path, is that JC's fault or nVidia's?
Not everyone is John Carmack and not everyone is going to be writing an NV30 codepath, hence the NV30 will suffer if their driver team/s don't pull their socks up.

I have faith they will, that still doesn't explain if the NV30's architecture is faulty or not. In time we shall see.

 

- ps1.1 vs ps1.4 (ps1.4 performance is so bad that you have to resort to ps1.1 w/ multipass)
- NV30 vs ARB2 extensions (arb2 performance is so bad that you have to use nv30 specific extensions)
- Generally having their ARB extensions perform significantly worse than their proprietary extensions, forcing developers to adopt the latter as opposed to the 'right' way.
- Not supporting EMBM until it was dead (granted it was never a particularly nice feature)
- Not supporting npatches
- Dropping support for rt-patches
- No true support for displacement mapping (this goes for both ATi and nVidia)
- CG vs HLSL

To name a few (I could name a lot better examples if it wasn't for this sleep deprevation problem). They do it much more silently than saying "do it this way only". Normally it is done by just not adopting features their competitors have created, making sure developers don't make too extensive use of that feature (if at all), other times it is by focusing on their proprietary paths rather than the standard paths, still other times it is by creating a new standard and stubbornly sticking to it when the current standard is usually better (or atleast just as good) anyway. Basically, if a standard wasn't created by nVidia it either won't go into nVidia hardware, or will be poorly implemented so that no one uses it. Sometimes this is legitament (i.e. the feature sucks), most of the time is it just a way of silently killing the competition's tech at great expense to the industry as a whole.

Obviously nVidia isn't the only one that does this (it's common practice in most industries, especially by the companies controlling the largest percentages of the market), they just seem to do it more so than the other companies.