deqp-gles: Add test to cover unwritten MRTs

[robclark]

After debugging a rendering corruption issue[1] in 3dmark, I realized the problem was a driver bug caused by a renderpass with two MRTs bound, but used with a fragment shader that only had a single color output (resulting in 2nd MRT getting undefined results). It would be useful if deqp's MRT tests covered this case.

[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8685

[anholt]

Test coverage would be most useful if it rendered with a shader with multiple color outputs first, then switched to a fragment shader rendering to output variables that are a subset of the color attachments.

[davidwelch158]

The OpenGLES3.2 specification says

Section 14.3.2 "Any fragment colors which are not written by the fragment shader are undefined."

[robclark]

The OpenGLES3.2 specification says

Section 14.3.2 "Any fragment colors which are not written by the fragment shader are undefined."

In this case, it is not that the shader is not writing to a defined color output, but that the fragment shader only defines a single color output but is used with an FBO that has multiple color buffers bound. So I don't think that wording applies here.

I agree the spec could be more clear about this scenario. But empirical evidence shows we have apps that depend on this behavior not being undefined.

[anholt]

I hadn't found the GLES spec text here, just the GLSL ES spec text ("If some, but not all user-defined output variables are written, the values of fragment colors corresponding to unwritten variables are similarly undefined"). Given the GLES spec text, I think that this concludes that the app is broken and we should report it to them and back out the workaround at some point.