R360 != 0.13 process ?

Ichneumon said:
Ahh...
So what you're saying is that if we code around the weaknesses inherant in the FX architecture, we get good performance.
That's not the point. The FX has more functional units than the R3xx series. A design tradeoff was definitely made between FP performance and FP+int performance. I don't see that as a weakness.

The register problem, that's a weakness.

However, the R3xx series proved that developers shouldn't have to bend over backwards to accomodate botched hardware designs. That is what general graphics API's are for... I am quite happy to be out of the days of Glide, CIF, and all that proprietary API/custom extesion nonsense. You should be too.
And they shouldn't. A compiler should be able to handle it. All a developer should have to do is use data types. Programmers have been using data types for ages...it's not a big thing to ask.
 
Chalnoth:

Considering the evidence presented by Cho, I think Cg is a bad idea for any non-Nvidia IHV.

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

Ichneumon is correct. Everyone should use the "standard" DX API. Proprietary compilers by vested interests are generally not a good idea, as we've seen with Glide toward the end of its usefulness, as well as S3's API, which never really took off anyways.
 
Natoma said:
Ichneumon is correct. Everyone should use the "standard" DX API. Proprietary compilers by vested interests are generally not a good idea, as we've seen with Glide toward the end of its usefulness, as well as S3's API, which never really took off anyways.
There are more higher-level shading languages than just Cg. Microsoft's HLSL may well be the better choice in Direct3D, and both companies should soon be supporting the new OpenGL shading language released with GL 1.5.

I do think that the OpenGL approach to the shading language is vastly superior to Microsoft's, however.
 
Chalnoth said:
I do think that the OpenGL approach to the shading language is vastly superior to Microsoft's, however.

You may be right... and frankly i'm reserving judgement 'till i see how the implementation turns out of ogl2 and IHV's implementations.

I get the feeling it will take significantly longer for IHVs to "get it right" for the new opengl vs. d3d in their drivers... but the extra work may very well turn out to be well worth it as you have suggested.

That still doesn't change my opinion that the FX series is simply either poorly designed and/or are poorly executed designs, which using their custom opengl extensions (effectively a proprietary API) allows them to perform adequately, but which show their significant flaws when running on general API usage. I always found that rather ironic given Nvidia's years of expounding how they designed hardware to general API spec back during the years of 3dfx....
 
Well, the big flashing warning light on the FX series is that despite the fact it has more integer units, and FP units that should be able to do integer ops, and a big clock speed advantage in the case of the 5800 and 5900, it really doesn't seem to outpower 9700/9800 on Integer shader operations either.
 
I think Nvidia spent so much time throwing in new cool features and a whole new paradigm of a flexible VPU that they forgot to make 3D rendering performance a priority.
 
Rugor said:
I think Nvidia spent so much time throwing in new cool features and a whole new paradigm of a flexible VPU that they forgot to make 3D rendering performance a priority.

I agree and disagree.

If nVidia's only competition was the NV2x, the raw 3D rendering performance looks just fine. I think the primary issue is nVidia underestimating what ATI had in the R300.
 
IIRC someone (Dave?) mentioned how ATI does not like to introduce a new process tech with a new core design. If so then this would be ATI’s last chance to test the .13 process with a high transistor chip. If they have problems the R350 gives them a fall back. I think it would be a wise move for ATI try this on the R360.
 
DaveBaumann said:
Well, the big flashing warning light on the FX series is that despite the fact it has more integer units, and FP units that should be able to do integer ops, and a big clock speed advantage in the case of the 5800 and 5900, it really doesn't seem to outpower 9700/9800 on Integer shader operations either.
From where do you get this info?
 
GeForce FX have more integer units ? AFAIK it's only the case in NVOGL when you don't use texturing.

In PS 1.1,

a GeForce FX 5800/5900 has 8 integer units and 8 texturing units
a GeForce 4 Ti has 8 integer units and 8 texturing units
a Radeon 9700/9800 has 8 "integer" units and 8 texturing units

Radeons can reach more easily their maximum 'fillrate' because they have 8 pipelines.

GeForces need well suited shader to reach their maximum fillrate:

tex
tex
math
math
tex
tex
math
math
...

GeForce FX have higher frequencies but in many cases this is not enough to reach Radeons performances.
 
a GeForce FX 5800/5900 has 8 integer units and 8 texturing units

Plus 4 FP32 units (or texture adress processors) - I'd have assumed that the FP units would have been put into operation under DX8 tasks as well (when texturing isn't being utilised) and just convert the result to int, much like ATI uses its FP24 units for all instructions. If this there the case then it would have a max of 12 shader units that could be used for DX8 operations (given the right conditions).
 
DaveBaumann said:
a GeForce FX 5800/5900 has 8 integer units and 8 texturing units

Plus 4 FP32 units (or texture adress processors) - I'd have assumed that the FP units would have been put into operation under DX8 tasks as well (when texturing isn't being utilised) and just convert the result to int, much like ATI uses its FP24 units for all instructions. If this there the case then it would have a max of 12 shader units that could be used for DX8 operations (given the right conditions).

I was thinking like you. But it's not the case :( The FP units don't seem to work with PS1.1.
 
Tridam said:
I was thinking like you. But it's not the case :( The FP units don't seem to work with PS1.1.

Ahhh, well, that does put it on par in terms of "functional shader units" with R300, but that doesn't explain why its still slower in operation with a heavy clock speed advantage. Would you think that co-issue on R300 would really be helping short DX8 shaders that much?

Interesting though - I guess there is no float to int conversation available between the FP and FX units which is why they can't be utilised. This makes the int/float pipeline they have and even more of an odd choice in my mind.

[edit] That also tears any notion that NV35 has had its FX units replaced by FP units. We' already shown that in most of the operations were inline with NV30 and its clockspeed differences, but with the DX8 performance being high on exactly the same they certianly can't have replaced any FX units with FP ones.

Do you have any code that proves this is the case?
 
DaveBaumann said:
Ahhh, well, that does put it on par in terms of "functional shader units" with R300, but that doesn't explain why its still slower in operation with a heavy clock speed advantage. Would you think that co-issue on R300 would really be helping short DX1 shaders that much?

It could help. But on another side, each FX unit is able to do 2 MUL. I think the problem comes from longer pipelines. For example :

tex
tex
mad
mad
mul

2 cycles on GeForces (4 pixel)
3 cycles on Radeons (but 8 pixel !)

-> Radeon 33% faster

DaveBaumann said:
Interesting though - I guess there is no float to int conversation available between the FP and FX units which is why they can't be utilised. This makes the int/float pipeline they have and even more of an odd choice in my mind.

In 'NVOGL', thepkrl show that they can use the FP units for FX calculations.

DaveBaumann said:
[edit] That also tears any notion that NV35 has had its FX units replaced by FP units. We' already shown that in most of the operations were inline with NV30 and its clockspeed differences, but with the DX8 performance being high on exactly the same they certianly can't have replaced any FX units with FP ones.
I agree.

DaveBaumann said:
Do you have any code that proves this is the case?
I can't give my framework :( (because it's not mine)
But this is easy to prove with small shader.
 
Tridam said:
I was thinking like you. But it's not the case :( The FP units don't seem to work with PS1.1.
The NV3x probably works on a "GeForce3/4 model" for rendering PS 1.1-1.3. This means that the FP32/texturing unit will be used for texturing commands, with the int units for arithmetic commands.
 
Hey, Joe. . .actually read Article V lately? Good luck getting rid of Rhode Island's senators!
 
An amendment to the Constitution that changed equal representation by state in the Senate would be unconstitutional if it did not have the consent of every state that was affected. So says Article V. A reference to what I took to be your having fun with Natoma's quote in your siggie.
 
Back
Top