Announcement

Collapse
No announcement yet.

MSAA Anti-Aliasing Finally Comes To Radeon R300g

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • MSAA Anti-Aliasing Finally Comes To Radeon R300g

    Phoronix: MSAA Anti-Aliasing Finally Comes To Radeon R300g

    While the AMD Radeon "R300g" Gallium3D driver has been effectively "done" for a while, only this weekend has multi-sample anti-aliasing (MSAA) support come to this open-source graphics driver that supports the ATI Radeon X1000 (R500) GPUs and older hardware...

    http://www.phoronix.com/vr.php?view=MTI2Nzk

  • #2
    This is also only standard MSAA while the proprietary AMD and NVIDIA drivers with modern GPUs support much more advanced anti-aliasing (AA) methods.
    Gallium (including r300g) also supports MLAA.

    Comment


    • #3
      I was just about to bring up MLAA. Can we get an update on the status of it?

      Comment


      • #4
        Thanks Marek! I'll updated my PPA tomorrow and test on my RV530.

        Comment


        • #5
          Test on a LiveCD?

          I have a RS690 (r400) that is unfortunately stuck on Windows right now. How long does piglet usually take to run? Any expected issues with running from a LiveCD?

          Is this the latest piglit website? http://people.freedesktop.org/~nh/piglit/

          Comment


          • #6
            Originally posted by gQuigs View Post
            I have a RS690 (r400) that is unfortunately stuck on Windows right now. How long does piglet usually take to run? Any expected issues with running from a LiveCD?

            Is this the latest piglit website? http://people.freedesktop.org/~nh/piglit/
            Yes, download it with git and then see its README: http://cgit.freedesktop.org/piglit/tree/README

            Comment


            • #7
              The all.test can take many hours (I tried it some months ago), you can probably do it with a LiveCD if you have enough RAM since you'll have to download a lot of packages to be able to use it. I'd suggest to run the LiveCD image from a USB drive where you can download and save packages after reboting.

              Comment


              • #8
                I don't recommend running all.tests. Running quick-driver.tests is enough and doesn't take so long.

                Comment


                • #9
                  So Merek, how do you want my money? Very spiffy.

                  Comment


                  • #10
                    Originally posted by EmbraceUnity View Post
                    I was just about to bring up MLAA. Can we get an update on the status of it?
                    No changes w/ MLAA since the 8.0 release. The post-processing in general has had some small optimizations.

                    The MLAA implementation is essentially complete, so there isn't really anything to change. New algorithms, like TXAA/FXAA could be added by someone interested as an alternative.

                    Comment


                    • #11
                      We can make MLAA a bit faster. There is some needless memory copying we can eliminate. However, MSAA will always give you higher quality.

                      Comment


                      • #12
                        The quality entirely depends on what you're looking at. MSAA will completely fail with transparent textures, for example.

                        Do you mean the PP queue in the special case of only one filter, MLAA? That's not an extra copy, since we need to write to the same texture we're reading from, that's not possible without the copy (pp_run.c:56).

                        Or do you mean some other part?

                        Comment


                        • #13
                          Originally posted by curaga View Post
                          The quality entirely depends on what you're looking at. MSAA will completely fail with transparent textures, for example.
                          That's not correct. For per-pixel antialiasing of transparent textures (like tree leaves), there is alpha-to-mask AKA alpha-to-coverage AKA GL_SAMPLE_ALPHA_TO_COVERAGE, a nifty feature of MSAA. It's like alpha-test with antialiasing.

                          Originally posted by curaga View Post
                          Do you mean the PP queue in the special case of only one filter, MLAA? That's not an extra copy, since we need to write to the same texture we're reading from, that's not possible without the copy (pp_run.c:56).
                          The PP queue can't do anything about it, but the DRI state tracker can. If it rendered the frame to a temporary texture instead of the back buffer, the PP queue wouldn't have to do the copy.

                          Comment


                          • #14
                            Alpha to coverage seems much inferior to MLAA:

                            http://www.tomshardware.com/reviews/...on,2868-8.html

                            Secondly, we learned that the aliasing that occurs on objects with texture transparencies is unaffected by MSAA, and despite newer DirectX 10/11 techniques like alpha-to-coverage, we see a need for further transparent texture anti-aliasing. When it comes to Radeons, adaptive anti-aliasing rarely works, but Nvidia’s transparent supersampling is relatively reliable in DirectX 10 and 11 games. This is an area we’d really like to see AMD improve.
                            The article has pics showing how alpha-to-coverage still leaves the transparent parts much aliased.

                            Comment


                            • #15
                              I don't believe Tom's hardware or any other hw review site on what technique is better. Alpha-to-coverage is pretty simple: it takes the alpha channel and uses it to represent how much a pixel is covered. If you can properly set the alpha channel, you can easily make the result look as if there were an edge. The problem is applications must take care of sharpening or bluring the alpha depending on how much the alpha channel source (usually a texture) is magnified or minified. Some apps do get it wrong, but it's not the fault of the technique itself.

                              This is an example of alpha-to-coverage that could use some sharpening. Other than that, it looks properly antialiased:
                              http://www.humus.name/3D/alphatocoverage_large.jpg

                              Comment

                              Working...
                              X