shader-db crashes when running piglit shaders
Submitted by ben@besd.de
Assigned to Piglit Mailing List
Link to original bug (#106052)
Description
It shouldn't, should it?
ATTENTION: default value of option allow_glsl_extension_directive_midshader overridden by environment. ERROR: shaders/csgo/fp-1.shader_test failed to compile ERROR: shaders/piglit/e0638f1c9eca81c574bcd627e60f62282ec8ff75_3.shader_test failed to compile: 0:1(12): error: extension `GL_OES_EGL_image_external' unsupported in fragment shader
ERROR: shaders/piglit/5494a68e2d2804590b505fa3639cba5753f7ad07_3.shader_test failed to compile: 0:1(11): error: syntax error, unexpected NEW_IDENTIFIER, expecting BASIC_TYPE_TOK or STRUCT or VOID_TOK or TYPE_IDENTIFIER
ERROR: shaders/piglit/5494a68e2d2804590b505fa3639cba5753f7ad07_3.shader_test failed to compile: 0:1(17): error: syntax error, unexpected BASIC_TYPE_TOK, expecting '{'
=> CRASHED <= while processing these shaders:
shaders/piglit/31f45c3387576beac1a7f5ea33b116f61711942e_3.shader_test
shaders/piglit/d553aae412090e34289d9e3ae30faf7a5f4828a9_3.shader_test
shaders/piglit/c8e89407effb43a2a5dfdfbe07f2105335c00389_2.shader_test
shaders/piglit/b3f09aeeda5f196f8f53d692d039c5596e7da3de_699.shader_test
shaders/piglit/0e67bb066d9a577798046ae2181c5ee934c90264_2.shader_test
shaders/piglit/174b4d638e3afe8eb11b180ef20e1ea55279f47a_455.shader_test
shaders/piglit/a23083b6b74ed805a670bd833b3000a46e21c721_4.shader_test
shaders/piglit/a45151d54ca1261531972431b80fedf96d62e441_3.shader_testActivity
The offending shaders are:
shaders/piglit/c8e89407effb43a2a5dfdfbe07f2105335c00389_2.shader_test
[require] GLSL >= 0.00 GL_ARB_separate_shader_objects SSO ENABLED
shaders/piglit/daae4cde7db90be01850fc61f495ec218db305fc_1.shader
[require] GLSL >= 0.00
I did a piglit run before and the only crashes it reported were these
shaders 547/553 glsl-fs-inline-explosion crash glsl-fs-unroll-explosion crash glsl-fs-vec4-indexing-8 fail glsl-routing fail glsl-vs-inline-explosion crash glsl-vs-unroll-explosion crash
Attachment 138843, "test fragment":
file_106052.txtI've seen this error with the 0.00 version before https://bugs.freedesktop.org/show_bug.cgi?id=105807#c8
and I can reproduce it if I force the context in the above fragment with glutInitContextVersion( 3, 0 );
could be 3.1, 3.2 or 3.0
but with 4.5 it works and I can get a list of supported versions
Handling this correctly could possibly also fix this
ERROR: shaders/metro2033redux/fbf8031490eb77c2d30ed329353198d8e597cba2_4875.shader_test failed to compile: 0:1(10): error: GLSL 4.00 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.00 ES, 3.00 ES, 3.10 ES, and 3.20 ES
seems NIR has specific crashes too
=> CRASHED <= while processing these shaders:
shaders/piglit/da1588b9fd1ec5009a02ff9ee244f11923d32855_3.shader_test[require] GLSL >= 1.10
[vertex shader] #version 110 #if VERSION >= 130 in vec4 piglit_vertex; #else attribute vec4 piglit_vertex; #endif void main() { gl_Position = piglit_vertex; }
[fragment shader] #version 110 uniform float id; void main() { ivec4 test = ivec4(0, 1, 0, 0); vec4 test2 = vec4(0.0, 1.0, 0.0, 0.0); int index = int(id); float col = test2[test[index]]; gl_FragColor = vec4(col); }
Another shader that has problems (but for both TGSI/NIR)
ERROR: shaders/piglit/a5b6cf610f51fc289f4c30864e2914ddd78bcf68_3.shader_test failed to compile: 0:4(2): error: value of type float cannot be assigned to variable of type vec4
[require] GLSL >= 0.00
[vertex shader] attribute float pos; void main() { gl_Position = pos; }
[fragment shader] void main() { gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0); }
From /**
- \file glsl-max-vertex-attrib.c
- Test setting vertex attrib value of GL_MAX_VERTEX_ATTRIBS attrib
- Queries the value for GL_MAX_VERTEX_ATTRIBS and uses that as index
- to set a value. GL specification states that GL_INVALID_VALUE should
- occur if index >= GL_MAX_VERTEX_ATTRIBS.
- \author Sun Yi yi.sun@intel.com
- \author Tapani Pälli tapani.palli@intel.com */
Patch 138854, "fix incorrect assignment of float to vec4 in tests/shaders/glsl-max-vertex-attrib.c":
file_106052.txt@tarcerisaid:(In reply to ben@besd.de from comment 10)
Created attachment 138854 [details] [review] fix incorrect assignment of float to vec4 in tests/shaders/glsl-max-vertex-attrib.c
Thanks for debugging this. I pushed a slightly different fix:
commit e60d247e Author: Timothy Arceri tarceri@itsqueeze.com Date: Tue Apr 17 18:14:20 2018 +1000
glsl-max-vertex-attrib: fix shader and check for successful link The previous vertex shader failed to compile.@tarcerisaid:(In reply to ben@besd.de from comment 8)
seems NIR has specific crashes too
=> CRASHED <= while processing these shaders:
shaders/piglit/da1588b9fd1ec5009a02ff9ee244f11923d32855_3.shader_test[require] GLSL >= 1.10
[vertex shader] #version 110 #if VERSION >= 130 in vec4 piglit_vertex; #else attribute vec4 piglit_vertex; #endif void main() { gl_Position = piglit_vertex; }
[fragment shader] #version 110 uniform float id; void main() { ivec4 test = ivec4(0, 1, 0, 0); vec4 test2 = vec4(0.0, 1.0, 0.0, 0.0); int index = int(id); float col = test2[test[index]]; gl_FragColor = vec4(col); }
This is tests/shaders/glsl-fs-vec4-indexing-8.shader_test and that piglit test fails in the glsl_to_nir pass for me. No need to track that issue here.
@tarcerisaid:(In reply to ben@besd.de from comment 2)
The offending shaders are:
shaders/piglit/c8e89407effb43a2a5dfdfbe07f2105335c00389_2.shader_test
[require] GLSL >= 0.00 GL_ARB_separate_shader_objects SSO ENABLED
shaders/piglit/daae4cde7db90be01850fc61f495ec218db305fc_1.shader
[require] GLSL >= 0.00
Seems this happens when the shader fails to compile. This seems to be an issue with the piglit tests rather than Mesa.
Hi Timothy thanks for looking into this.
If you remember from https://bugs.freedesktop.org/show_bug.cgi?id=105807#c8
this kind of thing also happens with "real world" shaders so I dont think this is piglit specific, rather that the piglit shaders in question expose a flaw in mesa.
@tarcerisaid:(In reply to ben@besd.de from comment 14)
Hi Timothy thanks for looking into this.
If you remember from https://bugs.freedesktop.org/show_bug.cgi?id=105807#c8
this kind of thing also happens with "real world" shaders so I dont think this is piglit specific, rather that the piglit shaders in question expose a flaw in mesa.
That was because the shaders were failing to compile until I fixed Mesa to compile the compat shaders correctly :)
no, there were significantly more piglit shaders failing because gpu_shader5 wasnt available in the context they requested.
The two I fixed still didnt work after that.
And there is one that still doesnt because it uses some mixture of instructions that are depreciated in 150 and gpu_shader5
@tarcerisaid:(In reply to ben@besd.de from comment 16)
no, there were significantly more piglit shaders failing because gpu_shader5 wasnt available in the context they requested.
The two I fixed still didnt work after that.
I'm not sure what you mean here. Isn't that a piglit issue?
And there is one that still doesnt because it uses some mixture of instructions that are depreciated in 150 and gpu_shader5
As I said in the gpu_shader5 bug we sometimes allow extensions to work in lower GL versions than the spec specifies. Whether we should be testing it works in via Piglit is questionable since other implementations use piglit for testing, but then again it is Mesas test suite so it's not unreasonable to do so.
well... Mesa implements OpenGl so OpenGL is the standard. The version requirements are there for a reason.
As far as piglit is concerned: I havent given it much thought but can it be that you have to explicitly ask it to check whether the shader you want to use for testing actually compiled? Does that make sense?
The shaders I'm talking about were looking for gpu_shader5 but mesa as of now only enables that in OpenGL 4.0 it should in 3.2 (GLSL 150)
after that they worked fine, doesnt have anything to do with compat shaders
@imirkinsaid:(In reply to ben@besd.de from comment 18)
well... Mesa implements OpenGl so OpenGL is the standard. The version requirements are there for a reason.
The reason tends to be "only planning on adding to driver that supports version N, don't feel like thinking about earlier versions". In general, we disregard those where they don't make sense.
The shaders I'm talking about were looking for gpu_shader5 but mesa as of now only enables that in OpenGL 4.0 it should in 3.2 (GLSL 150)
A test that requested a compat GL 3.2 context would likely have similar issues to what you're seeing now with Mesa.
(All that said, ARB_gpu_shader5 should probably not be exposed in a GL context below 3.2 on Mesa -- it could potentially work with lower with ARB_geometry_shader4, but that's not supported in Mesa.)
All it takes is
- if (consts->GLSLVersion >= 400)
- if (consts->GLSLVersion >= 150) extensions->ARB_gpu_shader5 = GL_TRUE;
and everything is fine (well not everything but that is ;)
