(Crosspost from the OpenGL Discussion Board because I now feel confident this is an implementation-dependent issue.)
I am struggling with the values of gl_FragCoord.xy provided by the GL. I want to display values calculated in a preceeding compute shader, which I do by drawing a usual full-screen quad consisting of two triangles. In the fragment shader, I access the compute shader output (in an SSBO) with the fragment coordinates gl_FragCoord.xy. By the nature of the data, this resolve step is and should be single-sample rendering. The render target, however, is a GL_TEXTURE_2D_MULTISAMPLE. Therefore, I disable multisampling right before the draw call with glDisable(GL_MULTISAMPLE) and then enable it again afterwards. No problems so far - but!
If I specify 1, 4 or 8 samples for the texture, everything works great, each fragment coordinate is at the center of its fragment (i.e. the bottom left fragment has gl_FragCoord.xy == vec2(0.5, 0.5)). If, however, I specify 16 or 32 samples, the fragment coordinate jumps to the relative position (0.75, 0.75) in each fragment, which leads to artifacts in the visualization. I double-checked that multisampling is disabled, sample shading is also disabled, so I am merely rendering single-sampled to a multisample texture, but the number of samples in this texture changes the behavior of the GL. Is this intended?
I tried to influence the relative offset of the fragment coordinate with layout(pixel_center_integer) in vec4 gl_FragCoord;, which works as expected for <= 8 samples, i.e. the relative offset is now (0.0, 0.0). For 16/32 samples, the offset stays at (0.75, 0.75), i.e. the redefinition is completely ignored. When enabling multisampling for the resolve pass, none of the behavior changes. When additionally enabling sample shading and setting glMinSampleShading(1.0), the relative offsets change to “random” values for all numbers of samples, as expected. So at least this is working.
I was not sure whether to flag this post as a bug report, as I don’t know if the specification actually allows the implementation to freely choose fragment offsets when rendering to a multisample render target, even if multisampling is disabled. Yet, it is annoying behavior and ignoring the redefinition of gl_FragCoord as specified in the GL_ARB_fragment_coord_conventions sounds like a bug.
Manual gradients also break for 16/32 samples, i.e. dFdx/dFdy of the world-space position return vec4(0.0). This issue has already been discussed inconclusively in the DevTalk. I don’t know if these two issues are related.
For the moment, the workaround is to limit the maximum number of samples to 8, but it is a shame, since 32 samples are supported by my card - GTX 980 with driver version 376.33 on Windows 8.1 64 bit.
I’d love to get some info on these issues. Especially the broken derivatives are bugging me. The fragment offsets could also be fixed manually.