Am I right?
- Thread starter K.I.L.E.R
- Start date
Quality AF is identical on NV2x and NV3x, however NV3x offers a different form of performance AF. So it's very likely NV3x uses an extended version of NV2x AF algorithm with more configurable parameters.
The same result doesn't mean the same algorithm was used.
Depends on how far you break down the algorithm. 487 processes divides differently than Pentium FPU, but the result is the same, assuming no bugs.
The same result doesn't mean the same algorithm was used.
What I thought was proven was that the best AF (in terms of image quality) that the NV3x could offer was the same as the best for NV25. As Xmas mentions, the NV3x aniso just seems to be significantly more configurable. From the standpoint of performance, and image quality when taking framerate into account, I think that makes it simply better.
The problem here is the way nVidia is using it and what they are calling it, not the AF capabilities themselves (as it appears they can function). There are some games (the same games where the 8500 AF is sufficient, for example, or so I presume) where the limited trilinear seems like it could offer better over all solution between the two...it is just a problem when nVidia is deciding those games instead of the user (apparently based on the criteria of boosting fps results in programs used as fps benchmarks), when they try to pass it off as full trilinear, and when such information is kept from consumers.
Also, to my understanding, their "good optimization guidelines" wouldn't have to change this behavior, because it is not unique to benchmark mode and "image quality is subjective".
For contrast, ATI's current control panel behavior (except maybe the 9600 in some of Wavey's tests?) share the 2nd fault and 3rd fault, except that the "Application Preference" option is clearly offered as well, and that sites like Beyond 3D are spreading the information. More need to do the same to continue to improve things (being less at fault than what nVidia is doing doesn't mean they aren't at fault at all), though the "Application Preference" distinction seems to be lost on atleast the 3dcenter.de article's discussion of UT2k3. They seem to propose rtool as the only way to get full trilinear for the R3xx cards is using rtool, like the only way for the NV3x for UT2k3 is using the "Anticheat scripts", which would be incorrect...then again, I don't read German well, and maybe that distinction was covered.
Of course, the other IHVs (except perhaps SiS?) don't seem to be at fault at all in this regard, though I'm not sure how many of them offer even up to 8x aniso.
Looking ahead for the NV3x...there seems to be implication that the "Application Preference" will return, but there doesn't seem to be any guarantee with regards to no application detection beahvior modification while using it. nVidia seems to consider "full trilinear on all texture stages" as "debugging aniso" and seems confortable with making "image quality" decisions...I guess we'll have to wait and see how things end up when the features are delivered (or maybe one of the beta drivers released recently show it?).
The problem here is the way nVidia is using it and what they are calling it, not the AF capabilities themselves (as it appears they can function). There are some games (the same games where the 8500 AF is sufficient, for example, or so I presume) where the limited trilinear seems like it could offer better over all solution between the two...it is just a problem when nVidia is deciding those games instead of the user (apparently based on the criteria of boosting fps results in programs used as fps benchmarks), when they try to pass it off as full trilinear, and when such information is kept from consumers.
Also, to my understanding, their "good optimization guidelines" wouldn't have to change this behavior, because it is not unique to benchmark mode and "image quality is subjective".
For contrast, ATI's current control panel behavior (except maybe the 9600 in some of Wavey's tests?) share the 2nd fault and 3rd fault, except that the "Application Preference" option is clearly offered as well, and that sites like Beyond 3D are spreading the information. More need to do the same to continue to improve things (being less at fault than what nVidia is doing doesn't mean they aren't at fault at all), though the "Application Preference" distinction seems to be lost on atleast the 3dcenter.de article's discussion of UT2k3. They seem to propose rtool as the only way to get full trilinear for the R3xx cards is using rtool, like the only way for the NV3x for UT2k3 is using the "Anticheat scripts", which would be incorrect...then again, I don't read German well, and maybe that distinction was covered.
Of course, the other IHVs (except perhaps SiS?) don't seem to be at fault at all in this regard, though I'm not sure how many of them offer even up to 8x aniso.
Looking ahead for the NV3x...there seems to be implication that the "Application Preference" will return, but there doesn't seem to be any guarantee with regards to no application detection beahvior modification while using it. nVidia seems to consider "full trilinear on all texture stages" as "debugging aniso" and seems confortable with making "image quality" decisions...I guess we'll have to wait and see how things end up when the features are delivered (or maybe one of the beta drivers released recently show it?).
A problem with the comparison to CPUs: general purpose CPUs expose an instruction set; the only input and output from the CPU is in terms of the instruction set. And different cores in the same ISA family almost always guarantee the exact same behavior (with some very minor and documented exceptions, e.g. imprecise interrupts w.r.t. floating point), other than performance (obviously). Unless there is a bug, any x86 chip should give the exact same output as any other when presented with a particular sequence of instructions. Even though the algorithms used to calculate particular instructions may be very different.
GPUs, on the other hand, are ASICs. They do not present a well-defined ISA to the programmer; rather they only promise to be able to perform (a subset of) the rendering commands of a couple of comparitively loosely defined APIs, which are translated to GPU commands in software (in the drivers) rather than in hardware where ISA instructions are handled in a CPU. As neither OpenGL nor DirectX is particularly specific about what exact output should be expected for "anisotropic filtering" (nor for much of anything else), there is no reason why a new core should be expected to give the same AF output as any other core.
This doesn't speak to the factual question of whether the NV3x AF implementation does indeed give different output than the NV2x implementation; only that it can, whereas the Pentium4 version of any x86 instruction has to give the exact same results as that instruction on any x86 chip from the Athlon to the 8086.
GPUs, on the other hand, are ASICs. They do not present a well-defined ISA to the programmer; rather they only promise to be able to perform (a subset of) the rendering commands of a couple of comparitively loosely defined APIs, which are translated to GPU commands in software (in the drivers) rather than in hardware where ISA instructions are handled in a CPU. As neither OpenGL nor DirectX is particularly specific about what exact output should be expected for "anisotropic filtering" (nor for much of anything else), there is no reason why a new core should be expected to give the same AF output as any other core.
This doesn't speak to the factual question of whether the NV3x AF implementation does indeed give different output than the NV2x implementation; only that it can, whereas the Pentium4 version of any x86 instruction has to give the exact same results as that instruction on any x86 chip from the Athlon to the 8086.
Actually, I am not sure that this is correct. I'm pretty sure it isn't for the complex math ops (fsin, fcos etc.).Dave H said:
My information on this is based on the 486 manual I have - Intel spend a very great deal of time plugging how accurate their FPU is and showing error domains for different operations. It even states a certain accuracy bound for non-transcendental operations.
That strongly implies that the exact result may be marginally different between different x86 implementations and there is no requirement for perfect accuracy.
However, I do believe that all modern x86 CPU's guarantee to deliver the correctly rounded result on 'simple' operations, certainly at anything below extended precision, and it's possible that they really do actually deliver the same results.
Well, the wording in the spec is "exactly rounded." Not very big difference.
It means the results are the same as exactly computed and then rounded.
Transcendental functions are not required to be exactly rounded because of "table maker's dilemma." Of course, this is getting OT
It means the results are the same as exactly computed and then rounded.
Transcendental functions are not required to be exactly rounded because of "table maker's dilemma." Of course, this is getting OT
