Dumb question: MSAA vs SSAA, what is the big differences?

[Demirug]

AFAIK, SSAA (if truly implemented in hardware and not just a driver hack) will always work. You render the image 4 times for 4xSSAA _completely_ and sample than, right? So in which case should it not be working?

Four times, or just once, but twice the resolution on both axis?

The question remains: in which case is SSAA incompatible to anything? The blending happens _after_ the whole image is rendered (be it 4 frames or double the res). Right?

As long as it is well done it will never be incompatible. But there are some render technics that will let you pay for SSAA but you will not see it. But there is the same problem with MSAA. I am sure you remeber als the games that can not use AA and postfilter effects at the same time.

 

[Simon F]

Besides, given the same number of samples, MSAA generally does a better work to smooth edges next to SSAA (see here for example).

IMHO that statement is false.

 

[Nappe1]

If my memory serves me well Matrox's FAA wouldn't work with stenciling also, albeit I'd figure it would be possible with FAA with a few workarounds.

problem with Stencil buffer was fixed in newer revision that also introduced BGA package, a bit higher clocks and AGP 8x support. (it quietly replaced the old version quite long ago... Not that anyone noticed that. (Murcers aren't counted here. ))

 

[Murakami]

Besides, given the same number of samples, MSAA generally does a better work to smooth edges next to SSAA (see here for example).

IMHO that statement is false.

I'm still waiting that someone explain me why and how.

 

[Murakami]

If my memory serves me well Matrox's FAA wouldn't work with stenciling also, albeit I'd figure it would be possible with FAA with a few workarounds.

problem with Stencil buffer was fixed in newer revision that also introduced BGA package, a bit higher clocks and AGP 8x support. (it quietly replaced the old version quite long ago... Not that anyone noticed that. (Murcers aren't counted here. ))

Have you got a link?

 

[bloodbob]

I'm still waiting that someone explain me why and how.

Explain to us how and why MSAA with exactly the same sampling pattern would be better then SSAA. There is no logical explantion.

Actually if you don't adjust the Lod for texture in SSAA the SSAA the edges would be smoother because the textures would be overly blurred so the contrast would be less.

 

[_xxx_]

Besides, given the same number of samples, MSAA generally does a better work to smooth edges next to SSAA (see here for example).

IMHO that statement is false.

I'm still waiting that someone explain me why and how.

MSAA does edges and poly intersections only, SSAA does the whole scene. When using the same sample pattern, both do exactly the same with the edges.

Those screenshots linked there are bull, because the shots don't have the same quality level and no aniso is used. Besides, the MSAA used there is not what it is today. Look at this:

Sample pattern of the GF3 to the left, the right one is GF4/FX. So the difference in quality in those Q3 shots linked above is rather nonsencical, that was just a hack and not "real" MSAA.

 

[Murakami]

Understood: i just wonder how the sample pattern can change between MSAA and SSAA on the same card, given that GeForce 3 sample grid is not adjustable in software ala R300... :?

 

[Simon F]

Understood: i just wonder how the sample pattern can change between MSAA and SSAA on the same card, given that GeForce 3 sample grid is not adjustable in software ala R300... :?

The "change" in the sampling shown in those diagrams probably could be achieved simply by tweaking the viewport transform.

 

[DeanoC]

The question remains: in which case is SSAA incompatible to anything? The blending happens _after_ the whole image is rendered (be it 4 frames or double the res). Right?

If the app locks the buffer, fiddles and then continues rendering you have issues with SSAA (the app will want a downsampled buffer for the lock, which might not be the best time for it)

 

[Demirug]

The question remains: in which case is SSAA incompatible to anything? The blending happens _after_ the whole image is rendered (be it 4 frames or double the res). Right?

If the app locks the buffer, fiddles and then continues rendering you have issues with SSAA (the app will want a downsampled buffer for the lock, which might not be the best time for it)

With DX this can only happen if you force the AA from the driver. But even than the driver can downsample it and copy it back after the unlock. I know this works because I have done this for my SSAA plugin for DirectX Tweaker. Anyway you will see the same problem with MSAA, too.

Lock the backbuffer is allways a bad thing. Lock a AA backbuffer is only more worse.

 

[KimB]

Supersampling and multisampling, when forced through the driver, also won't work properly if any sort of render to texture is used for bloom effects or deferred shading.

But that's somewhat immaterial. If games are programmed properly, there's really no reason why multisampling and supersampling should have any difference as far as compatibility is concerned. The only difference that may crop up would come from textures that are copied straight to the screen (as is done with text entirely too often), where you might get unexpected results if said texture doesn't fill entire pixels where it should.

 

[Basic]

Murakami:
GeForce3 had a fixed sample pattern for MSAA, but at least it had HW to do two samples at 45º angle. This part of the HW was only capable of MSAA.

The SSAA part was done by rendering to a higher resolution buffer, and then downsampling it (at readout). Thus giving an ordered grid.

A possible reason that the jittered grid part couldn't do SSAA, is that it needs a bit more effort to calculate texture samples and LOD level with jittered grid.

 

[Murakami]

Thanks to Simon F and Basic

 

[Reverend]

A little late to the discussion... wrt the topic's question, the only difference that matters is that of performance.

That's the single biggest reason the IHVs went wholeheartedly into MS and ditched SS.

Of course, there'll be the technical differences, as discussed here, but so what, right?

 

[Ailuros]

A little late to the discussion... wrt the topic's question, the only difference that matters is that of performance.

That's the single biggest reason the IHVs went wholeheartedly into MS and ditched SS.

Of course, there'll be the technical differences, as discussed here, but so what, right?

Hmmmm....which reminded me of something else...

The issue of anisotropic filtering and alpha blending points out a more general problem of anisotropic filtering and pixel shaders in general.

To properly anti-alias a pixel shader function (be it alpha blending or any other pixel shading function) it is necessary to perform the pixel shading function at each sample point in the pixel and then average (usually weighted) the result. Filtering the input samples separately and performing the pixel shading once for the pixel on the resulting filtered inputs gives the wrong results.

While performing pixel shading at each sample point in a pixel is expensive, it is still much cheaper than super sampling since the z values still do not need to be processed.

Hopefully, at least some of the 3d hardware vendors will properly implement anisotropic filtering with pixel shaders.

http://www.beyond3d.com/forum/viewt...rder=asc&highlight=hsr++tile*&start=0

Any thoughts?

 

[Ailuros]

If my memory serves me well Matrox's FAA wouldn't work with stenciling also, albeit I'd figure it would be possible with FAA with a few workarounds.

problem with Stencil buffer was fixed in newer revision that also introduced BGA package, a bit higher clocks and AGP 8x support. (it quietly replaced the old version quite long ago... Not that anyone noticed that. (Murcers aren't counted here. ))

When the overall shortcomings of an architecture outweigh the positive aspects it's natural that only few will notice. Apart from that while Matrox's FAA could apply 16x sample AA on poly edges it still just had a 4*4 EER.

EER (edge equivalent resolution) was a term I first saw at Matrox whitepapers and it is a valid point when comparing fragment or multisampling AA. Programmable sparsed sampled patterns like ATI's have an advantage and it shows even at just 6x MSAA with a 6*6 EER.

 

[KimB]

"Equivalent edge resolution" is not a fair way of comparing FSAA (at least, not in the way you're talking). I seriously doubt ATI's 6x is actually better-looking than Matrox' 16x, even if it is an ordered grid (when Matrox' FAA worked, that is).

 

[no-X]

"Equivalent edge resolution" is not a fair way of comparing FSAA (at least, not in the way you're talking). I seriously doubt ATI's 6x is actually better-looking than Matrox' 16x, even if it is an ordered grid (when Matrox' FAA worked, that is).

Really?

Parhelia (rev.2) [16xFAA] (1.71.60_107.01whql)


Radeon 9600 XT [6x] (ATi 4.6)


just compare horizontal/vertical lines ;-)

 

[KimB]

ATI also has gamma-adjusted filtering, though.