View Full Version : Wrong fragment coordinates with 16x multisample render target?

01-10-2017, 08:25 AM
Hello everybody,

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. it 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.

Manual gradients also break for 16/32 samples, i.e. dFdx/dFdy of the world-space position return vec4(0.0).

Which leaves the question: Why is the relative offset inside a fragment not always (0.5, 0.5), depending on the number of samples? What am I not seeing? Is the implementation (Nvidia with driver 376.33 on Win 8.1) allowed to do that? And is the implementation allowed to ignore the redefinition of gl_FragCoord as specified in the GL_ARB_fragment_coord_conventions extension? Or is this simply a bug?