Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Morphological Anti-Aliasing With Mesa 8.0

  1. #1
    Join Date
    Jan 2007
    Posts
    15,129

    Default 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. #2
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,798

    Default

    What about MSAA?

  3. #3
    Join Date
    Mar 2011
    Posts
    9

    Default

    Quote 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.

  4. #4
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,798

    Default

    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 at 06:37 AM.

  5. #5
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    877

    Default

    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.

  6. #6
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,187

    Default

    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.

  7. #7
    Join Date
    Oct 2008
    Posts
    3,174

    Default 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?

  8. #8
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    Quote 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.

    Quote 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.

  9. #9
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,187

    Default

    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

  10. #10
    Join Date
    Jun 2010
    Posts
    164

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •