New cheats exposed at DigitLife
- Thread starter BoardBonobo
- Start date
Well I know very little on shader programming but even the pictures that digit life used of the PS2.0 benchmark don't seem completely useless.
The differences ati show from the ref are mostly small. The difference picture on the whole is pretty much random noise, theres lots of it but nothing obvious (except the shadow right under the base, not sure whats going on there).
Then you can look at the FX 44.65 picture. The differences actually follow patterns, you can see a grain pattern in the base and something seems to be up with the way the models shine a bit.
This suggests more to a shader replacement or modification to me
or am i talking bs?
The differences ati show from the ref are mostly small. The difference picture on the whole is pretty much random noise, theres lots of it but nothing obvious (except the shadow right under the base, not sure whats going on there).
Then you can look at the FX 44.65 picture. The differences actually follow patterns, you can see a grain pattern in the base and something seems to be up with the way the models shine a bit.
This suggests more to a shader replacement or modification to me
or am i talking bs?
chavvdarrr
Veteran
Re: Unbelievable IMHO
Kristof said:
chavvdarrr
Veteran
Re: Unbelievable IMHO
agree, IMHO their article is far from perfection - but it's not a crap either.andypski said:
Pete said:
Heh, ok, I didn't express my impressions in the most intellectually refined way, but informal forum discussion is really not subject to the same standards as a serious article like that in question. A more matter-of-fact style would serve the purpose better there.
Differences between refras and real hw are not just limited to FP24. The ordering of operations in the vertex shader, and the implementation of that HW can lead to slight vertex data lsb changes. As well, clipping can performed differently on different architectures, which can, again, lead to differences in lsbs of data.
Then, setup and rasterization can lead to more differences. Typically, a hw unit will sort vertices for each vertex, so that a permutation of vertices will not change what is rendered. However, there's no set way to do that sort; each method is different. As well, what precision is maintained for iteration and for Z computations is going to be different. At this point, you could do Z in FP or integer, but how many bits? Each hardware version will give slightly different results. You could even imagine a 1/2 pixel shift, between HW versions. Shading and precision in shading will lead to more differences. As well, reduction to the final frame buffer (from shader precision downto 8b/comp) can be done in several ways; another 1/2 lsb of change is trivial there.
In general, we shoot for "self-consistency" -- We assume that data coming in does not have gaps or T-vertices, and we guarantee not to introduce any. But small differences will be abudant -- And have always been there.
At the end, even WHQL certification is aware of that process, and uses a fuzzy compare to a reference image, on very SIMPLE geometry. With a complexe scene, the differences will increase even more.
At the end, the following seems true to me:
1) Doing pixel compares to the refras is a waste of time.
2) Doing pixel compares between two different HW implementations, is a waste of time.
3) Comparing images between two drivers on the same HW can give you a little information, but it's very fluffy. Generally a new driver means *something has* changed.
4) Comparing the same hw, the same drivers, but with changes in the apps or with app detect, can have value, if done properly.
Then, setup and rasterization can lead to more differences. Typically, a hw unit will sort vertices for each vertex, so that a permutation of vertices will not change what is rendered. However, there's no set way to do that sort; each method is different. As well, what precision is maintained for iteration and for Z computations is going to be different. At this point, you could do Z in FP or integer, but how many bits? Each hardware version will give slightly different results. You could even imagine a 1/2 pixel shift, between HW versions. Shading and precision in shading will lead to more differences. As well, reduction to the final frame buffer (from shader precision downto 8b/comp) can be done in several ways; another 1/2 lsb of change is trivial there.
In general, we shoot for "self-consistency" -- We assume that data coming in does not have gaps or T-vertices, and we guarantee not to introduce any. But small differences will be abudant -- And have always been there.
At the end, even WHQL certification is aware of that process, and uses a fuzzy compare to a reference image, on very SIMPLE geometry. With a complexe scene, the differences will increase even more.
At the end, the following seems true to me:
1) Doing pixel compares to the refras is a waste of time.
2) Doing pixel compares between two different HW implementations, is a waste of time.
3) Comparing images between two drivers on the same HW can give you a little information, but it's very fluffy. Generally a new driver means *something has* changed.
4) Comparing the same hw, the same drivers, but with changes in the apps or with app detect, can have value, if done properly.
http://www.beyond3d.com/forum/viewtopic.php?p=139234#139234
... as a matter of info, no more, of course.
... as a matter of info, no more, of course.