Good morning (depending on the time zone)! To whom it may concern, the following is a bug report.
Yesterday I discovered that the above mentioned driver shows certain incorrect behavior depending on the code of a tessellation control shader. Let’s get the vertex, tess eval and fragment shaders out of the way first:
/* vertex shader */
#version 420
in vec4 position;
void main()
{
// pass-through
gl_Position = position;
}
/* tess eval shader */
#version 420
layout(isolines) in;
void main()
{
// just draw a line from (0, 0, 0) to (1, 0, 0)
gl_Position = vec4(gl_TessCoord, 1.0);
}
/* fragment shader */
#version 420
out vec4 FragColor;
void main()
{
FragColor = vec4(1.0, 0.0, 0.0, 1.0);
}
All well and good. Now, according to the spec, the following tess control shader should cause the linker to fail linking the program:
#version 420
void main()
{
}
However, this will simply cause the driver to crash. I’d offer a comprehensive stack trace but - yeah, closed source and no symbols.
Interestingly, the following will simply crash as well:
#version 420
layout(vertices = 2) out;
void main()
{
}
If I add only one write to a single output, no matter which, it links and runs.
#version 420
layout(vertices = 2) out;
void main()
{
gl_TessLevelInner[0] = 1.0;
}
Interestingly, the following will compile, link and run just fine as well, although it’s in violation of the spec:
#version 420
void main()
{
gl_TessLevelOuter[0] = 1;
}
The following, however, will crash during linkage:
#version 420
void main()
{
gl_TessLevelInner[0] = 1;
}
To say the least: this is messed up!
As far as I can tell, and as far as I could find any information in the spec, a tess control shader is not mandated to do anything other than specifying the number of vertices in the output patch. I couldn’t find anything so far that states otherwise. In any case, the driver clearly behaves incorrectly.