GFFX Anti-Aliasing with FSAA Tester
- Thread starter Brent
- Start date
Try this java applet to compare the images:
http://www.nvnews.net/temp/aa_comparison.shtml
This is really sad - spending my Saturday night doing image quality comparisons
http://www.nvnews.net/temp/aa_comparison.shtml
This is really sad - spending my Saturday night doing image quality comparisons
gokickrocks
Regular
Volenti said:
thats what i see as well
it is just me or does the font in the 4xS picture look distorted compared to other shots? (smaller/thinner and blurrier)
also the 8x mode looks blurrier than 6xS and the black-white border is shifted a pixel or two to the right?
maybe it's just my eyes or is it supposed to be that way?
also the 8x mode looks blurrier than 6xS and the black-white border is shifted a pixel or two to the right?
maybe it's just my eyes or is it supposed to be that way?
gokickrocks
Regular
Rambler said:
same here
Update:
Using Mike C's java code I have put up a comparison page that now also has the 9700 Pro pics to compare to:
http://home.attbi.com/~brentjustice2/index.htm
Using Mike C's java code I have put up a comparison page that now also has the 9700 Pro pics to compare to:
http://home.attbi.com/~brentjustice2/index.htm
6xS and 8xS suck and I think I know why.
6xS is using 4x MSAA with 1.5x Horizontal SSAA. Sample Pattern then is
* * *
* * *
8xS is using 4x MSAA with 2x Horiztonal SSAA. Sample Pattern is
* * * *
* * * *
These both do shocking AA on near horizontal lines, but ok AA on vertical lines. Notices that the vertical lines on the 6xS and 8xS shots aren't too bad.
[Added]
Just comparing the 9700 and GFFX 2x shots, Gamma corrected FSAA makes a bigger difference than I ever though it would. I am actually quite surprised.
6xS is using 4x MSAA with 1.5x Horizontal SSAA. Sample Pattern then is
* * *
* * *
8xS is using 4x MSAA with 2x Horiztonal SSAA. Sample Pattern is
* * * *
* * * *
These both do shocking AA on near horizontal lines, but ok AA on vertical lines. Notices that the vertical lines on the 6xS and 8xS shots aren't too bad.
[Added]
Just comparing the 9700 and GFFX 2x shots, Gamma corrected FSAA makes a bigger difference than I ever though it would. I am actually quite surprised.
ClyssaN said:
I thought so too at first glance, but both 6xS and 8xS have better quality in at least a couple of places. The 5th, 6th, and 7th bars going counter-clockwise from the top (the more reddish tinted of the purple ones) are all done better with the 6XS and 8XS. The difference isn't quite as noticable, however, compared to how much better the 9700's 4X is on the orange bars near the 9 o'clock position. As you continue counterclockwise, though, the 6xS and 8xS again do a better job starting around the 8 o'clock position. Another area the FX modes seem to do better on is the red lines from the lower-right quadrant as they approach the center. The lines become fairly broken up in the 9700's 4X shot, but remain relatively clear in the 6xS and 8xS shots.
6X on the 9700 is still the best of them all of course, with the only place it loses to any FX modes is again in that area where the red bars converge towards the middle. Everywhere else it's as good or better.
Crusher said:
I agree with what you said, but given the choice I'd definitely select 4X on the R9700 over any of the modes on the FX. It just looks much better overall. 8xS is still better than 6X in the same places as 4X, but again overall 6X looks much better.
Why is it the R9700 isn't as good near that one angle, is it just because that's around the angle that the grid is rotated? If so, maybe the future of FSAA will be Multiple differently Rotated grids.
Doomtrooper
Veteran
Great comparisons shots Brent, also nice FSAA application Thomas, thats a great app for testing FSAA modes.
By the time Dave gets a Geforce FX we will have done the entire review on the forums
By the time Dave gets a Geforce FX we will have done the entire review on the forums
Hmm, 6XS and 8XS look like 6X and 8X (i.e., the MS is OG...atleast that is my theory). What would cause that? I wonder if it is a driver bug?
Anyways, I have a question: Why can't the GF FX do 4xS using the post filter? I.e., it was said the 4xS shots represented game play without computer side post processing.
I have some theories on how it could work using postfiltering...could someone tell me if my reasoning is invalid?
....
Here is my guess at an explanation of GF 4 modes (please correct if in error...which seems likely because I just made it up ) and two theories on GF FX operation.
If there is a conceptual error, please point it out and I'll go back and fix it throughout if it wrecks my theory. Please ignore the RAM squander
in theory 2 for the purposes of theorizing a 256 MB card sometime in the future.
I assume, for the purposes of analyzing performance drawbacks, the postfilter is capable of all of the operations I specify below:
(I hope I'm not spouting badly conceived math everywhere...
)
Per Hyp-X correction, D = blend render rate, D' = blend read rate, R = refresh rate.
It struck me that changing bus utilization of one due to constraints of the bus in regards to the other might be a factor...for example, output blend bandwidth usage could be 1/N blend read bandwidth usage...and the difference between the two might factor in analysis.
Also, I should list vsync and triple buffering as possible factors in latency effects.
BLENDED NxS:
bandwidth = (N/2)x SS write * 2x MS write (back buffer) + D' * (N/2)x SS read * 2x MS read (back buffer) + D * 1x write (front buffer) + "latency effect" (from tying up write bandwidth) + R * 1x read (front buffer)
RAM = 1x front buffer RAM used
RAMDAC NxS (theory 1, if efficient access isn't a problem):
bandwidth = (N/2)x SS write * 2x MS write (back buffer) + D' * (N/2)x SS read * 2x MS read (back buffer) + D * 2x MS write (front buffer) + "latency effect" (from tying up write bandwidth) + R * 2x MS read (front buffer)
RAM = 2x front buffer RAM used
RAMDAC NxS (theory 2, if efficient access for blending is an issue above):
bandwidth = (N/2)x SS write * 2x MS write (back buffer) + R * (N/2)x SS read * 2x MS read (front buffer)
RAM = (N)x front buffer RAM used
Also, CCdiff = the difference between theoretical maximum MS color compression and actual compression, ignoring overhead (for a screen with no edges, a theoretical "0"). The "latency effect" from this difference is ignored.
Compared to GF 4 implementation (positive is a possible penalty, in red if always so, and a negative is a benefit):
For NxS (theory 1):
+ D * (CCdiff)x write + R * (CCdiff)x read + 1x front buffer RAM used (might cause further performance hit on 128 MB card at higher resolution)
For NxS (theory 2):
+ (R - D') * (N/2)x SS read * 2x MS read - D * 1x write - "latency effect" - D' * 1x read + (N-1)x front buffer RAM used (might this be conceivable for 4xS at some resolutions, even with 128MB? Looks pretty ugly for anything above that even on a 256 MB card I think...)
Assuming SS has no color compression benefit, and the postfilter is capable of this blend:
(N/2)x SS read/write * 2x MS read/write = (N/2) * (CCdiff + 1x read/write)
(R - D') * (N/2)x SS read * 2x MS read - D * 1x write - R * 1x read =
R * (N/2)x SS read * 2x MS read - D' * N/2 SS read * 2 MS read - D * 1x write - R * 1x read =
R * (N/2) * (CCdiff + 1x read) - D' * (N/2) * (CCdiff + 1x read) - D * 1x write - R * 1x read =
(R - D') * (N/2) * CCdiff + R(N/2 - 1) * 1x read - D' * (N/2) * 1x read - D * 1x write
+ (R - D') * (N/2) * CCdiff + R * (N/2 - 1) * 1x read - D' * (N/2) 1x read - D * 1x write - "latency effect" + (N-1)x front buffer RAM used
With CCdiff presumed to be near 0, bandwidth savings is primarily determined by the relationship of R to D and D'.
For NxS (theory 2) to offer bandwidth savings using post filter, R * (N/2 -1) would have to be less than D' * (N/2) + D.
Assuming D and D' equivalent, render rate (D) would have to be > refresh rate (R) * (N - 2) / (N + 2), or : D > R/3 for 4xS, D > R/2 for 6xS, D > R * 0.6 for 8xS. Tthis does not look to have any redeeming values.
And/or my math could be in error.
Hmm...this time I'm pretty positive I've messed up the math but I'll check it at a later time.
---
If my reasoning isn't fatally flawed, EDIT1: is the above the reason for no postfilter usage for anything besides 2x and Quincunx?
EDIT2: I've gone and corrected based on Hyp-X's correction (or atleast my understanding of it) from another thread in brown, and added italic edited comments for clarification. Note that I haven't performed a sanity check on the math yet, and it might show.
PS: Yes, I know the colors are overboard, I'm seeking distraction.
Anyways, I have a question: Why can't the GF FX do 4xS using the post filter? I.e., it was said the 4xS shots represented game play without computer side post processing.
I have some theories on how it could work using postfiltering...could someone tell me if my reasoning is invalid?
....
Here is my guess at an explanation of GF 4 modes (please correct if in error...which seems likely because I just made it up
) and two theories on GF FX operation.If there is a conceptual error, please point it out and I'll go back and fix it throughout if it wrecks my theory. Please ignore the RAM squander
in theory 2 for the purposes of theorizing a 256 MB card sometime in the future.I assume, for the purposes of analyzing performance drawbacks, the postfilter is capable of all of the operations I specify below:
(I hope I'm not spouting badly conceived math everywhere...
)Per Hyp-X correction, D = blend render rate, D' = blend read rate, R = refresh rate.
It struck me that changing bus utilization of one due to constraints of the bus in regards to the other might be a factor...for example, output blend bandwidth usage could be 1/N blend read bandwidth usage...and the difference between the two might factor in analysis.
Also, I should list vsync and triple buffering as possible factors in latency effects.
BLENDED NxS:
bandwidth = (N/2)x SS write * 2x MS write (back buffer) + D' * (N/2)x SS read * 2x MS read (back buffer) + D * 1x write (front buffer) + "latency effect" (from tying up write bandwidth) + R * 1x read (front buffer)
RAM = 1x front buffer RAM used
RAMDAC NxS (theory 1, if efficient access isn't a problem):
bandwidth = (N/2)x SS write * 2x MS write (back buffer) + D' * (N/2)x SS read * 2x MS read (back buffer) + D * 2x MS write (front buffer) + "latency effect" (from tying up write bandwidth) + R * 2x MS read (front buffer)
RAM = 2x front buffer RAM used
RAMDAC NxS (theory 2, if efficient access for blending is an issue above):
bandwidth = (N/2)x SS write * 2x MS write (back buffer) + R * (N/2)x SS read * 2x MS read (front buffer)
RAM = (N)x front buffer RAM used
Also, CCdiff = the difference between theoretical maximum MS color compression and actual compression, ignoring overhead (for a screen with no edges, a theoretical "0"). The "latency effect" from this difference is ignored.
Compared to GF 4 implementation (positive is a possible penalty, in red if always so, and a negative is a benefit):
For NxS (theory 1):
+ D * (CCdiff)x write + R * (CCdiff)x read + 1x front buffer RAM used (might cause further performance hit on 128 MB card at higher resolution)
For NxS (theory 2):
+ (R - D') * (N/2)x SS read * 2x MS read - D * 1x write - "latency effect" - D' * 1x read + (N-1)x front buffer RAM used (might this be conceivable for 4xS at some resolutions, even with 128MB? Looks pretty ugly for anything above that even on a 256 MB card I think...)
Assuming SS has no color compression benefit, and the postfilter is capable of this blend:
(N/2)x SS read/write * 2x MS read/write = (N/2) * (CCdiff + 1x read/write)
(R - D') * (N/2)x SS read * 2x MS read - D * 1x write - R * 1x read =
R * (N/2)x SS read * 2x MS read - D' * N/2 SS read * 2 MS read - D * 1x write - R * 1x read =
R * (N/2) * (CCdiff + 1x read) - D' * (N/2) * (CCdiff + 1x read) - D * 1x write - R * 1x read =
(R - D') * (N/2) * CCdiff + R(N/2 - 1) * 1x read - D' * (N/2) * 1x read - D * 1x write
+ (R - D') * (N/2) * CCdiff + R * (N/2 - 1) * 1x read - D' * (N/2) 1x read - D * 1x write - "latency effect" + (N-1)x front buffer RAM used
With CCdiff presumed to be near 0, bandwidth savings is primarily determined by the relationship of R to D and D'.
For NxS (theory 2) to offer bandwidth savings using post filter, R * (N/2 -1) would have to be less than D' * (N/2) + D.
Assuming D and D' equivalent, render rate (D) would have to be > refresh rate (R) * (N - 2) / (N + 2), or : D > R/3 for 4xS, D > R/2 for 6xS, D > R * 0.6 for 8xS. Tthis does not look to have any redeeming values.
And/or my math could be in error.
Hmm...this time I'm pretty positive I've messed up the math but I'll check it at a later time.
---
If my reasoning isn't fatally flawed, EDIT1: is the above the reason for no postfilter usage for anything besides 2x and Quincunx?
EDIT2: I've gone and corrected based on Hyp-X's correction (or atleast my understanding of it) from another thread in brown, and added italic edited comments for clarification. Note that I haven't performed a sanity check on the math yet, and it might show.
PS: Yes, I know the colors are overboard, I'm seeking distraction.
Dave H said:
The wording should be "is this why the postfilter isn't used?". I wrote the theories out and found reasons why each is not desirable. What is missing in my text (among the slightly awkward wordings with the shifted focus) is a reason that theory 1 might be a valid method to propose at all (which would be that the post filter couldn't handle theory 2->therefore since theory 1, if technically possible, is not desirable, the postfilter isn't used).
EDIT: rewording for clarity, it is past my clarity threshold for the night...err..morning.
Of course all of our comparisons have been based on edge quality only and not the other benefits SS AA can bring when looking at 4xS/6xS/8xS.
Brent have you played any games with excessive LOD, alpha's etc where SSAA can help aliaising better than MSAA, e.g. F1 2001 or Counterstrike. Operation Flashpoint, even Black & White?
Brent have you played any games with excessive LOD, alpha's etc where SSAA can help aliaising better than MSAA, e.g. F1 2001 or Counterstrike. Operation Flashpoint, even Black & White?
