Future of MSAA?

[MrGaribaldi]

( Is temporal a form of MSAA )

ATI's implementation is. It just alternates between two (or was it more) sampling patterns to create a better result than you'd get with just the one pattern.

You could probably do the same with SSAA though.

 

[KimB]

Why? It might be a matter of taste. I don't like bluriness, and at 1600x1200 I don't really see any benefits. At whatever multiple of that, there'll be no difference IMHO.

Anti-aliasing cannot be equated to blurriness. And yes, there will be a difference. One of the things that has cropped up in this thread, for example, is texture aliasing.

For years we've had simple texture filtering methods to get rid of (for the most part) texture aliasing. This has reduced a great deal of the need for FSAA. But, we are now moving into a time when we're no longer using basic textures for all surfaces, and thus the old techniques of texture filtering are breaking down. There are very significant artifacts involved with texture aliasing that cannot simply be done away with by increasing the resolution.

Anyway, aliasing will always depend upon the resolution and the game, but yes, even at 4096x3072, there will still be visible aliasing in specific in-game scenarios. The most obvious will be high-contrast geometry, such as is often seen in City of Heroes.

 

[Gunhead]

ATI's implementation is.

You misspelled "misnamed implementation"

Okay, I'll try to be constructive now... Supposing that someday we get to micropolygons (several triangles per pixel, not the other way around), you know, the Toy Story quality Nvidia has promised for our dekstop pleasure Real Soon Now, how does that hang with AA?

I mean, when you have to sample multiple fragments per pixel anyway, does it remove the need for doing AA on top of that? Or does it lead to hideous pixel soup if you don't do even better AA than what we have today? -- Any specific implications for MS vs. SS in particular?

And I want (real) Temporal AA today... I have a slow LCD that would be just fine for gamming if I could accumulate a 100 fps output into a nice rock-steady 25 fps display... getting the illusion of "liquid smooth" with that accumulation hack. (Or would I?)

 

[KimB]

I mean, when you have to sample multiple fragments per pixel anyway, does it remove the need for doing AA on top of that? Or does it lead to hideous pixel soup if you don't do even better AA than what we have today? -- Any specific implications for MS vs. SS in particular?

Well, it seems to me that micropolygon rendering is sort of a method in and of itself to do anti-aliasing. And if you're going to be doing micropolygon rendering, multisampling won't really make a whole lot of sense.

Regardless, it'll be a long time before micropolygons make it to PC rendering, if ever (we may decide other algorithms are better-suited for realtime graphics, and choose to spend processing power elsewhere).

 

[OpenGL guy]

If you arent using any tricky texturing it is a shame to use supersampling for edges.

Huh? Multisampling is very similar to supersampling in terms of performance constraints at edges.

For MSAA, it depends on how many different triangles intersect that edge pixel. For SSAA it's always the same fixed cost. The worst case scenario for MSAA would be SSAA performance, but it's generally much higher.

 

[KimB]

That is assuming you're using more than 2x MSAA. Regardless, I thought it odd that MfA pointed out the one place to differentiate between MSAA and SSAA as being the place where they are closest in performance.

 

[Humus]

MSAA has always struck me as a particulary hackish solution

For me SSAA has always struck me as a hackisk solution. Simple brute-force approach. MSAA is much more elegant and does not interfer with shading in any way like SSAA does. I see it that it's SSAA that has limitations and weaknesses rather than MSAA.

 

[tEd]

MSAA has always struck me as a particulary hackish solution

For me SSAA has always struck me as a hackisk solution. Simple brute-force approach. MSAA is much more elegant and does not interfer with shading in any way like SSAA does. I see it that it's SSAA that has limitations and weaknesses rather than MSAA.

For me as a user i woud like to have the performance of MSAA and a efficient way to AA alpha test textures. It's unforunately still a problem in todays games

 

[KimB]

For me as a user i woud like to have the performance of MSAA and a efficient way to AA alpha test textures. It's unforunately still a problem in todays games

Well, there is an efficient way. Unfortunately it requires depth sorting.

But it shouldn't be that much of a concern: within 2-3 years, when we'll actually have the pixel shader performance to pursue alpha testing AA, we may find that it'll make more sense just to use geometry.

 

[Arun]

For me as a user i woud like to have the performance of MSAA and a efficient way to AA alpha test textures. It's unforunately still a problem in todays games

Savage's solution to this is quite brute-force, but it looks surprisingly good. All tree models are separated in the foliage part and the rest. And all alpha textures (thus, the foliage part) are rendered once with alpha testing and a threshold of around 0.65, and then rendered again with alpha BLENDING. The result is a very nice lack of aliasing, although how good it looks depends entirely on how well the modeller did his job (some trees are still an aliasing fest, while others look flawless even at 0x AA)

Now of course, S2's implementation is shit for everything else using alpha, and I wonder if they even knew about any use of alpha besides foliage... But a slightly improved implementation might be a quite good solution before manufacturers develop a better solution for developers to use.
Something useful here would be the ability to decide NOT to write Z in the pixel shader. Yes, that would kill part of Early Z in such a shader, but that's already disabled with Alpha Test, which would also be required... So I don't see that as much of an issue personally.

Although of course, better systems for depth sorting would be even more desirable. I can't imagine a much more efficient technology than TBDR for that though...


Uttar

 

[stepz]

Something useful here would be the ability to decide NOT to write Z in the pixel shader. Yes, that would kill part of Early Z in such a shader, but that's already disabled with Alpha Test, which would also be required... So I don't see that as much of an issue personally.

I can't see why would alpha test need to kill Early Z. If the fragment can be determined to be occluded before the alpha test/shader then there's no harm in discarding it before shading it. I'm assuming here that fragment early out based on geometry Z is totally independent from the shading portion on the chip. The driver tells the chip if it can be used or not leading to some funky effects when used wrongly.

I'm not too familiar with the API's though so pardon me if I made some silly mistake here.

 

[Arun]

I can't see why would alpha test need to kill Early Z. If the fragment can be determined to be occluded before the alpha test/shader then there's no harm in discarding it before shading it. I'm assuming here that fragment early out based on geometry Z is totally independent from the shading portion on the chip. The driver tells the chip if it can be used or not leading to some funky effects when used wrongly.

I'm not too familiar with the API's though so pardon me if I made some silly mistake here.

We've already had that discussion a fair bit of times already... The best reference, at least for ATI hardware, is: http://www.beyond3d.com/forum/viewtopic.php?t=13859

Uttar

 

[stepz]

Ahh... , implementation details

At a glance it might be enough to do early Z check w/o write and a Z check with write afterwards. HW probably doesn't support that yet though.

Might be wrong though, it's already morning over here and I haven't slept yet.

 

[Simon F]

Ahh... , implementation details

You should bear in mind that what may seem simple to do in software may be tricky to do efficiently in hardware and vice versa.

 

[Panajev2001a]

Ahh... , implementation details

Bear should you in mind that what simple appears to be in software tricky to efficiently in hardware do is.

Ahhh... misterious are the ways of IMG Technologies... now I know Simon F's face:

.

 

[Simon F]

Ahh... , implementation details

Bear should you in mind that what simple appears to be in software tricky to efficiently in hardware do is.

Ahhh... misterious are the ways of IMG Technologies... now I know Simon F's face:
.

I'm far uglier than that.

What I should have said was that things like

IF (NOT short_cut_test_on_pixel(X,Y)) THEN
 DoOperationOn(X,Y)
ELSE
  SkipPixel
ENDIF

may be great for speeding up software, but when you are running dozens or maybe hundreds (shrug) of pixels in parallel /pipelined in hardware, it may not achieve anything. In fact, trying to do it may make the pipeline slower/more expensive for the general case <shrug>

 

[Panajev2001a]

Ahh... , implementation details

Bear should you in mind that what simple appears to be in software tricky to efficiently in hardware do is.

Ahhh... misterious are the ways of IMG Technologies... now I know Simon F's face:
.

I'm far uglier than that.

I was not commenting about your beauty, but about your wisdom .

 

[Bjorn]

I'm far uglier than that.

Yoda ugly ?? Blasphemy !!!

 

[AlNom]

Yoda's a hottie. *drooool*


question: for current methods, does the card apply AA to "hidden objects" too? Any way to get around that besides just not rendering those objects in the first place

 

[no_way]

Thats what i'd like to see in hardware
http://www.cs.uaf.edu/~genetti/Research/Papers/CGF98/ASOS.html
Unfortunately, its raytracing by its very nature.