Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 37

Thread: AMD's Open-Source Radeon Driver After Four Years

  1. #21
    Join Date
    Jan 2009
    Posts
    630

    Default

    Quote Originally Posted by Sidicas View Post
    I certainly DON'T think that everybody should move over to Gallium3D drivers on older hardware as for many people, that'd be a loss of features (no MSAA, no Hyper-Z, less 3D performance, etc.)... User's shouldn't have to sacrifice features...
    I can tell you for sure that even though MSAA is missing and most of HyperZ is disabled by default (you can enable it though) and the performance isn't at 100% of the level of Catalyst, the open r300g driver has much more features in total. There are over 50 more OpenGL extensions in r300g than in Catalyst 9.3 on the same hardware. That's a ton of features. See for yourself.

  2. #22
    Join Date
    Jan 2009
    Posts
    1,498

    Default

    Quote Originally Posted by Qaridarium View Post
    "cutting edge feature"

    LOL ??? not really its a poor man feature real man get this: Rotated Sample-Super-Sample-AA RS-SSAAx8

    but this killer cutting edge feature kill all hardware thats why they do MLAA the poor mans AA..
    Cutting edge in that it is new, looks pretty much as good as MSAA and is apparently faster.
    http://www.youtube.com/watch?v=d31oi1OOKbM

  3. #23
    Join Date
    Oct 2008
    Posts
    3,247

    Default

    Quote Originally Posted by Qaridarium View Post
    "cutting edge feature"

    LOL ??? not really its a poor man feature real man get this: Rotated Sample-Super-Sample-AA RS-SSAAx8

    but this killer cutting edge feature kill all hardware thats why they do MLAA the poor mans AA..
    This is a strange definition of cutting edge. By that logic, the new smartphones and tablets this year can't be cutting edge because i can already buy a 3Ghz PC.

  4. #24
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,153

    Default

    Quote Originally Posted by liam View Post
    I'm very (pleasantly) surprised this is coming to Linux so quickly.I also like the idea of MLAA. A nice, simple post-processing idea that can be applied to any scene (though, unlike BlackStar I don't think it is variable only across resolution since it seems very much edge/color contrast dependent).
    As far as I know, the filter has two passes: edge detection and blurring. The kernel for each pass gets executed exactly once for each pixel on the framebuffer, regardless of the amount of edges in the scene (unlike MSAA which gets executed per edge). Now, performance might be somewhat correlation with the amount of edges if the shader uses branches (which I doubt) but even if this is the case... 12 times faster than MSAA 8x? This wouldn't happen if the amount of edges affected MLAA significantly.

  5. #25
    Join Date
    Oct 2008
    Posts
    3,247

    Default

    Quote Originally Posted by BlackStar View Post
    As far as I know, the filter has two passes: edge detection and blurring. The kernel for each pass gets executed exactly once for each pixel on the framebuffer, regardless of the amount of edges in the scene (unlike MSAA which gets executed per edge). Now, performance might be somewhat correlation with the amount of edges if the shader uses branches (which I doubt) but even if this is the case... 12 times faster than MSAA 8x? This wouldn't happen if the amount of edges affected MLAA significantly.
    There appear to be 3 passes, actually: Edge detection, blend weights, and smooth edges.

    Also, i think the 2nd and 3rd passes are based on edges, or at least are optimized to a degree for non-edges. But I'm not very familiar with graphics programming.

    The implementation for Mesa is in TGSI here: http://lists.freedesktop.org/archive...st/010629.html

    which is based on the Jimenez MLAA code, which you can view in a more readable DX10 version here: https://github.com/iryoku/jimenez-ml...haders/MLAA.fx

    Maybe someone smarter than me can make more sense out of it.

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

    Default

    Quote Originally Posted by BlackStar View Post
    As far as I know, the filter has two passes: edge detection and blurring. The kernel for each pass gets executed exactly once for each pixel on the framebuffer, regardless of the amount of edges in the scene (unlike MSAA which gets executed per edge). Now, performance might be somewhat correlation with the amount of edges if the shader uses branches (which I doubt) but even if this is the case... 12 times faster than MSAA 8x? This wouldn't happen if the amount of edges affected MLAA significantly.
    Three passes, and only the first (edge detection) is executed for all pixels. The second and third pass are only executed for the edge-marked pixels (via the stencil), which brings a big speedup compared to running them on all pixels.

    The second pass is what makes it so much better in quality than many of the other implementations; instead of a constant blur, it depends on the type of aliasing. I recommend the fxaa vs mlaa article @ digitalfoundry, you can see how much more fxaa blurs.

  7. #27
    Join Date
    Jun 2011
    Posts
    316

    Default

    Quote Originally Posted by liam View Post
    Cutting edge in that it is new, looks pretty much as good as MSAA and is apparently faster.
    http://www.youtube.com/watch?v=d31oi1OOKbM

    As a gamer on nvidia hardware (under Windows) I've found that MSAA and CSAA fall short while FXAA and MLAA really nail it..
    The major problem with MSAA & CSAA is that it doesn't anti-alias shaders very well (if at all)... So you have these very bright pixels on the edges of objects that are caused by shiny objects but the bright pixels aren't anti-aliased properly because the shaders are at a different level than MSAA/CSAA.. So at decent resolutions (1080p) and very high texture & lightning details you can see some course grainy pixels on the texture caused by the bright reflective lighting on the edges of shiny objects (like wet steps).. MLAA and FXAA fixes that while you can crank MSAA and CSAA to the max all day long and it will do nothing to fix those annoying coarse white pixels along the edges of very shiny objects (which can really detract from the realism, IMO).
    Last edited by Sidicas; 08-18-2011 at 09:53 AM.

  8. #28
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by smitty3268 View Post
    This is a strange definition of cutting edge. By that logic, the new smartphones and tablets this year can't be cutting edge because i can already buy a 3Ghz PC.
    my point isn't in that way. my point is RS-SSAAx8 beats MLAA in "Quality"

    RS-SSAAx8 is the best of the best of the best!

  9. #29
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,153

    Default

    Quote Originally Posted by curaga View Post
    Three passes, and only the first (edge detection) is executed for all pixels. The second and third pass are only executed for the edge-marked pixels (via the stencil), which brings a big speedup compared to running them on all pixels.
    I am missing some secret sauce here. How does the stencil get written? Via GL_ARB_stencil_shader_export (is this even supported on Mesa? It requires GLSL 1.40!) And if yes, why doesn't the loss of early z-tests destroy performance?

    The second pass is what makes it so much better in quality than many of the other implementations; instead of a constant blur, it depends on the type of aliasing. I recommend the fxaa vs mlaa article @ digitalfoundry, you can see how much more fxaa blurs.
    Thanks, will do.

    Edit: I missed the part where this is written in TGSI rather than GLSL. But still, the hardware limitations should be identical. Need to think about this some more.

  10. #30
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,336

    Default

    Quote Originally Posted by BlackStar View Post
    I am missing some secret sauce here. How does the stencil get written? Via GL_ARB_stencil_shader_export (is this even supported on Mesa? It requires GLSL 1.40!) And if yes, why doesn't the loss of early z-tests destroy performance?
    Via
    glClear(GL_STENCIL_BUFFER_BIT);
    glStencilFunc(GL_ALWAYS, 1, ~0);
    glStencilOp(GL_KEEP, GL_KEEP, GL_REPLACE);
    // pass 1 here
    Since pass 1 calls discard for non-edge pixels, the stencil is not marked for those. Early-Z isn't lost this way. This is quite a smart optimization, my jaw dropped too when I first saw it.

Posting Permissions

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