Multisample AA and glsl derivatives

Hi all,

Has anyone experienced problems when using dFdx/dFdy derivatives in glsl with 16x multisample FBOs in OpenGL? I am using latest drivers on GTX670.

In my case I create the color attachment of the FBO with:

glTexImage2DMultisample(GL_TEXTURE_2D_MULTISAMPLE, 16, GL_RGBA, width, height, GL_FALSE);

When rendering on such an FBO, it appears that dFdx/dFdy return 0, whereas if I reduce the samples parameter to 8 (everything else remaining the same), the derivatives start working (so I am quite sure that the problem is not due to the shader code itself, at least not in a trivial way).

In a related note, does anyone know exactly what type of AA different values of the samples parameter correspond to? I suspect that the actual type of AA (CSAA, MSAA, etc.) when samples=16 may have something to do with my problem.

Any info/pointers would be greatly appreciated.

Did you check if GL_EXT_framebuffer_multisample is available and glGetIntegerv( GL_MAX_SAMPLES, &maxSamples )?
That’s an implementation dependent value.

If 2x, 4x, and 8x work and 16x and higher don’t, that could be because 2x, 4x, and 8x are native multisample formats and 16x and higher are some hybrid methods.

The numbers and samples of CSAA modes can be enumerated with something like this:

if ( numModes )
  // Provide room for the pairs of coverageSamples and colorSamples.
  std::vector<int> modes( 2 * numModes );
  // Get the list of modes.
  glGetIntegerv( GL_MULTISAMPLE_COVERAGE_MODES_NV, &modes[0] );
  // Look at the modes vector contents here...

I would expect CSAA colorSamples to be 8 and lower.

Detlef, Thanks a lot for the info, it’s quite useful.

Now I am testing on a GTX580 with 320.18 drivers. GL_MAX_SAMPLES is 32. The coverage modes enumeration returns the following list (coverage, samples):

2, 2
4, 4
8, 4
8, 8
16, 4
16, 8
16, 16
32, 8
32, 32

It’s unclear to which mode the samples parameter of glTexImage2DMultisample maps to, but NV_framebuffer_multisample_coverage has the following info which is likely to also apply here:

“Since color samples are a subset of coverage samples, the parameter to RenderbufferStorageMultisampleEXT should be treated as a request for coverage samples. The implementation is free to choose the number of color samples used by the renderbuffer.”

The funny thing with is, if I am not mistaken, in a previous version of my application the derivatives were working properly with samples=16. It is possible that some change in my code prompted nVidia drivers to choose a different AA method (or maybe different number of color samples) for the same samples value. I’ll try going back and see if I can find anything.

Here is a quick update.

Instead of glTexImage2DMultisample, I tried allocating renderbuffers using glRenderbufferStorageMultisampleCoverageNV. It seems that once I make the samples parameter 16 or 32, the derivatives stop working. With values less than or equal to 8 they work fine. The coverage parameter does not affect the derivatives (e.g. 32, 8 works fine).