GL_ARB_multisample restrictions?


I’ve got a couple of questions regarding the GL_ARB_multisample extension, specifically on NVidia hardware, as I am using a GF3 at the moment.

  1. Is there a way to enable multisample rendering without changing the AA setting in the driver panel? I can only get 4 samples if I force 4xAA in the driver.

  2. Does GF3 support ALPHA_TO_COVERAGE? I can’t get it to work. If it does, can I restrict it to use only 4 levels of intensity rather than the 16 achieved with dithering? What Hardware does support this method?

  3. If I do not Disable GL_SAMPLE_COVERAGE_ARB at the end of each frame, I get some strange and really inconsistent results.
    Like completely grey window (I’m using blue as clear color), no rendering at all (no clear too), SAMPLE_COVERAGE_INVERT only working if I change it twice, etc.
    Is this expected behavior?

  4. Is there a way to specify a bitmask rather than a linear coverage value to control multisample rendering? If not, are there any plans to introduce an extension that exposes this capability (I assume that’s not a restriction of the hardware, as it can convert a linear value into a bitmask, and, if required, invert it).

The only way to access four individual samples with that linear value is to render at a coverage of 0.5, 0.5 inverted, 0.25 and 0.75 inverted, in this order. This gives me four different color values, but it’s not flexible enough for what I want to do, because it writes two samples twice, including depth.

I also played around a bit with D3D multisample mask, but that only got me some flickering triangles, as if the coverage value changed in between frames.

[This message has been edited by Xmas (edited 08-27-2002).]

I have GL_SAMPLE_ALPHA_TO_COVERAGE working now, it’s quite nice. Maybe it was a driver issue, I’m now using 30.82.
Still there’s the dithering problem, can I disable dithering?

See if


does what you are looking for. The specs only say ‘color’ though, dunno if ‘color’ includes ‘alpha’.


Originally posted by Dan82181:
[b]See if


does what you are looking for. The specs only say ‘color’ though, dunno if ‘color’ includes ‘alpha’.


Thanks, but it didn’t help.

When we antialias in 16-bit color, there is the question of whether we should dither when downsampling or not. This is a completely separate question from whether we should dither when rendering.

The answer we’ve selected (at least at present) is that, yes, we should just always dither on the downsample, even if GL_DITHER is disabled.

You can disagree with this decision, but I think it’s reasonable.

I’m guessing this is what you are seeing.

  • Matt

Well, no, this is not what i mean. I’m using 32 bit color. What I mean is, if I have an alpha/coverage value of, say, 0.65, it doesn’t get rounded to 0.5 (as GF3 has a maximum of 4 samples) but instead i get some dithered rendering (dithering on the pixel level, not sample level). Well, both methods would look ugly, so I guess it’s not so important…

This little app:
shows the problem, press A to enable alpha2coverage.

btw, I have that bitmask working now in D3D. It allows some neat effects like adding motion trail to an app with just two lines of code, or doing RGSS at useful framerates.
Why isn’t this possible in OpenGL?

I think you’re seeing expected behavior. Alpha to coverage is supposed to produce a “dithered” polygon-stipple-like effect.

  • Matt

Yes, it’s obvious that this dithering is intentional. But I wanted to get rid of it.

Well, I’m going to use D3D now, that sample bitmask is much more convenient to use.