Just curious, is there any official channels to tell FM about the new beta 53.03 set that "fixes" the 3.40 patch? Or is just posting up here about it enough to get Worm's attention and hopefully reaction to this?
This doesn't make sense as FP16 is definitely unusable for vertex transformation.{Sniping}Waste said:Here are some test thhat show the problem With the VS 2.0 on the 5900U.
I have a Idea that the NV35 has 3 VS pipelines and each will do FP16 and it needs to cobine 2 pipelines to make FP32 and it kills the proformans like the 5800U and the PS 2.0 were it had to cobine 2 FP16 to make 1 FP32.
Xmas said:This doesn't make sense as FP16 is definitely unusable for vertex transformation.{Sniping}Waste said:Here are some test thhat show the problem With the VS 2.0 on the 5900U.
I have a Idea that the NV35 has 3 VS pipelines and each will do FP16 and it needs to cobine 2 pipelines to make FP32 and it kills the proformans like the 5800U and the PS 2.0 were it had to cobine 2 FP16 to make 1 FP32.
Also, the 5800 doesn't combine two FP16 units to form one FP32 unit. All FP ALUs are purely FP32 (except rsq, which is faster in FP16 mode). However, it can store two FP16 vectors in one FP32 register, and the architecture is very sensitive to register usage. That's the reason why FP16 is faster than FP32.
The vertex shaders doesn't contain FP16 at all, and has no need to. It's the pixel shader on the GeForce FX that can use FP16 to reduce register usage.{Sniping}Waste said:Thanks for the info. So how is nvivda boosting the FPS in game test 2,3, and 4? By going to FP16 for the VS reduse the register usage?Xmas said:This doesn't make sense as FP16 is definitely unusable for vertex transformation.{Sniping}Waste said:Here are some test thhat show the problem With the VS 2.0 on the 5900U.
I have a Idea that the NV35 has 3 VS pipelines and each will do FP16 and it needs to cobine 2 pipelines to make FP32 and it kills the proformans like the 5800U and the PS 2.0 were it had to cobine 2 FP16 to make 1 FP32.
Also, the 5800 doesn't combine two FP16 units to form one FP32 unit. All FP ALUs are purely FP32 (except rsq, which is faster in FP16 mode). However, it can store two FP16 vectors in one FP32 register, and the architecture is very sensitive to register usage. That's the reason why FP16 is faster than FP32.
digitalwanderer said:Hold on a sec, I just was informed that people are submitting the 53.03 set for comparison and the ORB is accepting them and giving out compare URL's for them and are just not allowing them to be considered for top scoring and what not...
...WHAT?!?!?!
What's the bloody point then?!?! I couldn't tell from the compare link that it was an un-official score, they should have "CHEATER DRIVERS!!!!" flashing in big red letters or something if they're going to allow 'em to submit scores!
I really didn't think un-allowed drivers were allowed to post scores, I don't see any incentive NOT to cheat now.
digitalwanderer said:Thanks for the explanation Tom, I wasn't aware of it being that way and it did sort of catch me out-o-the-blue like a nasty slap in the face.
I really was under the impression that "cheater" drivers weren't even allowed to publish scores and really do not like the way the system is currently, I'd much rather only have allowed drivers be able to even publish scores.
digitalwanderer said:Pagh, they should make the background for un-official results blazing red.
I'm curious if FM is going to take any actions with this 53.03 set which I'm betting nVidia is going to push as their "un-official official" set...at least for review purposes.
OMG, EB is in violation of FM's EULA!AzBat said:BTW, other than Hanners' article on EliteBastards, have any other site tried posting results using non-approved drivers in their articles and reviews? If there are, then maybe we need to notify Futuremark of them.