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:

Code :
 
/* 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:

Code :
#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:

Code :
#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.

Code :
#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:

Code :
#version 420
void main()
{
    gl_TessLevelOuter[0] = 1;
}

The following, however, will crash during linkage:

Code :
#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.