Does P.S. run multiple times under super sampling AA?

[991060]

This is quite a simple and basic question. I just want to make sure the answer is correct and accurate, any guru enlight me ?

 

[bloodbob]

Well if the question said fragment shader then the answer is yes. Some might argue if it is implementation dependant I think this is more a problem with naming of the shader it should have been fragment shader.

 

[Simon F]

Well if the question said fragment shader then the answer is yes. Some might argue if it is implementation dependant I think this is more a problem with naming of the shader it should have been fragment shader.

Pixel Shader is a perfectly valid name - it's what's used in DX terminology.

To answer the OP's question - Yes, but it also has to run multiple times in multisampling implementatons whenever a boundary crosses through a pixel.

 

[chavvdarrr]

To answer the OP's question - Yes, but it also has to run multiple times in multisampling implementatons whenever a boundary crosses through a pixel.

Does that mean that in theory, a situation is possible, when MSAA will be more demanding than FSAA, in terms of pixel shading power?

 

[Humus]

Pixel Shader is a perfectly valid name - it's what's used in DX terminology.

Depends on how you see it. The distinction between a fragment and a pixel was in common use before DX arrived. Then MS screwed it up and decided there's no difference and thus redefined the term "pixel" already in common use to mean something else.

To answer the OP's question - Yes, but it also has to run multiple times in multisampling implementatons whenever a boundary crosses through a pixel.

Well, the OP's question was not about multisamping, but rather supersampling. So the answer is a clear Yes.
On multisampling though, it can of course be implemented in many ways, but I was under the impression that most implementations just evaluate the sample once, even on boundary pixels and just distributed the result to all subsamples that are covered. Otherwise I don't see the point of centroid sampling.

 

[Simon F]

To answer the OP's question - Yes, but it also has to run multiple times in multisampling implementatons whenever a boundary crosses through a pixel.

Does that mean that in theory, a situation is possible, when MSAA will be more demanding than FSAA, in terms of pixel shading power?

There shouldn't be.

 

[Humus]

To answer the OP's question - Yes, but it also has to run multiple times in multisampling implementatons whenever a boundary crosses through a pixel.

Does that mean that in theory, a situation is possible, when MSAA will be more demanding than FSAA, in terms of pixel shading power?

MSAA will always be less than or equally demanding as SSAA, even in theory. If implemented like Simon F suggests, then the cost of say 6xAA is up to 6 times the cost of no AA, while for SSAA the cost is constantly 6 times that of no AA. Roughly speaking, ignoring mipmap selection etc.

 

[991060]

thanks Humus and Simon, I think I have known the idea.

and BTW, why does nvidia still implement SSAA within their AA algorithm(when it's above 6xAA IIRC), given that NV3X is already in an inferior posiiton than R3XX in term of pixel(fragment) shading power?

 

[akira888]

SSAA has some added side benefits not seen in MSAA. It can reduce aliasing in textures (and also should do the same for normal maps - which HL2 could use in some spots). However, the added cost of such a brute force technique usually means that alternative means to the same ends should be used - AF for texture AA, removal of high frequencies in normal map data, so on...

Then there's always good old punch-through 1-bit alpha that can only be anti-aliased through SSAA AFAIK.

 

[mrbill]

[E]ach fragment includes SAMPLES depth values, color values and sets of texture coordinates, instead of the single depth value, colover value and set of texture coordinates that is maintained in single-sample rendering mode. An implementation may choose to assign the same color value and the same set of texture coordinates to more than one sample.

Assume for a moment that a polygon covers an entire pixel.

The fragment shader can execute as few as once per pixel, a very common implementation which assigns the same color to all samples.

The other extreme is execute the fragment shader once per sample.

Or some choice in between (NV's 2x8 implementation).

All of the above are multisampling.

-mr. bill

 

[KimB]

Then there's always good old punch-through 1-bit alpha that can only be anti-aliased through SSAA AFAIK.

Nah, there's always a way. But, in the case of an alpha test, it requires changing the alpha test to an alpha blend, and making sure that all surfaces that use the alpha blend are rendered front to back. And yes, an alpha blend works just fine on 16-bit textures.

Anyway, I expect the main benefit of the half-supersampling FSAA modes is for older games that don't have high fillrate requirements. For newer games with higher fillrate requirements, you're going to have to run at lower resolutions anyway. Turning on supersampling with modern videocards is a dream for these newer games.

 

[Dave Baumann]

After something Richard Huddy said to me yesterday, it clicked what the point of centroid sampling was in R300 - the actually mentioned it in their marketting at the start, but it never panned out. Centroid sampling can be used to sample Alphas multiple times such that Alphas can recived some kind of texture sampling and work better with MSAA.

 

[Simon F]

After something Richard Huddy said to me yesterday, it clicked what the point of centroid sampling was in R300 - the actually mentioned it in their marketting at the start, but it never panned out. Centroid sampling can be used to sample Alphas multiple times such that Alphas can recived some kind of texture sampling and work better with MSAA.

Correct me if I'm wrong, but centroid sampling depends on the edges of the triangle relative to the pixel, causing a different set of UV coordinates to be generated, and therefore can't be affected by the alpha of the texture being sampled.

 

[arjan de lumens]

After something Richard Huddy said to me yesterday, it clicked what the point of centroid sampling was in R300 - the actually mentioned it in their marketting at the start, but it never panned out. Centroid sampling can be used to sample Alphas multiple times such that Alphas can recived some kind of texture sampling and work better with MSAA.

Nope. The idea of centroid sampling in the context of multisampling is to, for each pixel, determine the area of the pixel that is within the current polygon, find the center point ("centroid") of this area and sample textures/shader programs at this center point instead of at the center of the pixel. This gives somewhat more correct texturing results because you are guaranteed not to sample coordinates outside the polygon, but you still sample each pixel in each polygon only once. And for interior pixels in the polygon it does no difference at all. Has nothing to do with sampling alpha multiple times.

 

[OpenGL guy]

To answer the OP's question - Yes, but it also has to run multiple times in multisampling implementatons whenever a boundary crosses through a pixel.

I don't think so. For a single polygon with MSAA, each pixel with at least one sample covered by the polygon only gets a single color from the pixel shader. The samples covered by the polygon all get this color then depth checking is done to see what gets written. If two polygons intersect, it's the same deal: The samples covered by one polygon only get a single color from that polygon.

Doing supersampling on the edges only would give rise to strange filtering artifacts, such as when rendering a quad subdivided as two triangles.

 

[Humus]

SSAA has some added side benefits not seen in MSAA. It can reduce aliasing in textures (and also should do the same for normal maps - which HL2 could use in some spots). However, the added cost of such a brute force technique usually means that alternative means to the same ends should be used - AF for texture AA, removal of high frequencies in normal map data, so on...

Then there's always good old punch-through 1-bit alpha that can only be anti-aliased through SSAA AFAIK.

It is possible to antialias alpha testing even with multisampling. The solution is as simple as to resort to evaluating all samples whenever alpha testing is enabled, effectively SSAA, but then you don't need to supersample whenever it's turned off, which will still likely be for the majority of the scene.

 

[akira888]

To answer the OP's question - Yes, but it also has to run multiple times in multisampling implementatons whenever a boundary crosses through a pixel.

I don't think so. For a single polygon with MSAA, each pixel with at least one sample covered by the polygon only gets a single color from the pixel shader. The samples covered by the polygon all get this color then depth checking is done to see what gets written. If two polygons intersect, it's the same deal: The samples covered by one polygon only get a single color from that polygon.

Doing supersampling on the edges only would give rise to strange filtering artifacts, such as when rendering a quad subdivided as two triangles.

I kind of think what Simon meant was that if you had a pixel that had contributions from two primitives (in other words an edge pixel) then two distinct color values will be calculated for that pixel, one for each triangle.

 

[akira888]

Then there's always good old punch-through 1-bit alpha that can only be anti-aliased through SSAA AFAIK.

Nah, there's always a way. But, in the case of an alpha test, it requires changing the alpha test to an alpha blend, and making sure that all surfaces that use the alpha blend are rendered front to back. And yes, an alpha blend works just fine on 16-bit textures.

In theory that seems correct, and I had a similiar idea about 4 months ago actually. The caveat of course is this these primitves are now part of the blend-transparency pass. (actually I believe its the back-front pass. Rendering transparencies front-back would be kind of... ...odd. ) How difficult this would be is anyones guess, although I believe a strong clue lies in the fact that I got my 9500 Pro (now up clocked to a ~9800np) in Dec 2002 and yet the grates in HL and CS still look horrible... makes me pine for my 8500LE.

 

[KimB]

Whoops, sorry, meant back to front. My bad.

Anyway, normally you would want to render front to back, so that you're not drawing anything that isn't in the final frame.

But when rendering with an alpha blend, you must render back to front, as the math of the alpha blend includes adding colors. If you don't know the color behind the object, you can't very well add it.

 

[bloodbob]

Well you could defer the blend I guess but it would require a the alpha value to be stored for pixel that need blending operation still and I think things would get rather complicated if you start trying to do unordered rendering.