Announcement

Collapse
No announcement yet.

MSAA Anti-Aliasing Finally Comes To Radeon R300g

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

  • #16
    Originally posted by marek View Post
    [...]
    Can we get Grid SuperSampling G-SSAA or Rotated Grid SuperSampling RG-SSAA with the radeon driver?

    I just ask because thatís the only 2 anti-aliasing methods Iím interested in.

    In my point of view all other techniques are just crap in a quality point of view.

    Comment


    • #17
      You don't have to believe their conclusion, just look at their pics. (inb4 the pics are doctored)

      If all of Starcraft 2, AvP, and Just Cause 2 get it wrong, it clearly must not be that easy to use. Tom's claims all three use it, I have to take their word for that since we don't have the source.


      If it has to be "gotten right" at all, that makes it inferior, because having good-quality transparent parts should be a tickbox, and thus forceable by the driver when the app doesn't support it. This is of course assuming many get it wrong, which it looks that they do from above.

      Comment


      • #18
        Also for the r300g driver, R500 now has hyper-Z marked as done.

        Information from:
        http://www.x.org/wiki/RadeonFeature

        Comment


        • #19
          Originally posted by necro-lover View Post
          Can we get Grid SuperSampling G-SSAA or Rotated Grid SuperSampling RG-SSAA with the radeon driver?
          Yes, we can, but it won't work with a lot of apps just like forcing MSAA doesn't work. The requirement is that an app must render all of its geometry to the main framebuffer, which is sometimes not the case, especially with the better-looking 3D apps.

          The proper solution it to have apps implement SSAA and not the driver. The driver is not in charge of this. I mean, the driver can turn it on for the main framebuffer, but if an app renders all of its geometry to a texture, it won't have any effect.

          Originally posted by curaga View Post
          You don't have to believe their conclusion, just look at their pics. (inb4 the pics are doctored)

          If all of Starcraft 2, AvP, and Just Cause 2 get it wrong, it clearly must not be that easy to use. Tom's claims all three use it, I have to take their word for that since we don't have the source.
          All the images where the fence has a lot of aliasing look like alpha-to-coverage was disabled. Maybe the game developers just didn't care, or they didn't know such a feature exists. That's quite common.

          Originally posted by curaga View Post
          If it has to be "gotten right" at all, that makes it inferior, because having good-quality transparent parts should be a tickbox, and thus forceable by the driver when the app doesn't support it. This is of course assuming many get it wrong, which it looks that they do from above.
          Even the standard MSAA isn't a tickbox. It requires setting up an MSAA renderbuffer, rendering to it, and explicitly resolving the renderbuffer to displayable pixels, and that is what apps need to do. This is the standard way of using MSAA in OpenGL and it's also the only way in Direct3D.

          Comment


          • #20
            Originally posted by marek View Post
            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
            Yes, it's nice.. But if I remember correctly that if you extend that fence farther into the distance towards infinity.. If you don't use super-sampling for transparent anti-aliasing then it appears that the fence "disappears" or rather the links end up getting over anti-aliased to the point where they're invisible creating the illusion of a large gap in the fence at a distance, when it really doesn't exist. It's a strange effect that's hard to describe, but I remember it being the reason why nvidia made a push towards TrAA using raw super-sampling rather than MSAA. nVidia's TrAA with super sampling is absolutely gorgeous, but if you're not running high end cards in SLI, it's very slow..

            I remember some games in the Call of Duty series using regular anti-aliasing for transparent textures and it was pretty up close, but rather ugly if you looked parallel to the texture from sharp angles. Certainly better than nothing, I suppose.

            Comment


            • #21
              I think you might be getting to the limitations of AA and sampling in general. If a fence is one half of a pixel thick, you need at least 2x SSAA. If a fence is 1/4th of a pixel thick, you need at least 4x SSAA. If a fence is 1/32nd of a pixel thick, you need at least 32x SSAA, because 16x SSAA will look ugly. And I could go on...

              Comment


              • #22
                Here is a quick MSAA quality comparison on r300g with glxgears: http://imgur.com/a/jNOWo#0

                Comment


                • #23
                  Originally posted by oibaf View Post
                  Here is a quick MSAA quality comparison on r300g with glxgears: http://imgur.com/a/jNOWo#0
                  Thanks for that!

                  Comment


                  • #24
                    Marek, it would be nice to print on stderr a message when MSAA is enabled and which mode (similar to the radeon: Acquired Hyper-Z. messages). I am not sure if the in-game settings always work and who get the precedence (game setting or env var). Thanks.

                    Comment


                    • #25
                      I also noticed a problem: when using MSAA 6x and high resolutions (1920x1080) the screen flashes and get very slow. At the same resolution with MSAA 4x it works fine, probably a limit of some time is reached. Using a RV530.

                      Possibly related to the fact my cards now get detected as a R580?
                      GL_RENDERER = Gallium 0.4 on ATI R580
                      GL_VERSION = 2.1 Mesa 9.1-devel (git-959e83d quantal-oibaf-ppa)
                      GL_VENDOR = X.Org R300 Project
                      Possible regression of http://cgit.freedesktop.org/mesa/mes...7e0e31c9a6f823

                      Comment


                      • #26
                        Originally posted by oibaf View Post
                        Marek, it would be nice to print on stderr a message when MSAA is enabled and which mode (similar to the radeon: Acquired Hyper-Z. messages). I am not sure if the in-game settings always work and who get the precedence (game setting or env var). Thanks.
                        Done. You have to set "RADEON_DEBUG=msaa" though.

                        Originally posted by oibaf View Post
                        I also noticed a problem: when using MSAA 6x and high resolutions (1920x1080) the screen flashes and get very slow. At the same resolution with MSAA 4x it works fine, probably a limit of some time is reached. Using a RV530.

                        Possibly related to the fact my cards now get detected as a R580?
                        Fixed in git. Only the renderer string was wrong. The card was detected correctly.

                        The issue with the flashing screen must be caused by something else.

                        Comment


                        • #27
                          Originally posted by marek View Post
                          Done. You have to set "RADEON_DEBUG=msaa" though.
                          Thanks, this also let me notice that the application has a higher priority than the evn var over MSAA setting.

                          Fixed in git. Only the renderer string was wrong. The card was detected correctly.

                          The issue with the flashing screen must be caused by something else.
                          Thanks again, I'll report a proper bug, probably tomorrow, I want to test some other known apps before.

                          Comment


                          • #28
                            I filed the flashing bug.

                            And here are some performance numbers, openarena, Very High Quality, 1024x768:
                            • no MSAA: 74.6 fps
                            • MSAA 2x: 61.1 fps
                            • MSAA 4x: 41.6 fps
                            • MSAA 6x: 29.7 fps

                            Comment


                            • #29
                              Originally posted by oibaf View Post
                              I also noticed a problem: when using MSAA 6x and high resolutions (1920x1080) the screen flashes and get very slow. At the same resolution with MSAA 4x it works fine, probably a limit of some time is reached. Using a RV530.
                              It's most likely a memory bandwidth limitation as MSAA compression isn't implemented yet.

                              Comment


                              • #30
                                Originally posted by oibaf View Post
                                Gallium (including r300g) also supports MLAA.
                                Not really, most of the hardware covered by r300g can't do MLAA with the only exception being R500 hardware chips.

                                For most people running r300g, MSAA would be their only option.

                                Comment

                                Working...
                                X