SSAA vs. MSAA debate

[KimB]

I don't expect to see a difference on the Voodoo4, either. Just the Voodoo5.

 

[poly-gone]

Rofl. Do you even know what modern MSAA implies? Your implementation has ZERO similarity to it. Obviously with such an implementation, you'd consider so-called SSAA to be better than so-called MSAA... duh. May I congratulate you for not even pointing this out earlier, and daring to start a debate based on such BS?

Uttar

Oh ho ho! Cool it dude. You're not the only one with graphics knowledge around here. It doesn't have ZERO similarity to it, BECAUSE IT IS MULTISAMPLING without all the extra hardware-based optimizations. And if one could accurately replicate the MSAA technique that the hardware does, obviously developers would have employed custom MSAA algorithms by now, making hardware MSAA obsolete! And what do you propose to do when you need to implement MSAA on hardware that doesn't support it natively? Think before you blurt out BS!

poly-gone, surely you have to realize how worthless your performance measurements are. MSAA in software compared to MSAA in hardware? They're not the same at all. Why you expect usable performance metrics from your program is beyond me.

MSAA has to be done in software when it is NOT supported by hardware. Otherwise you will have to resort to super-sampling. So, I was estimating the performance and quality differences between the two methods done "in software". Why aren't you folks getting this point?

Then that is not MSAA and your claim that 2xSSAA is better than 4xMSAA is useless.

Not MSAA in hardware, YES. But it's the closest thing to implementing MSAA in software. And you'd have to resort to a "software" based method when the underlying hardware doesn't support it natively. Are you getting my point now?

I'm pretty sure that game developers that go all the way to implement some form of AA on non-FP16-MSAA-capable GPUs will most likely make use of the MSAA capabilities for 8 bit per channel rendertargets and compose a non-antialiased tonemapped HDR render on top of it. Or take the easy way of doing supersampling.

Exactly, so if you want a viable "software" solution for AA on FP16 targets, supersampling would be the way to go.

 

[Snyder]

MSAA has to be done in software when it is NOT supported by hardware. Otherwise you will have to resort to super-sampling. So, I was estimating the performance and quality differences between the two methods done "in software". Why aren't you folks getting this point?

Because you didn't point it out earlier, I guess...

 

[KimB]

MSAA has to be done in software when it is NOT supported by hardware. Otherwise you will have to resort to super-sampling. So, I was estimating the performance and quality differences between the two methods done "in software". Why aren't you folks getting this point?

That's all well and good, but how could you possibly do it in software?

 

[poly-gone]

That's all well and good, but how could you possibly do it in software?

You mean performing hardware style MSAA in software? It can be approximated, but you'd need to use an edge detection filter to extract the edges of all polygons, in order to antialias them without compromising the shading "power" or wasting computations on intra-polygon regions. And use z-compression via special depth buffers (dunno if this can be done efficiently).

 

[Basic]

When you do your "custom MSAA", what resolution do you render to (compared to the final resolution). What is the custom 16 tap filter kernel? (What sample points?)

 

[poly-gone]

When you do your "custom MSAA", what resolution do you render to (compared to the final resolution). What is the custom 16 tap filter kernel? (What sample points?)

Same resolution, otherwise it would become no different than super-sampling. I sample 4 pixels at a time, in 4 sets, thus giving me a 16 tap kernel and average them.

 

[Basic]

So what you're doing isn't AA at all. It just regular non-AA rendering with a blur filter at the end. Then no, this isn't multisampling by any stretch. And probably won't look any better than without the blur (ie not better than no-AA).

You could make a multipass SW algorithm with edge detection, that do SSAA only on the edges. And with really complex shaders, fairly large polygons, and HW with fast branching in PS, it might be faster than straight SSAA.

But what you described is not it.

 

[poly-gone]

So what you're doing isn't AA at all. It just regular non-AA rendering with a blur filter at the end. Then no, this isn't multisampling by any stretch. And probably won't look any better than without the blur (ie not better than no-AA). But what you described is not it.

Ah, no, it's not an extended bi-linear filter. The sampling is still effectively done at 4 times (instead of 16 due to 4 sets) the frequency of the initial aliased image, so it does satisfy the Nyquist criterion, and hence looks better than ordinary filtering.

 

[poly-gone]

You could make a multipass SW algorithm with edge detection, that do SSAA only on the edges. And with really complex shaders, fairly large polygons, and HW with fast branching in PS, it might be faster than straight SSAA.

I tried that once a while back, and it wasn't exactly "straightforward". The problem is that you need to straight away render the edges to an upsampled buffer, otherwise, if you render the "colored" scene to a bigger buffer, the whole point of efficient multisampling is lost. Most edge detection filters require a base "color" image (though a depth map would perhaps work) to extract the edges from, so initially you'd have to render all the objects in different colors using simple shaders, then run an edge detection pass on them and proceed with the downsampling. For the hardware, it's much simpler since it has full control over the rasterizing phase.

 

[Basic]

What is the 16 tap filter applied to?

[Edit]
Because of the lack of answer, I'll add the reply I would give if I got the answer I expected.:smile:

Answer:
The aformentioned image, of course!

My reply:
But then it's exactly what I said. No AA, with a blur filter. After the initial rasterization, the aliasing is in the image, and no postfiltering will remove it.

[Edit2]
Btw, when you quoted me at last page, you altered what I said. It was probably unintensional, but please be more careful. "But what you described is not it." refers to the second quote, not the first.

 

[poly-gone]

Another implementation of SSAA I'm thinking of implementing is using an accumulation buffer, rendering the scene from jittered camera viewpoints and averaging them.

But I was wondering, could a z-compression technique be employed with this idea? One optimization would be to use a single z-buffer for all 4 "passes", this should cut-down on memory bandwidth, but what if I skipped z-writing for the other 3 passes since the pixel jitter would approximately be very small, so would a single depth sample, a fake-filtered sample suffice?

Or perhaps store a per-triangle information in a buffer, and selectively emit depth writes on a per-pixel basis (if this can be done)? An ideas on this?

 

[Inane_Dork]

MSAA has to be done in software when it is NOT supported by hardware. Otherwise you will have to resort to super-sampling. So, I was estimating the performance and quality differences between the two methods done "in software". Why aren't you folks getting this point?

Software is not hardware, and it should be obvious to you that making statements about hardware performance of MSAA when you tested software performance of MSAA is unfounded. There's no necessary link between the two.

And doing them both in software is doubly missing the point, as neither are necessary reflections of hardware performance.

 

[KimB]

And doing them both in software is doubly missing the point, as neither are necessary reflections of hardware performance.

Well, since supersampling is comparitively harder to optimize, a hardware and software implementation aren't going to differ much in performance.

 

[Basic]

AA with accumulation buffers are the good old fashioned way of doing it. It will work, but if you reuse the z-buffer from the first pass, you'll effectively disable the edge-AA (actually it will even be a bit worse than that). And if you're not careful with z-offsetting, you'll disable AA inside many triangles too.

 

[KimB]

Hrm, I wonder if you could make use of MRT's to do software MSAA? I mean, it would require that you can have a different z-buffer for each render target, and it may require modifying z values in the pixel shader (a big no-no for performance), but I suppose that could be a way...

 

[Inane_Dork]

Well, since supersampling is comparitively harder to optimize, a hardware and software implementation aren't going to differ much in performance.

I wouldn't expect much difference either, but I did not want to impose my expectations on the outcome.

Hrm, I wonder if you could make use of MRT's to do software MSAA? I mean, it would require that you can have a different z-buffer for each render target, and it may require modifying z values in the pixel shader (a big no-no for performance), but I suppose that could be a way...

If I'm reading the DX SDK correctly, you can only output one depth value per pixel.

 

[Xmas]

MSAA has to be done in software when it is NOT supported by hardware. Otherwise you will have to resort to super-sampling. So, I was estimating the performance and quality differences between the two methods done "in software". Why aren't you folks getting this point?

It certainly didn't look that way until later in this thread.

Not MSAA in hardware, YES. But it's the closest thing to implementing MSAA in software. And you'd have to resort to a "software" based method when the underlying hardware doesn't support it natively. Are you getting my point now?

You can implement MSAA in software (like any other algorithm). But trying to squeeze it into a hardware-accelerated method is a bad idea because you're inevitably throwing valuable processing power away.

Exactly, so if you want a viable "software" solution for AA on FP16 targets, supersampling would be the way to go.

I think there are better ways, but they require more work.

Ah, no, it's not an extended bi-linear filter. The sampling is still effectively done at 4 times (instead of 16 due to 4 sets) the frequency of the initial aliased image, so it does satisfy the Nyquist criterion, and hence looks better than ordinary filtering.

You can take as many samples as you want, if the resolution of the data you sample from is not higher than the output resolution, it will hurt more than it helps.

 

[ShootMyMonkey]

Another implementation of SSAA I'm thinking of implementing is using an accumulation buffer, rendering the scene from jittered camera viewpoints and averaging them.

As long as the jitter is smaller than one pixel, I guess I would classify that as supersampling, but not otherwise. The general idea with supersampling is that you're trying to raise the Nyquist limit of your sampling grid so that it is at least as high as the resolution of your final output. That's what sort of makes MSAA not really *true* antitaliasing in my book. SSAA is more correct.

But the fundamental point of choosing one over the other is quality/speed tradeoffs. If you just take screensnaps, of course MSAA is gonig to look worse (at least at the same AA depth), but it generally becomes harder to detect in motion. In hardware or software, SSAA is always going to be slower because you've simply got more to actually render. It's not going to happen just by scaling up a low-res image with some anisotropic kernel and then scaling it back down with linear interpolation -- though that can produce some results on its own that may be good enough if you're maintaining a decent framerate.

 

[KimB]

The general idea with supersampling is that you're trying to raise the Nyquist limit of your sampling grid so that it is at least as high as the resolution of your final output. That's what sort of makes MSAA not really *true* antitaliasing in my book. SSAA is more correct.

Well, MSAA is only anti-aliasing for edges. So it's not true full-screen anti-aliasing (in that while it is applied to the full screen, it doesn't anti-alias the full screen). But it is definitely anti-aliasing, as it does increase the resolution of your sampling grid by the number of samples at triangle edges.