Jump to content
  • Advertisement
Sign in to follow this  
sysrpn

Anti Aliasing Inside a Shader

This topic is 3175 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!