Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 31

Thread: MSAA Anti-Aliasing Finally Comes To Radeon R300g

  1. #11
    Join Date
    Jan 2009
    Posts
    598

    Default

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

  2. #12
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,729

    Default

    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?

  3. #13
    Join Date
    Jan 2009
    Posts
    598

    Default

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

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

  4. #14
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,729

    Default

    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.

  5. #15
    Join Date
    Jan 2009
    Posts
    598

    Default

    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

  6. #16
    Join Date
    Aug 2012
    Posts
    292

    Default

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

  7. #17
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,729

    Default

    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.

  8. #18
    Join Date
    Sep 2010
    Posts
    420

    Default

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

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

  9. #19
    Join Date
    Jan 2009
    Posts
    598

    Default

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

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

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

  10. #20
    Join Date
    Jun 2011
    Posts
    315

    Default

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

Posting Permissions

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