Luminescent
Veteran
Here is a post of mine from around June which extrapolates the whole two shaders per clock shabang from the results obtained by MDolnec's benchmark on AnteP's test system, a 5800 and 5900.DaveBauman said:
Games and Pixel Shader 2.0
- Thread starter Energy
- Start date
The first and thrid is a matter of opinion on both of us, who is best qualified to judge? I think ATi has proven the case for no INT and for TBDR, there's no comparable data to judge. (In other words I don't think they have proved it, all they done is prove you can build traditional design with a fast enough throughput so that you don't get hurt on SW which would benefit from TBDR) Yes the similarity to your first example is deliberate, ain't perspective great.
As for number 2, well seeing as both the likelyhood and impact of such an event is extremely low you'll excuse me if I put it under the 'ignore' category of my worries.
No, not GunMetal.tb said:
There are some new NVIDIA drivers (presently NDA'ed) which I'll be checking out with a NV35 and see what happens. Given that the game is a TWIMTBP game, features Cg and FP16 + FP32 for a certain texture format, it may prove to be interesting, especially when comparing with R3x0.
Uttar said:
IMO, that not the case. Given the transistor req's of FP32 they cannot have replaced all the FX12 units with FP32, so its reasonable to expect DX8 (int) performance to be traded off for for fewer float units, however clock for clock NV35 has exactly the same int performance as NV30.
Not in 5 million tranisors (and an increased bus in those 5M).
IIRC, the data we've seen was compatible with:
NV30 = 1FP32/2TEX + 2 FX
NV35 = 1FP32/2TEX + 2 FP16
Or maybe
NV35 = 1FP32/2TEX + 1 FP(16? 32?)
Certainly the reason NV35's performance on complex PS 2.0 shaders is not much different than NV30's is that it appears to suffer from the same extreme restrictions on temp register use. But I believe we've seen pretty clearly that dedicated FX12 units are no longer around--otherwise, how to explain the lack of performance difference between FX12 and FP16?
NV30 = 1FP32/2TEX + 2 FX
NV35 = 1FP32/2TEX + 2 FP16
Or maybe
NV35 = 1FP32/2TEX + 1 FP(16? 32?)
Certainly the reason NV35's performance on complex PS 2.0 shaders is not much different than NV30's is that it appears to suffer from the same extreme restrictions on temp register use. But I believe we've seen pretty clearly that dedicated FX12 units are no longer around--otherwise, how to explain the lack of performance difference between FX12 and FP16?
Heathen said:(In other words I don't think they have proved it, all they done is prove you can build traditional design with a fast enough throughput so that you don't get hurt on SW which would benefit from TBDR) Yes the similarity to your first example is deliberate, ain't perspective great.
You're hoisted by your own petard. You say all ATI has done is proven you can do a IR design which "fast enough" throughput that it won't get hurt on SW which would benefit from TBDR. Ok, under this criteria you suggest they have NOT proven that TBDR is not needed.
But all ATI has done with FP24 is proven that you can build a traditional design with "fast enough" throughput that it won't get hurt in SW which would benefit from INT/FP16. Ok, under this critera, you suggest that they HAVE proven INT is not needed.
See the contradiction?
You claim there isn't enough data with respect to TBDR. Well, that's because no one has designed a blazing TBDR and there are no games that push the limits of shading and depth complexity because developers always have IR designs in mind.
Well, with respect to INT/FP16, there isn't enough data, because no one has designed a blazing INT/FP16 card and there are no games that push the limits of multiprecision shading, because developers are concentrating on DX7/8 games mostly, and certainly not many are coding games specifically for a card only a small number of people own.
The fact of the matter is, we don't know how much of a benefit a good multiprecision design can eek out. Even forgetting multiprecision scalars, simply being able to allocate FP units in clusters is good: for example, I can do twice the number of 2D vector operations as 4D vector operations by packing two vectors into one register.
It is unknown how much benefit "unit pooling" and multiprecision will bring, since it depends on many factors, such as what the average shader will look like in the future. 3dLabs wildcat takes the unit clusting approach (as does Sun's MAJC) It's an area of research.
Thus, I would claim that neither multiprecision NOR TBDR have been disproven. "Proof" is a very strong word.
Ratchet said:
Well I hope it's not a secret, as I can put 2 + 2 together (and hopefully not make 5)
http://www.beyond3d.com/forum/viewtopic.php?t=6860Reverend said:
http://www.beyond3d.com/forum/viewtopic.php?t=7006
and http://www.nvidia.com/object/game_tombraider_aod.html
Hope i haven't let a cat out of a bag , but you (Reverend) have been dropping subtle hint's about it for the last couple of weeks. Please feel free to delete this if I've spoken out of turn.
Mark
I think Rev. has been playing with HL2.
http://www.ects.com/newsitem.asp?EDEV_ID=0&EDNE_ID=321
http://www.ects.com/newsitem.asp?EDEV_ID=0&EDNE_ID=321
Which answer would you prefer?
Where TBDR comes in I don't really care one way or another, I was trying to highlight the matter of differing perspectives on the issue. What you see as proof I don't and vice versa.
Of course it is, I don't disagree. But as I've tried to point out, proof is a metter of opinion in this sort of case. In my opinion ATI have proved that INT aren't needed, in your opinion they haven't.
TBDR was just an example on perspective.
Energy said:
Well, presumably, they'd use a HLSL that supports int, half, and float types. Then, on single precision architectures like ATI, everything would be upcast to FP24. On multiprecision architectures like the NV3x (and presumably, the 3dLabs VPU) it would depend on resources and optimization. (e.g. if I can issue one int and one fp32 per cycle, I might upcast one of my expressions so that I can issue two in parallel)
OGL2.0 HLSL supports int and float, but not half, however it has the right architecture to allow the driver to do the optimizations. DX9 HLSL has int, half, float, and double, but it compiles to PS2.0 and PS2.0 has no int or double registers. Right now, there is no Common HLSL that supports all the types, and allows the GPU driver to deal with them.
