B3D's AMD R6xx image quality investigation

Wow! That's cool.
And how many months to the performance part (or suitable Cat's)?

 

Early 2009 going by past performances

The target is 3rd week Sept, fingers crossed.

 

Wow. I think I disagree with about every other sentence in that article.

How embarrassing!

ERK

 

Actual IQ comparisons i.e screenshots something or rather woud've been great. (This woud've been the icying on the cake really)

Either then that it was a great article! good work guys!

 

Well, the question is embarrassing for *who*?

Would you like to toss the first couple sentences out you'd like to take issue with? Shouldn't take too long to determine who should be turning red, or if the twain shall just never meet.

 

As for who, probably me!

OK, where should I start...?

Hmm, all right. First of all, what does being a pre- or post-filter have to do with pixel area coverage? Isn't area coverage the shape of the filter?

Secondly, I thought we had previously discussed this, and several references were pointed to as to why a box filter is not optimal, and that sampling outside the pixel with appropriate weights was very desirable. Yet the article opines more-or-less that all sampling outside the pixel area is bad because it just adds blurring.

My understanding has always been that only frequency content below half the sampling frequency can be reasonably accurately reconstructed on screen (at most) and that all spatial frequency content faster than this must either be aliased or blurred (filtered). The balance between how much blur and how much aliasing is a subjective one, but surely improvements can be made upon box filtering/area coverage filtering by sampling outside the "pixel area" as demonstrated by the links in the previous discussion. The case that's always brought up is that of the square/sinc relationship. IMO, many cases which sample outside the "pixel area" are better than "pixel area coverage", including bicubic, gaussian, chebychev, etc. filters.

Thirdly, why do the authors refer to MSAA as a post-filtering technique? Imagine a bunch of geometry in a scene; rasterize that to a million times finer scale than the final desired resolution, filter that, then sample to final resolution. I would call this process pre-filtering because the filtering takes place before the final sampling/accumulating. Because MSAA samples from the geometry at much higher effective resolutions than the final output resolution, and filter weightings are applied to these samples, it seems more appropriate to refer to it also as pre-filtering. To me, post filtering is: render to final resolution, then do another pass blending neighboring pixels together to smooth stuff out.

Anyway, I could go on, but frankly I'm probably full of BS so I'll stop here until others chime in.

ERK
PS. BTW, my background is in DSP, not graphics, so there may be a semantics barrier here to some extent.

Also, I'm off home for the night. I'll check back here in about 17 hours.

 

The debate on the higher-order sample resolving (eg., taking samples outside the pixel area) can be stretched miles long, depending on the subjectivity of visual perception.
From my personal experience, on a razor sharp, high contrast brand new TFT monitor, tent filter in R600 adds quite nice subtle blurring to the whole image. Well maybe the wide-tent can be seem as a tad too much for some people. Anyway, if you are still on a 6-year old CRT tube, things can get a bit uglyish.

 

In my experience, this is dependant on the title you're toying with. In some it's horrible, for example NWN2 or Marvel Ultimate Alliance. In others, due to the game itself aiming to be a tad bit blurry/dreamy, it's great:think Oblivion, Overlord, even Medieval II due to its rather bloomy nature.

I agree with B3D though that ATi should work on tweaking the sample weights in the future, as other, more costly post-filters are not that likely to be implemented, IMHO, considering that AA performance is less than stellar to begin with on the R600.

 

Sorry, but this article is pretty lousy. Contains nothing new or interesting. I'm surprised you could get so many pages out of so little content. Sorry about being so negative, but thats my honest opinion.

 

Good read, thanks. I finally get their new AA modes now, and I'll be sticking with "box" I think.

 

It's a question of taste really Digi...it's just like with using some program to calibrate your monitor:if it looks poor to you, what does it matter if the program states you've achieved optimal parameters?

I don't like the tent modes, save for a few cases, but there are some that are having hard-ons WRT them(try TechReport, who herald it as the best thing in the IQ-department ever ). There is science behind tent-filters, they make sense on paper in a way, but in the end, it only matters how it looks...and that evaluation is hyper-subjective.

 

Aye, have to agree that the Tent filters are extremely subjective.

While it's not something I'll enable 100% of the time for all titles, there ARE quite a few instances where the increase in IQ when in motion is just (IMO) a huge leap over box filters.

Then there's other cases, like a 3D turn based RPG where you stare at a relatively static screen for long periods of time where the box filter is certainly the way to go.

And this actually brings me to a point. I LIKE it because it DOES increase IQ in certain titles even though it reduces IQ in other titles. For those other titles, I always have the old Box filter to fall back on. So it's a win/win situation in my situation.

It's a herald of things to come (hopefully) with DX10(.1) where developers will have a better supported way to have their own AA resolve in their games and it can be tailored to what and how they want their game to look.

Game Q might see a tent filter as the way to go. Game P might see the traditional box filter as the way to go. Game S might have their own special AA resolve that works great in their game.

Now, I just have to hope that developers take this power that's been given to them and use it to best effect. Although, if I was to go by the amount of past titles that even offered a drop down box for basic x2/x4 AA choices, I'd probably be a bit less hopeful.

It's not the greatest thing since sliced bread, but it is (IMO) a rather large step in the right direction of improving IQ overall. And is probably one of the few things about the R600 that I'm not disappointed in.

Regards,
SB

PS - Edge Detect is absolutely amazing, IMO when combined with a 4x box filter. I haven't had the courage to try enabling it with an 8x box filter on a single card, however.

 

Agreed. IMHO box filters are poor when motion is involved.

 

No link to the forum thread from the article, or did I miss something?

 

Sure there is. . . . now.

 

I agree with ERK in every point. I thought the article was disappointing.

- For example, page 4, "pre-filtering", talks about the internal area of a pixel without even discussing what the internal area is. The article also talks about the "pre-filter ideal" without explaining why this is supposed to be ideal.

- Page 5, Tent Filter: "The filter kernel weights are therefore pre-computable if you know in advance exactly where your samples will be taken from, although at the expense of absolute accuracy."
Please explain the last part.

- "The name comes from the shape of the filter if you plot weight against distance, and its linear interpolation also maps nicely to hardware accelerated lerp logic already available in the hardware, outside of the ROP."
Surely anyone in their right mind would use a sample weights LUT and a single MAD per sample. That also means that the shape of the filter does not matter for performance, only the number of taps. I'm not even sure where lerp logic would come in.

- "So the tent filter doesn't approximate coverage any better than a box filter for post-filter AA, an important property to consider when deciding which down-filter to choose."
It's the shape of the downfilter that determines what "pixel coverage" actually means.

- a side question: Page 6, Edge detect: "If an edge is detected, the standard chosen filter is run."
So you can choose between narrow and wide tent for edge detect (surely combining it with a width-1 box filter doesn't make much sense)?

- Page 7: "Things become more complicated if your pixel colour can lie in a different colour space and have more than 8 integer bits per channel, and those have to be taken in to account when making a user-selectable control panel filter for MSAA"
If this refers to HDR and tone mapping then that should be made clear.


Instead of judging for the reader, the article should have presented comparison screenshots so the readers can decide for themselves in the highly subjective matter of image quality. It should have shown benchmarks on how fast R600 and G80 can actually access samples from a multisample texture instead of making the statement that the former is more efficient without proof. It should have mentioned the bandwidth implications of any filter that shares samples between pixels. And most importantly, it should have talked about the signal chain from geometry to multisample buffer to resolved buffer to screen to eye to brain. It's hard to explain antialiasing without explaining aliasing first.

 

Me too, and I wrote most of it. There was a need to publish though, and I couldn't really avoid it if I wanted to avoid some knock-on effects. It'll get revised over time, when there's time. I agree with some of the concerns, but not all.

Wide and narrow tent are available with edge detect, yep

 

How would this work?For current drivers it'e either tent-modes or Edge-Detect, AFAICT. Also, I remember that some launch-presentation explained that edge detect worked somethin like:run a full-screen edge-detection algorithm, if edge found then apply higher AA(seemingly 3x the base level, given current nomenclature) along edge, else apply base level of AA.

The edge-detection algorithm wasn't presented as being conceptually different from what's used by Photoshop, for example, and thus somewhat costly in terms of ALU usage. It would be nice if ATi actually described edge-detect as clearly as they've described their tent-modes-meaning text+graphical illustration of what they're actually doing.

 

some samples for comparision (square brackets contains my subjective opinions)

level: 2

2x (2x + box filter)
4x (2x + narrow tent) [crap, comparable to quincunx, but subjectively blurrier due to gamma correction]
6x (2x + wide tent) [crap, blurry and aliased]


level: 4

4x (4x + box filter)
6x (4x + narrow tent) [mediocre]
8x (4x + wide tent) [mediocre]
12x (4x + edge-detect) [very good]


level: 8

8x (8x + box filter)
12x (8x + narrow tent) [very good]
16x (8x + wide tent) [very good, especially for moving objects/scenes]
24x (8x + edge-detect) [excellent]

//edited:

here are some other screenshots from my archive - for better comparision

3Dfx VSA100 4x (RGSS 4x)
3Dfx VSA100 4x (SS 4x, optimized pattern)
ATi R1xx 4x quality (oversampling)
ATi R2xx 4x quality (oversampling, later driver - c4.10)
ATi R3xx 6x (MSAA 6x, gamma correction, sparse... same as R4xx and R5xx)
Matrox Parhelia FAA 16x (second revision, "AGP 8x" core)
NV40 quincunx (filtered RGMS 2x)
NV40 8x (OGSS 2x + RGMS 4x)
FX 8x (OGSS 4x + RGMS 2x, WHQL driver, 56.72)
FX 8xS (OGSS 2x + OGMS 2x?, crappy grid, non-WHQL driver, 61.40)