Announcement

Collapse
No announcement yet.

Morphological Anti-Aliasing With Mesa 8.0

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

  • Morphological Anti-Aliasing With Mesa 8.0

    Phoronix: Morphological Anti-Aliasing With Mesa 8.0

    One of the less talked about features of Mesa 8.0 is its ability to handle MLAA, which is short for Morphological Anti-Aliasing. But how does MLAA on the open-source graphics drivers affect the OpenGL performance and is it worth it for boosting the image quality through this anti-aliasing technique? In this article are some benchmarks of MLAA under Mesa 8.0.

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

  • #2
    What about MSAA?

    Comment


    • #3
      Originally posted by RealNC View Post
      What about MSAA?
      It's not supported yet is it?

      For me the big problem with MLAA except for the performance drop is the anti-aliasing of 2d overlays. All text looks like comic sans basically.

      Comment


      • #4
        When it comes to post processing AA, FXAA seems much better than MLAA anyway. But the "real deal" is MSAA. This really needs to be supported. Though with the huge performance issues of the whole open source graphics stack at the moment, it would probably kill even whatever little performance there is. Going from 80FPS to 70FPS on the binary blobs is not an issue, but going from 30FPS to 20FPS on the open drivers is a huge issue.

        Edit:
        Note that FXAA, even though introduced by NVidia, is a generic AA method, just like MLAA, and works perfectly fine on AMD hardware too.
        Last edited by RealNC; 02-14-2012, 06:37 AM.

        Comment


        • #5
          Looking at the screenshots, I'd prefer the mlaa_color option, and given that it has a less severe performance drop, that makes me even more likely to use it. Now we just need to optimize the crap out of both it and the rest of the stack.

          Comment


          • #6
            Thanks Michael for running the tests. Could you post the full-resolution lossless pics of Nexuiz, for easier comparison?

            It's also surprising how little performance impact there was going from 2 to 16. It's up to 8x more work per pixel.


            @tholin

            That's the drawback of the color version. The depth one does not blur text.

            @RealNC

            In my opinion, FXAA blurred too much, while (Jimenez's) MLAA kept texture details much better. But your comparison is flawed, HardOCP compared AMD's MLAA to FXAA, which is a lot slower and worse in quality compared to Jimenez's algorithm.

            @Veerappan

            I doubt there's much to optimize in the implementation itself, I believe the bottlenecks are in the gallium context switch. Possibly also some buffer switching could be done faster.

            Comment


            • #7
              The performance results are very interesting

              The way just turning it on really hurts performance, but then turning up the quality has no impact. Obviously something other than the shader computations is limiting the speed.

              Didn't Jiminez throw away this algorithm and create some new AA technique recently, or update to a new version? Is there any plan to bring that in, or will Mesa stick with this code for a while?

              Comment


              • #8
                Originally posted by smitty3268 View Post
                Didn't Jiminez throw away this algorithm and create some new AA technique recently, or update to a new version? Is there any plan to bring that in, or will Mesa stick with this code for a while?
                Indeed, he did. IIRC, it's called SMAA (subpixel morphological AA) and offers significantly better quality at the same performance cost.

                Originally posted by RealNC
                What about MSAA?
                Do note that the old-school MSAA is quickly becoming obsolete with these new methods. SMAA offers quality equivalent to 4x MSAA at the cost of 2x MSAA and with greater flexibility to boot. A proper in-game implementation doesn't suffer from blurry fonts, so there's very little reason to use MSAA anymore - its few advantages don't outweight its cost.

                Jimenez's papers are worth a read.

                Comment


                • #9
                  SMAA isn't a full rewrite/new algo, it builds on the MLAA work. SMAA 1x is only slightly changed from the older MLAA.
                  The higher quality modes are also slower, only the 1x mode is ~the same speed as MLAA.

                  Is there any plan to bring that in, or will Mesa stick with this code for a while?
                  No plans from my side, but patches welcome as usual

                  Comment


                  • #10
                    Michael: Can you please use lossless pictures in these reviews? It's kind of hard to see the differences with all the jpeg artifacts.

                    A suggestion for future test: do a "stress test" to compare texture mipmapping with/without AF and different levels of AA.

                    -----

                    MSAA(and related) is of course preferred over MLAA.

                    Comment

                    Working...
                    X