Anti Aliasing Inside a Shader

Started by
3 comments, last by Yann L 14 years, 6 months ago
I wrote a small article about an shader problem and solution I think you might find interesting: When drawing inside polygons using a GPU shader, if your shader outputs areas containing high contrast lines, those lines will be heavily ailiased. Multisampling does nothing to fix the aliasing, as multisampling only serves to smooth the edges of geometry and not their interior fills. Full article with example screens here: http://www.codebot.org/articles/?doc=9557
Advertisement
It is worth noting that beginning with D3D10.1, it is possible to run pixel shaders on per-fragment granularity (instead of per-pixel) to gain "real" antialiasing.

Niko Suni

Quote:Original post by Nik02
It is worth noting that beginning with D3D10.1, it is possible to run pixel shaders on per-fragment granularity (instead of per-pixel) to gain "real" antialiasing.


Interesting. Since I use OpenGL I was unaware of this D3D feature. Could you perhaps link me to the D3D documentation page describing this enhancement?
This feature is actually relatively undocumented in the SDK.

That said, there are two things that make this work:

1: Using a PS parameter with SV_SampleIndex semantic. This will cause the shader to run once per sample.
2: Using the HLSL intrinsic GetRenderTargetSamplePosition function to look up the position of the current PS sample given sample index.

Alternatively, call GetRenderTargetSampleCount and loop thru all sample positions manually.

I'm not sure whether the aforementioned intrinsic function is currently implemented correctly by AMD (ATI cards), but in my practical tests the returned position is the position in the render target pixel space; that is, if your render target is sized [512,512], the returned sample position could be between [-0.5,-0.5] and [512.5,512.5] (though not verified with scientific accuracy ;)). This is the part I'm not sure about - if I didn't know better, I would have imagined that the sample position is defined relative to the current pixel being processed, but this is not the case as of now.

IIRC this requires a SM4.1 feature set.

Niko Suni

Quote:Original post by sysrpn
Interesting. Since I use OpenGL I was unaware of this D3D feature.

It's also available on OpenGL.

However, one should note that specialized AA solutions, such as the one you presented in your first post, can still be considerably faster than simply brute forcing shader execution at all subfragments. The latter is interesting for more complex shaders that would be non-trivial to AA otherwise.

This topic is closed to new replies.

Advertisement