Announcement

Collapse
No announcement yet.

Gallium3D Post-Processing, MLAA Nearly Ready

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

  • #16
    I wouldn't equate FXAA with SMAA, even the current MLAA beats FXAA in my opinion. Though they are similar in both being post-processing approaches.

    Comment


    • #17
      Originally posted by curaga View Post
      I wouldn't equate FXAA with SMAA, even the current MLAA beats FXAA in my opinion. Though they are similar in both being post-processing approaches.
      In quality, maybe. It's kind of subjective, but I'd declare FXAA and MLAA a draw.

      In performance Nvidia's FXAA implementation wins AMD's MLAA (on Windows) quite clearly.

      Edit: Oh, and I equated FXAA with SMAA instead of MLAA, because unlike MLAA it also uses a subpixel approach.

      Comment


      • #18
        Originally posted by curaga View Post
        The updated source has not been released yet. 1.6 also changed the name, it's called SMAA (Subpixel Morphological AA).
        Good to know! I found some more info here: http://www.iryoku.com/introducing-su...l-antialiasing

        Comment


        • #19
          Originally posted by Otus View Post
          In performance Nvidia's FXAA implementation wins AMD's MLAA (on Windows) quite clearly.
          That is not hard to do, Jimenez' MLAA beats AMD's by a factor of 7-8x in speed, while also beating it in quality. Though this was measured before 11.8 which claims to have sped up AMD's MLAA.

          Comment


          • #20
            PP is now available in Mesa master.

            Comment


            • #21
              Originally posted by curaga View Post
              PP is now available in Mesa master.
              Congrats!

              So how do I enable it properly? I maxed out the two last values in the image quality tab in driconf but I couldn't tell the difference in glxgears. I made screenshots and a logged off & back.
              Thanks for the heads-up!

              Comment


              • #22
                - which values?
                - which card/driver?
                - are you sure driconf is setting those for the right driver? I think the GUI is still buggy in that it sometimes uses the wrong driver name (e.g. r300 when it should be dri2)


                In other news, the hw status of MLAA in current master:

                - r300g still lacks ROUND, patch available thanks to Tom
                - r600g affected by loop bug / https://bugs.freedesktop.org/show_bug.cgi?id=40034
                - nvfx lacking many GL extensions
                - nv50 and nvc0 should work (not 100% sure)

                As I only have the e-350, I don't know whether the loop bug affects other hw in r600g. It's likely though, since the loop support is not really used anywhere (the glsl compiler unrolls even huge loops).

                Comment


                • #23
                  Originally posted by curaga View Post
                  - nv50 and nvc0 should work (not 100% sure)
                  nv50 does not work, at least for me - nv84 card:

                  $ pp_jimenezmlaa=2 glxgears
                  ATTENTION: default value of option pp_jimenezmlaa overridden by environment.
                  Running synchronized to the vertical refresh. The framerate should be
                  approximately the same as the monitor refresh rate.
                  bld_instruction:1988 - unhandled opcode 27
                  Aborted

                  pp_nored, pp_noblue, pp_nogreen work OK (with some 25% drop in glxgears reported fps)

                  Comment


                  • #24
                    Originally posted by curaga View Post
                    - which values?
                    "Morphological anti-aliasing based on Jimenez' MLAA" and its colour version set from 0 to 32.

                    Originally posted by curaga View Post
                    - which card/driver?
                    Gallium 0.4 on AMD RV730

                    Originally posted by curaga View Post
                    - are you sure driconf is setting those for the right driver? I think the GUI is still buggy in that it sometimes uses the wrong driver name (e.g. r300 when it should be dri2)
                    In that case I'm not sure, how do I check it?

                    I tried this but failed miserably:
                    $ pp_jimenezmlaa=2 glxgears
                    Running synchronized to the vertical refresh. The framerate should be
                    approximately the same as the monitor refresh rate.
                    Segmentation fault


                    Thanks for the help!

                    Comment


                    • #25
                      @HokTar

                      The gui writes the XML config file ~/.drirc. The "<device screen="0" driver="dri">" line should have dri2 as the driver for r600g. Setting PP_DEBUG=1 will tell you if filters are enabled.

                      I wonder if you could post the output of "PP_DEBUG=1 pp_jimenezmlaa=2 glxgears"? Even without the loop bug workaround, I didn't get segfaults, just wrong output.

                      Comment


                      • #26
                        Originally posted by curaga View Post
                        @HokTar

                        The gui writes the XML config file ~/.drirc. The "<device screen="0" driver="dri">" line should have dri2 as the driver for r600g. Setting PP_DEBUG=1 will tell you if filters are enabled.

                        I wonder if you could post the output of "PP_DEBUG=1 pp_jimenezmlaa=2 glxgears"? Even without the loop bug workaround, I didn't get segfaults, just wrong output.
                        The output doesn't mean much to me, everything seems fine then segfault comes:

                        $ PP_DEBUG=1 pp_jimenezmlaa=2 glxgears
                        ATTENTION: default value of option pp_jimenezmlaa overridden by environment.
                        Initializing the post-processing queue.
                        Initializing program
                        mlaa: using 2 max search steps
                        Queue successfully allocated. 1 filter(s).
                        Initializing FBOs, size 300x300
                        Requesting 1 temps and 2 inner temps
                        Running synchronized to the vertical refresh. The framerate should be
                        approximately the same as the monitor refresh rate.
                        Segmentation fault


                        .drirc says r600 so retrying with dri2 now.

                        Comment


                        • #27
                          I wonder if you could get a backtrace?

                          Comment


                          • #28
                            Edit not possible...

                            Setting dri2 solves the problem, so PP_DEBUG=1 pp_jimenezmlaa=2 glxgears works fine now.
                            However, I still can't tell the difference even when I set 0 or 32. Fps goes down from ~1500 to ~200, though.

                            Comment


                            • #29
                              I'll take that as r700 is affected by the loop bug as well.

                              Comment


                              • #30
                                Originally posted by HokTar View Post
                                Edit not possible...

                                Setting dri2 solves the problem, so PP_DEBUG=1 pp_jimenezmlaa=2 glxgears works fine now.
                                However, I still can't tell the difference even when I set 0 or 32. Fps goes down from ~1500 to ~200, though.
                                The normal version doesn't seem to work right, but pp_jimenezmlaa_color should.

                                Comment

                                Working...
                                X