Go Back   nV News Forums > Graphics Card Forums > Other Desktop Graphics Cards

Newegg Daily Deals

Reply
 
Thread Tools
Old 10-13-02, 09:09 PM   #25
Chalnoth
Registered User
 
Join Date: Jul 2002
Posts: 1,293
Default

Quote:
Originally posted by Nv40
[b]Notice the key word here is choose ,i think it is
alot better if ATi lets their customers to choose when they
want a part time 16x/4x aniso or when they want a
full time aniso like Nvidia have been doing always.
all-ways .
Not a possibility, NV40. It's a hardware implementation issue. Quite simply, it takes more transistors to do a comprehensive aniso technique.

Quote:
i dont trust too much in standar game benchmarks ,like most people , because timedemos like those made in quake3 engines
or unreal 1/2 engines tells you at the end only the average frame rate at x or y game . but they never tell you exactly
how smooth the game will run at all-times..
Actually, UT2k3 does output spreadsheets that show exact framerates for each frame, from which you can easily compose framerate graphs. It would be nice if some websites would post benchmarks reflecting these results.
Chalnoth is offline   Reply With Quote
Old 10-13-02, 10:09 PM   #26
Nv40
Agent-Fx
 
Nv40's Avatar
 
Join Date: Aug 2002
Location: everywhere
Posts: 2,216
Default

Quote:
Originally posted by Chalnoth
Not a possibility, NV40. It's a hardware implementation issue. Quite simply, it takes more transistors to do a comprehensive aniso technique.
dont you think it is possible via drivers to limit the anisoF
method at some angles ,even if the harware is fully
capable of doing anisoF full time ? i think so ..


Quote:
Actually, UT2k3 does output sprea
dsheets that show exact framerates for each frame, from which you can easily compose framerate graphs. It would be nice if some websites would post benchmarks reflecting these results.
.

exactly ,it will be nice if websites show in reviews
slowdowns in framerates and artifacts errors , lately ,TomsH
latest review of the Geforce4 mx-agp 8x vs radeon9000
(a very good one) shows graphs that tells the worst performance
case for both cards ..

http://www6.tomshardware.com/graphic...8_nv28-06.html
Nv40 is offline   Reply With Quote
Old 10-13-02, 10:54 PM   #27
Chalnoth
Registered User
 
Join Date: Jul 2002
Posts: 1,293
Default

Quote:
Originally posted by Nv40
dont you think it is possible via drivers to limit the anisoF
method at some angles ,even if the harware is fully
capable of doing anisoF full time ? i think so ..
No, it is an impossibility.

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:
exactly ,it will be nice if websites show in reviews
slowdowns in framerates and artifacts errors , lately ,TomsH
latest review of the Geforce4 mx-agp 8x vs radeon9000
(a very good one) shows graphs that tells the worst performance
case for both cards ..
It would be nicer if they would release statistic based on the framerate information such as standard deviation, which is a measurement of how much the data varies from the mean (average) framerate. After all, just showing the minimum or showing the number of significant drops in framerates are both very subjective measures. A standard deviation is very objective and would give a very good idea of how stable the framerates are.
Chalnoth is offline   Reply With Quote
Old 10-14-02, 08:02 AM   #28
jbirney
Registered User
 
jbirney's Avatar
 
Join Date: Jul 2002
Posts: 1,430
Default

Quote:
I've posted on this again and again, and the answer is simple: the alpha test/MSAA problem is solvable through programming.
Please stop saying this is a developer problem. Its not. Its a hardware limitation. End of case. Now it does have a work around in software and developers will start to use it. Alpha test were created for a reason, have been used for a long time and still have a purpose in today's games.

Quote:
But rotated planes do happen, in each and every single game.
Once again I really would suggest trying one out before you say this is such and issue. SS:SE was the ONLY game that I have noticed it in all of the FPS I have played. Yes it does drop down in its AF filtering but I really think you guys really just love to argue a fact and will take any point no matter how little it actually effect your game play...

Quote:
Oh, and one final thing. The worst-case scenarios for 2x SSAA and other forms of MSAA are the same, if you want to include alpha tests. Both will apply no FSAA in certain situations (MSAA due to how a game is made, SSAA at certain angles). You'd have to go up to at least 4x SSAA to make the appropriate comparison you were attempting to make.
False. MSAA will never apply AA. SS will if the correct sampling pattern is chosen in the x2 case

Quote:
You discuss this as if it's a "solution to a problem"... something ATI just hasn't been able to figure out yet.
Exactly. Being an EE with more than 10 years of real work experience has taught me every thing about engineering is do-able so long as you are willing to pay the price. Fact its every single design has to make trade offs in order to meet the design goals, product specs or ship date. ATI's AF is not broken. Its working to a margin that is acceptable to ATI and for 99.5% of the other people out there. Sure its not perfect but ATI new what they were doing and agreed that the performance increase is worth a few cases were it falls to a level at or one degree worse then its competitors. Others may disagree and that's fine as they have other beliefs.

Quote:
Notice the key word here is choose ,i think it is
alot better if ATi lets their customers to choose when they
want a part time 16x/4x aniso or when they want a
full time aniso like Nvidia have been doing always.
all-ways .
I would rather have an adaptive ansio that gives me x16 most of the time and only drops to x8 or x4 under certian conditions that dont show up in many of the FPS shooters with out the larger pef hit. Of course others may want the x8 all the time but will have to suffer the perfromance hit. To each their own...
jbirney is offline   Reply With Quote
Old 10-14-02, 10:12 AM   #29
Chalnoth
Registered User
 
Join Date: Jul 2002
Posts: 1,293
Default

Quote:
Originally posted by jbirney
Please stop saying this is a developer problem. Its not. Its a hardware limitation. End of case. Now it does have a work around in software and developers will start to use it. Alpha test were created for a reason, have been used for a long time and still have a purpose in today's games.
It doesn't matter. Neither ATI nor nVidia are going back to a full-screen supersampling technique. This should be absolutely obvious to everybody by now. This means the ball's in the developer's court.

Quote:
False. MSAA will never apply AA. SS will if the correct sampling pattern is chosen in the x2 case
You seem to misunderstand. With 2x AA enabled, there will be some edge angles to which no AA is actually applied (i.e. when the triangle edge is parallel to the sampling pattern). This is not the case with 4x AA or higher.

Quote:
Exactly. Being an EE with more than 10 years of real work experience has taught me every thing about engineering is do-able so long as you are willing to pay the price. Fact its every single design has to make trade offs in order to meet the design goals, product specs or ship date. ATI's AF is not broken. Its working to a margin that is acceptable to ATI and for 99.5% of the other people out there. Sure its not perfect but ATI new what they were doing and agreed that the performance increase is worth a few cases were it falls to a level at or one degree worse then its competitors. Others may disagree and that's fine as they have other beliefs.
If you're an EE with so much experience, it should be obvious to you that this is not a performance optimization, but a transistor budget decision.
Chalnoth is offline   Reply With Quote
Old 10-14-02, 11:57 AM   #30
jbirney
Registered User
 
jbirney's Avatar
 
Join Date: Jul 2002
Posts: 1,430
Default

Quote:
Originally posted by Chalnoth
It doesn't matter. Neither ATI nor nVidia are going back to a full-screen supersampling technique.
Oh really then why do we keep hearing about a SS mode being availble in the R300 just disabled for now in the drivers?


Quote:
You seem to misunderstand. With 2x AA enabled, there will be some edge angles to which no AA is actually applied (i.e. when the triangle edge is parallel to the sampling pattern). This is not the case with 4x AA or higher.
No I Understand what you ment but your wording in not correct. If you wrote a very adaptive edge detection algorithm then even in x2 mode you could have a sample point inside the edge and detect it. However thats not the point here. We are taking about a method that NEVER will when Alpha test is used vers a method that fails only under certin conditions...


Quote:
If you're an EE with so much experience, it should be obvious to you that this is not a performance optimization, but a transistor budget decision.
You know for one that complains about personal attacks so much you would think you would not attack others like this. Thanks for the cheap shot. BTW I am not a graphics designer. I do have experince in DSP, Digital, some IC Fab work and Cell phone/pagers design (including protocol, analog, RF and Manufacturing). So I know enough about how to design for many different enviorments.

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.....
jbirney is offline   Reply With Quote
Old 10-14-02, 07:41 PM   #31
Chalnoth
Registered User
 
Join Date: Jul 2002
Posts: 1,293
Default

Quote:
Originally posted by jbirney
Oh really then why do we keep hearing about a SS mode being availble in the R300 just disabled for now in the drivers?
Talk does not equal implementation.

Quote:
No I Understand what you ment but your wording in not correct. If you wrote a very adaptive edge detection algorithm then even in x2 mode you could have a sample point inside the edge and detect it. However thats not the point here. We are taking about a method that NEVER will when Alpha test is used vers a method that fails only under certin conditions...
Um, when an alpha-tested texture displayed doesn't count as "certain conditions?"

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 alpha-tested texture. That's just ludicrous.

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.....
It's not a performance tweak, not in the least.

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 degree-selection 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; 10-14-02 at 07:53 PM.
Chalnoth is offline   Reply With Quote
Old 10-14-02, 08:23 PM   #32
Chalnoth
Registered User
 
Join Date: Jul 2002
Posts: 1,293
Default

If you'd like to see the OpenGL aniso specs, here they are:

http://oss.sgi.com/projects/ogl-samp...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 implementation-defined 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 power-of-two 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 precious-close 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:

8500-type method:
Fx = |du/dx| + |dv/dx|
Fy = |du/dy| + |dv/dy|

You might see how this could produce lines similar to:

\/

9700-type 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...
Chalnoth is offline   Reply With Quote

Old 10-15-02, 09:36 AM   #33
Chalnoth
Registered User
 
Join Date: Jul 2002
Posts: 1,293
Default

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.
Chalnoth is offline   Reply With Quote
Old 10-15-02, 12:48 PM   #34
jbirney
Registered User
 
jbirney's Avatar
 
Join Date: Jul 2002
Posts: 1,430
Default

Quote:
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.
I will see if I can find the post from the ATI employee that stated that they thought their AF is fine and just wanted to improve their angle perfromance. I thought I saw it back on B3D from OpenGL guy...Your theory is based off on techincal facts however thats not why ATI chose this method of Aniso (again look at the speed tradeoff this method gives). Also if I remember OpenGL guys this was the same AF that they used in the 8500 just with tweaks (angles and tri-linear).
jbirney is offline   Reply With Quote
Old 10-15-02, 03:57 PM   #35
Chalnoth
Registered User
 
Join Date: Jul 2002
Posts: 1,293
Default

Quote:
Originally posted by jbirney
I will see if I can find the post from the ATI employee that stated that they thought their AF is fine and just wanted to improve their angle perfromance. I thought I saw it back on B3D from OpenGL guy...Your theory is based off on techincal facts however thats not why ATI chose this method of Aniso (again look at the speed tradeoff this method gives). Also if I remember OpenGL guys this was the same AF that they used in the 8500 just with tweaks (angles and tri-linear).
There is no evidence to support that ATI's aniso method is fundamentally of higher performance.

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...).
Chalnoth is offline   Reply With Quote
Old 10-15-02, 09:01 PM   #36
Joe DeFuria
Registered User
 
Join Date: Oct 2002
Posts: 236
Default

Quote:
There is no evidence to support that ATI's aniso method is fundamentally of higher performance.
Erhm...I presume then that there is also no evidence to support that ATI's aniso is "fundamentally" of lower quality.

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:
Quite simply, the GeForce4 does not have the ability to calculate the degree of anisotropic for two textures per clock...
Doesn't the GeForce3 have that ability though?
Joe DeFuria is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


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

All times are GMT -5. The time now is 06:01 AM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright ©1998 - 2014, nV News.