101302, 09:09 PM  #25  
Registered User
Join Date: Jul 2002
Posts: 1,293

Quote:
Quote:


101302, 10:09 PM  #26  
AgentFx
Join Date: Aug 2002
Location: everywhere
Posts: 2,216

Quote:
method at some angles ,even if the harware is fully capable of doing anisoF full time ? i think so .. Quote:
exactly ,it will be nice if websites show in reviews slowdowns in framerates and artifacts errors , lately ,TomsH latest review of the Geforce4 mxagp 8x vs radeon9000 (a very good one) shows graphs that tells the worst performance case for both cards .. http://www6.tomshardware.com/graphic...8_nv2806.html 

101302, 10:54 PM  #27  
Registered User
Join Date: Jul 2002
Posts: 1,293

Quote:
Well, not an absolute impossibility, but the idea is so unfeasible once you think about it that it's just not going to happen. Basically, it's like this. The Radeon 9700 and the GeForce line calculate the anisotropic degree in different ways. The GeForce line of cards uses a smooth function that gives the same result regardless of angle (I can't be certain if nVidia elected to use the proper function, or just a smooth approximation), whereas the Radeon 9700 uses a different function entirely that appears to be based upon absolute values. What you should get from this is that the same hardware simply cannot be used to compute the degree of anisotropic for both cases, so supporting both would be idiotic as it would require specialized hardware for each case. Quote:


101402, 08:02 AM  #28  
Registered User
Join Date: Jul 2002
Posts: 1,430

Quote:
Quote:
Quote:
Quote:
Quote:


101402, 10:12 AM  #29  
Registered User
Join Date: Jul 2002
Posts: 1,293

Quote:
Quote:
Quote:


101402, 11:57 AM  #30  
Registered User
Join Date: Jul 2002
Posts: 1,430

Quote:
Quote:
Quote:
But back to the point you do realize that its the same AF method they used back in the R8500 just with an tweak to handle angles better. Thus its a perfromnace tweak as ATI themselves have stated..... 

101402, 07:41 PM  #31  
Registered User
Join Date: Jul 2002
Posts: 1,293

Quote:
Quote:
Basically, there are some scenes that will always show some edge AA for every single edge with 4x+ MSAA enabled, and some scenes where certain edges will always show no AA. For 2x SSAA, in almost every single complex scene, there will always be some edges that will show no AA. To say that MSAA always fails seems to be assuming that every single edge that is displayed is on an alphatested texture. That's just ludicrous. Quote:
Quite simply, just as you've stated yourself (but in other words), the percent of the screen in most FPS situations that has reduced degrees of anisotropic is just too small to make for any significant performance benefit. Therefore, the only possible performance discrepancy can come from the calculation of the anisotropic degree, which will vary between different methods. Still, it is more than possible to have hardware that calculates anisotropic in any possible way once per clock per texture pipeline. This makes it solely a transistor count optimization. Update: One final thing on the personal attacks. I was merely stating that if your background had as much bearing on this situation as you thought it did, then you would agree with me on the point I made above. It's not very hard to figure out. Oh, one final final thing. I never have said that ATI's anisotropic was broken, a hack, or a cheat. I'm just saying that it seems silly to me that ATI has yet to implement a good degreeselection algorithm, especially now with a 100+ million transistor product that supports the exact same number of transistors as their previous product. As a side note, however, it appears that the 8500>9700 implementation change would take exactly twice the computational power in selecting the degree of anisotropic. This means, to me, that ATI's drop to one texture per pixel pipeline probably didn't affect the anisotropic degree selection hardware hardly at all. That is, there's still enough hardware to select two anisotropic degrees per pixel pipeline, but they are now combined to support a somewhat better algorithm. It really, really seems to me like doing the proper aniso degree selection (which something along the lines of sqrt(x^2 + y^2), as opposed to the absolute values that ATI apparently uses) would be very close to the same expense in transistors. Last edited by Chalnoth; 101402 at 07:53 PM. 

101402, 08:23 PM  #32 
Registered User
Join Date: Jul 2002
Posts: 1,293

If you'd like to see the OpenGL aniso specs, here they are:
http://oss.sgi.com/projects/oglsamp...nisotropic.txt Here's the relevant portion: "Anisotropic texture filtering substantially changes Section 3.8.5. Previously a single scale factor P was determined based on the pixel's projection into texture space. Now two scale factors, Px and Py, are computed. Px = sqrt(dudx^2 + dvdx^2) Py = sqrt(dudy^2 + dvdy^2) Pmax = max(Px,Py) Pmin = min(Px,Py) N = min(ceil(Pmax/Pmin),maxAniso) Lamda' = log2(Pmax/N) where maxAniso is the smaller of the texture's value of TEXTURE_MAX_ANISOTROPY_EXT or the implementationdefined value of MAX_TEXTURE_MAX_ANISOTROPY_EXT. It is acceptable for implementation to round 'N' up to the nearest supported sampling rate. For example an implementation may only support poweroftwo sampling rates. It is also acceptable for an implementation to approximate the ideal functions Px and Py with functions Fx and Fy subject to the following conditions: 1. Fx is continuous and monotonically increasing in du/dx and dv/dx. Fy is continuous and monotonically increasing in du/dy and dv/dy. 2. max(du/dx,dv/dx} <= Fx <= du/dx + dv/dx. max(du/dy,dv/dy} <= Fy <= du/dy + dv/dy. If you'll note, the specs allow for an approximation of the Px and Py functions, but the rest of the aniso degree selection calcs must be the same. It appears that ATI uses the sum of absolute values in their approximation. The 8500 presumably uses the sum of two absolute values, whereas the 9700 apparently uses the sum of four (I'm not entirely certain exactly what is used, but this does seem to be the case based on the data that's been put out to date). It seems to me that this is getting preciousclose to the calculation power needed to just use the true functions Px and Py. By the way, to see how I arrived at this conclusion as to how ATI apparently does the math, consider the following two functions: 8500type method: Fx = du/dx + dv/dx Fy = du/dy + dv/dy You might see how this could produce lines similar to: \/ 9700type method: Fx = (du/dx  a + dv/dx  a)  (du/dx + a + dv/dx + a) Fy = similar (Disclaimer: Written as is, this probably won't conform to specs. By modifying the value for a and scale factors, such as adding a constant to the entire equation, or multiplying the entire equation by a constant, should be enough to make the equation conform) And this should produce lines similar to: \_/ If you'll note, I actually based these calcs on MIP map selection algorithms, which appear to be very highly related (If you look at the math, it's almost identical...and the differences in MIP lines seem to coincide perfectly with the differences in aniso selection algorithms). After looking at this, it really seems even more blatant to me that even from a transistor count perspective, that it would have been a good idea to go with the real function instead. The only possible problem may be the square root. That function may take a number of transistors, but I'm not really sure how many... 
101502, 09:36 AM  #33 
Registered User
Join Date: Jul 2002
Posts: 1,293

Oh, and one last thing, for those who care about this technical stuff.
I just realized that the square root is absolutely trivial. Since there is a logarithm that must be done after calculating the Px and Py, all that you would need to do is keep all of the previous values before calculating that log as squares, and divide the result after the log by 2. This is absolutely trivial, as it consists of just truncating the last digit. So, I really see no reason why ATI should have gone the route they did with the Radeon 9700. It now is seeming to me like it was more of an engineering cost issue. They wanted to spend time elsewhere instead, feeling that their aniso implementation was, "good enough," and would rather spend time on other things. 
101502, 12:48 PM  #34  
Registered User
Join Date: Jul 2002
Posts: 1,430

Quote:


101502, 03:57 PM  #35  
Registered User
Join Date: Jul 2002
Posts: 1,293

Quote:
Quite simply, the GeForce4 does not have the ability to calculate the degree of anisotropic for two textures per clock, which, for most cases effectively makes the GeForce4 a 4x1 card when anisotropic is enabled. This alone is enough to reduce the performance significantly (It can be made a 4x2 card with aniso enabled if anisotropic is enabled only for the second and fourth texture stages...). 

101502, 09:01 PM  #36  
Registered User
Join Date: Oct 2002
Posts: 236

Quote:
You're just fogging the issue. Sure...with high enough transistor budget (additional logic) and bandidth, etc, you may 'negate' a performance penalty. Though one can do the same for increasing aniso quality on the Radeon. All that matters is practically speaking how do the two compare? GeForce=More uniform quality Radeon = faster. Quote:


Thread Tools  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
R9700 Oficially Announced  druga runda  Other Desktop Graphics Cards  20  042508 10:28 PM 
My UT2003 Tweak Guide  DXnfiniteFX  Gaming Central  48  103002 11:59 PM 
Understanding CineFX  MUCH more than the R300  Uttar  Rumor Mill  68  100202 01:02 AM 
FalconNW and Voodoo under ATI 9700 spell!!!  mizzer  Other Desktop Graphics Cards  12  092002 07:53 PM 
GeForce4 image quality  need some HONEST opinions  ErrorS  NVIDIA GeForce 7, 8, And 9 Series  24  082202 06:39 AM 