Multisampled FBO => flimmering artifacts on ATI


i render my scene to FBO1 with multisampled renderbuffers, blit FBO1 to FBO2(with GL_TEXTURE_2D as storage) to downsample, and finally render a fullscreen quad to the framebuffer with FBO2’s texture.

This works nicely on Nvidia 8800Gt. On Ati X3850, it works basically too, but i get random white flimmering pixels at some multisampled edges.

As long as long as the objects remain static, the white pixels stay at the same position. When i change the modelview slighty, they appear at other random locations, but only at the multisampled regions.

Here an image of some frames with slightly changed positions:

My implementation is based on this:

  • I tried Catalyst 8.8 and 8.12 and a few driver settings(catalyst ai etc), but nothing changed.
  • Tried 16bit-float and 8bit backbuffers => no change
  • Tried a different X3850, behaves the same
  • When i do glReadpixels of FBO2 after blitting, i see the artifacts already
  • When i set numSamples to 0 when creating the renderBuffers of FBO1, everything is ok(but no smoothing then of course)

What might be the cause?
Any idea for a solution/workaround?

Found a solution: Enabling “Adaptive Anti-Aliasing” in the driver settings seems to fix the white flickering artifacts(i have not verfied yet that it really does in all cases).

It’s normally meant to fix aliasing in alpha-test textures like fences in games. I have alpha-blended-textures, but i don’t understand why i need to enabled it though…

Anyhow, can this option be set via OpenGL?

The adaptive AA is just hiding the problem by diminishing the contribution from aberrant sub-samples. This looks like a backface vs. frontface zfighting artifact at the silhouette where they can become arbitrarily close; if you can, enable backface culling.

It could also be z invariance if you’re using multiple passes but that’s generally less of an issue on modern hardware.

Thanks for your input, dorbie. I checked the points you mentioned:

  • It’s 1 pass only
  • Culling is on
    So i don’t think that’s the problem directly.

But while checking, i took a closer look at the scene rendering:

  • With all simple shaders(decal only, no lighting) there are no artifacts visible
  • If i use a very simple shader pair to show the “” as “result.color.rgb”, i see flimmering pixels as black holes.
    (Came up with that idea after pointless hours of debugging my shaders :stuck_out_tongue: They produce white pixels because of those normals)
  • With that adaptive AA the holes are also closed when rendering the vertex.normal

The whole thing looks like a zfighting artifact, you are right, but i don’t know how to fix it…

Are you using dFdx or dFdy in your shaders? It might be, that these don’t work the way you assume at multisampled polygon edges.

I had a problem like this, the solution was to declare all my GLSL varyings as centroid.

An explanation for why is here:

Hmm not directly at least. I use the ASM shaders, and just do regular stuff like dot3 bump mapping, shadow mapping etc.

Well, i think i give up finding a solution. :tired:

I just enable “adaptive AA” in the registry and leave it at that. To accomplish that, the key “ASTT” must changed from “0x30,0x00” to “0x31,0x00” (at least for catalyst 8.8 on winXP).

If you have more ideas, i’m still interested in understanding the problem.

Thanks that’s it :slight_smile:

But there’s no way to specify “centroid” for ARB_vertex/fragment_program, right?

Centroid support was introduced in the NV_fragment_program4 extension, but as you want to support ATI you’ll have to switch to GLSL.
Or just switch to Direct3D (seriously)