This CTS test defines different shaders that have an uniform block which contains double variables and some dummy variables in-between. Each shader (VS, TESS, GS, FS) checks that it reads the expected data from the uniform block and sets an integer to 1 (if the read was correct) or to 0 (if it is not). Each stage receives as input varyings the result integers from previous stages, sets its own and output all of them to next stage. In case of VS, TESS and GS, those integers are saved by a transform feedback. In case of FS, it is setting the output color to a FBO which is rendering one point to a 1x1 texture with GL_RED32I color format. In the verification process, all transform feedback varyings are read, the texture's value is read and all of them are compared with the expected value (which is 1). First execution with current master showed that only TES eval shader was working. Hovewer, using Curro's i965-spilling-fixes branch (rebased on top of up-to-dated master), then VS, both TESS and GS pass because they were failing because of register spilling issues. Note: Curro's i965-spilling-fixes patches are under review in the mailing list. But then, we still have FS case failing: the shaders were not setting gl_Position for the rendered vertex and it seems the consequence is that FS was not being executed at all! I even modified FS code to be sure about this. Furthermore, if I set gl_Position when emitting the vertex in the Geometry shader, the test pass. Is this behaviour expected? If not, any idea how can I fix it? I was playing in gen8_ps_state.c without luck. Note: NVIDIA proprietary driver passes the test in any condition (with or without setting gl_Position in GS). Relevant info: * Broadwell computer (gen8) * Mesa Master: eb384da * CTS version: GLCTS-4.5.2.0-20150506 * Test: GL42-CTS.gpu_shader_fp64.named_uniform_blocks
So, our FS is not explicitly disabled, but it does not seem to run for any fragments... from the description it seems that NVIDIA assigns a default value to gl_Positon within the render region if the shader does not set it explicitly (probably (0,0,0,1)?). I guess what we need to do to see if this is a bug in the test or in the diver is check if there is anything in the GL spec that mandates a specific value for gl_Position if none is set by the shader.
(In reply to Iago Toral from comment #1) > So, our FS is not explicitly disabled, but it does not seem to run for any > fragments... from the description it seems that NVIDIA assigns a default > value to gl_Positon within the render region if the shader does not set it > explicitly (probably (0,0,0,1)?). Yes, I though the same after submitting this bug report. > I guess what we need to do to see if this > is a bug in the test or in the diver is check if there is anything in the GL > spec that mandates a specific value for gl_Position if none is set by the > shader. From GLSL 4.2, "7.1 Built-In Language Variables": "As an output variable, gl_Position is intended for writing the homogeneous vertex position. It can be written at any time during shader execution. This value will be used by primitive assembly, clipping, culling, and other fixed functionality operations, if present, that operate on primitives after vertex processing has occurred. Its value is undefined after the vertex processing stage if the vertex shader executable does not write gl_Position, and it is undefined after geometry processing if the geometry executable calls EmitVertex() without having written gl_Position since the last EmitVertex() (or hasn't written it at all). As an input variable, gl_Position reads the output written in the previous shader stage to gl_Position." So, according to the spec, gl_Position value is undefined if it is not set by any shader. I found a Chromium bug [0] which explains that some drivers fail when linking shaders that don't set gl_Position. The workaround was to initialize gl_Position at the beginning of the vertex shader's main() to vec4(0,0,0,0) like in ANGLE [1]. Looks like it is a test issue because it doesn't set gl_Position and expects to render a point in the texture. [0] https://bugs.chromium.org/p/chromium/issues/detail?id=416670 [1] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/angle/include/GLSLANG/ShaderLang.h&sq=package:chromium&type=cs&l=171&rcl=1463944873
I forgot to say that I keep this bug open to discuss if we want to initialize gl_Position too, keep current behaviour or if there are more news related to it.
I believe this was a CTS bug fixed by CTS commit 9604d02b1089bc9eb9661deec56fe3e35663fb96. Marking as NOTOURBUG.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.