Part of the Khronos Group

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 12 of 12

Thread: alpha-to-coverage on NV 182.08

  1. #11
    Junior Member Newbie
    Join Date
    Aug 2006

    Re: alpha-to-coverage on NV 182.08

    Here's some screenshots...

    White quad, alpha gradient [0, 1.0] @ 8x MSAA (gamma correction off):

    White quad, alpha gradient [0, 1.0] @ 8x MSAA (gamma correction on):

    Notice there is no band shift between the two screenshots so the difference only comes from the fact that pixels are put back in "gamma space" after fragments averaging (resolve stage) which is correct. The alpha value is not converted somehow.

    Here is what happen when gamma correction is on:
    each fragment is linearized, averaged, and the result is put back in gamma space (resulting pixel). In my screenshot linearization does nothing since color is 1.0. Quad's white fragments and black clear color fragments are then averaged and the end result (<1.0) is boosted in gamma space.

    I don't think alpha to coverage need to match alpha blend. It is a better alternative than the aliasing prone alpha test. You may want to detect if "gamma correction" is on at application initialization time by doing a simple test and then adjust your textures or shader... better than reverting back to alpha test.

    Foliage and fences are typical usages.

    Additional notes:

    - Correct me if I'm wrong but I think on ATI the "gamma correction" is still set to on (default) and there is no way to disable it in their control panel.

    - The 2x2 dither pattern is bad when CSAA is involded (16xQ) even if there is also 8 MSAA samples:


  2. #12
    Member Regular Contributor
    Join Date
    May 2001

    Re: alpha-to-coverage on NV 182.08

    Quote Originally Posted by Cubitus
    I don't think alpha to coverage need to match alpha blend.
    To achieve proper colour space support the two should match. But this means that if the framebuffer is considered sRGB-encoded then blending should involve sRGB<->lRGB conversions as well.

Posting Permissions

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