ATI's MSAA algorithm: Does it calculate Z per-sample?

[Arun]

Hey everyone,

After looking at a few Hyper Z documents and stuff about Z Compression, I'd like to ask a little precision...

MultiSampling traditionally is the following, AFAIK:
Calculate color per pixel
Calculate Z per sample
And store both per sample

ATI however seems to claim they get pretty much compression increases linearly to the number of samples. That would mean with two samples, if it's the same triangle, it compresses perfectly.

But if it compresses perfectly, that would imply the Z values are actually identical. Which isn't exactly traditional MultiSampling.

That's just speculation - but I'm kinda wondering if that couldn't explain the Radeon 9700's excellent performance with AA ( as well as the Radeon 9600's rumored AA performance compared to a 5600 with *more* memory bandwidth )
AFAIK, nVidia calculates Z per-sample. Could be wrong on that, too, though.

So, basically, does anyone have any detail on this stuff?

Thanks for reading,


Uttar

 

[Dave Baumann]

A.) Yes, it does (as it has to) cacluate Z per sample

b.)

ATI however seems to claim they get pretty much compression increases linearly to the number of samples. That would mean with two samples, if it's the same triangle, it compresses perfectly.

AFAIK ATI claim they get maximum compression ratios in line with the number of samples. Does it say different somewhere else?

 

[Arun]

Hmm, yeah, probably just misread. Thanks for the quick response.
Feel free to lock this thread if you want. Why do you say "as it has to", though? You wouldn't get that many artifacts from using the same Z Value for each sample in a pixel...

 

[Gubbi]

If you use the same Z-value for the entire pixel, intersecting tris wouldn't be anti-aliased. You would then have something similar to Matrox's FAA.

Cheers
Gubbi

 

[Arun]

If you use the same Z-value for the entire pixel, intersecting tris wouldn't be anti-aliased. You would then have something similar to Matrox's FAA.

Cheers
Gubbi

Err, what? No, that doesn't seem to make sense...
Imagine the following situation:

In a per-sample Z case, the following happens ( assume the greater the Z value, the nearer it is - not the traditional way to do it, but anyway... ) :

Sample 1/2/3/4 got the following Z value: 1, 2, 2, 3
You're trying to draw a new polygon at that location, with the Z values: 6, 7, 9, 7
The new polygon covers the old one: the Z & Color values are updated.
This IS a case of intersecting polygon, isn't it?

Now, imagine with 1 Z value per pixel:
Original values: 2, 2, 2, 2
New values: 7, 7, 7, 7

*Exactly* the same thing happens.
The only problem is when the Z of the new polygon is very near to the one of the old polygon, in which case it might be required to only cover part of the samples - but those cases are rare, aren't they?

This is definitively not comparable to Matrox's FAA, IMO.


Uttar

 

[Xmas]

Sample 1/2/3/4 got the following Z value: 1, 2, 2, 3
You're trying to draw a new polygon at that location, with the Z values: 6, 7, 9, 7
The new polygon covers the old one: the Z & Color values are updated.
This IS a case of intersecting polygon, isn't it?

Not at all.
Gubbi was talking about the case that some samples are in front and some samples are behind the already rendered samples. I.e. intersection edges.

 

[Snyder]

I could be wrong, but it seems to me you are confusing overlapping polygons with intersecting polygons.

The only problem is when the Z of the new polygon is very near to the one of the old polygon, in which case it might be required to only cover part of the samples - but those cases are rare, aren't they?

If I'm not mistaken, these cases exactly are intersecting polygons. Intersection means they have direct contact and so the z values are quite near if not identical.

 

[Arun]

Oopsy Didn't realize that's overlapping polygons.

Can't find a lot of examples of interesting polygons, though - most of the time, intersecting polygons are glitches. Or maybe things like explosions. Any practical examples? Maybe it's a lot more frequent than I think...

I did realize that was the problem, but I just didn't know the correct name for it.


Uttar

 

[3dcgi]

An example of what to look for. Just about anytime a game that has a cylindrical column will have intersecting polygons at the base. Or at least only the column edge and no floor edge. This is because tessellating the floor will add a lot of polygons.

Having only one z value per fragment is exactly why Matrox does not claim FAA is FSAA.

 

[3dcgi]

But if it compresses perfectly, that would imply the Z values are actually identical.

Not so. Ati uses differential compression so perfect compression implies a constant slope, which is what you get if a single triangle covers a pixel. They compress on a block basis though so to get perfect compression there can only be a few edge pixels in the block. I don't know how many edge pixels there can be though. To give you an idea their block size is likely somewhere between 16 and 64 pixels.

 

[Mintmaster]

Not sure if someone mentioned this already, but colour compression and Z compression are separate, and I think that's where you're getting a tad confused, Uttar.

Colour compression ratio has a maximum equal to the number of samples. The interior of polygons should have maximum color buffer compression. This is important because the colour bandwidth is what was holding back MSAA speed before the R300 architecture.

Z compression is, as 3dcgi mentioned, slope-based. You can use larger areas than the number of samples since a whole polygon has the same slope. This can be activated even without MSAA, and has been in the past. The hope is that with MSAA you probably will need very little extra z-bandwidth because the extra samples should all interpolate to the same slopes. Only where the Z-test is not the same over all samples in a pixel will you wind up increasing the Z-bandwidth over non-MSAA rendering.

A big part of compression, however, is that you might need better granularity and latency to really reduce the bandwidth needs of MSAA. All your Z and colour buffer data is now in little bits and pieces, and it takes a good memory controller to optimize the memory access.

 

[Arun]

Not sure if someone mentioned this already, but colour compression and Z compression are separate, and I think that's where you're getting a tad confused, Uttar.

The problem actually was that I didn't know Z Compression was slope-based ( assumed it was a system to determine which bits are identical - doesn't make sense for Z Compression, now that I think about it )


Thanks for the explanations!


Uttar