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_test
Looks like you are trying to run an ES shader in a desktop context, so possibly a valid compilation error.
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
The dump is broken for starters. GLSL >= 0.00 Is probably going to end up requesting the wrong GL version. Someone need to track down why this is broken.
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
Created attachment 138843 [details] test fragment
I'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> */
Created attachment 138854 [details] [review] fix incorrect assignment of float to vec4 in tests/shaders/glsl-max-vertex-attrib.c
(In reply to ben@besd.de from comment #10) > Created attachment 138854 [details] [review] [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 e60d247eb359f044caf0c09904da14e39d7adca1 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.
(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.
(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.
(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
(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
(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 ;)
However I dont consciously have any application that uses gpu_shader5 so I can only judge from shader-db runs Do you any?
Found one: Unigine Valley dont know if there's a difference but works MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=150 ./valley Loading "/home/nano/.Valley/valley_1.0.cfg"... Loading "libGPUMonitor_x64.so"... Loading "libGL.so.1"... Loading "libopenal.so.1"... Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock Set 1920x1080 fullscreen video mode Set 1.00 gamma value Unigine engine http://unigine.com/ Binary: Linux 64bit GCC 4.4.5 Release Feb 14 2013 r11294 Features: OpenGL OpenAL XPad360 Joystick Flash Editor App path: /home/nano/Downloads/Unigine_Valley-1.0/bin/ Data path: /home/nano/Downloads/Unigine_Valley-1.0/data/ Save path: /home/nano/.Valley/ ---- System ---- System: Linux 4.16.0+ x86_64 CPU: Intel(R) Xeon(R) CPU E31260L @ 2.40GHz 2400MHz MMX SSE SSE2 SSE3 SSSE3 SSE41 SSE42 AVX HTT x8 GPU: Unknown GPU x1 System memory: 16053 MB Video memory: 256 MB Sync threads: 7 Async threads: 8 ---- MathLib ---- Set SSE2 simd processor ---- Sound ---- Renderer: OpenAL Soft OpenAL vendor: OpenAL Community OpenAL renderer: OpenAL Soft OpenAL version: 1.1 ALSOFT 1.17.2 Found AL_EXT_LINEAR_DISTANCE Found AL_EXT_OFFSET Found ALC_EXT_EFX Found EFX Filter Found EFX Reverb Found EAX Reverb Found QUAD16 format Found 51CHN16 format Found 61CHN16 format Found 71CHN16 format Maximum sources: 256 Maximum effect slots: 4 Maximum auxiliary sends: 2 ---- Render ---- GLRender::GLRender(): Unknown ATI GPU OpenGL vendor: X.Org OpenGL renderer: Radeon RX 560 Series (POLARIS11, DRM 3.26.0, 4.16.0+, LLVM 7.0.0) OpenGL version: 3.2 (Core Profile) Mesa 18.1.0-dev-ben-So 1. Apr 13:40:29 CEST 2018 (git-e76bb06a7e) OpenGL flags: Core Profile Found required GL_ARB_map_buffer_range Found required GL_ARB_vertex_array_object Found required GL_ARB_draw_instanced Found required GL_ARB_draw_elements_base_vertex Found required GL_ARB_transform_feedback Found required GL_ARB_half_float_vertex Found required GL_ARB_half_float_pixel Found required GL_ARB_framebuffer_object Found required GL_ARB_texture_multisample Found required GL_ARB_uniform_buffer_object Found required GL_ARB_geometry_shader4 Found optional GL_ARB_blend_func_extended Found optional GL_ARB_tessellation_shader Found optional GL_ARB_shader_bit_encoding Found optional GL_ARB_sample_shading Found optional GL_ARB_compute_shader Found optional GL_ARB_gpu_shader5 Found optional GL_EXT_texture_compression_s3tc Found optional GL_ARB_texture_compression_rgtc Shading language: 1.50 Maximum texture size: 16384 Maximum texture units: 192 Maximum texture renders: 8 ---- Physics ---- Physics: Multi-threaded ---- PathFind ---- PathFind: Multi-threaded GPUMonitorPlugin::init(): can't initialize GPUMonitor EnginePlugins::init(): can't initialize "GPUMonitor" plugin ---- Interpreter ---- Version: 2.52 Loading "valley/unigine.cpp" 45ms Loading "valley/locale/unigine.en" dictionary Loading "core/materials/default/unigine_post.mat" 23 materials 50 shaders 5ms Loading "core/materials/default/unigine_render.mat" 47 materials 2368 shaders 11ms Loading "core/materials/default/unigine_mesh.mat" 5 materials 3386 shaders 11ms Loading "core/materials/default/unigine_mesh_lut.mat" 2 materials 1062 shaders 3ms Loading "core/materials/default/unigine_mesh_paint.mat" 2 materials 1158 shaders 5ms Loading "core/materials/default/unigine_mesh_tessellation.mat" 5 materials 3332 shaders 12ms Loading "core/materials/default/unigine_mesh_tessellation_paint.mat" 2 materials 2276 shaders 8ms Loading "core/materials/default/unigine_mesh_triplanar.mat" 1 material 112 shaders 1ms Loading "core/materials/default/unigine_mesh_overlap.mat" 1 material 300 shaders 2ms Loading "core/materials/default/unigine_mesh_terrain.mat" 1 material 813 shaders 4ms Loading "core/materials/default/unigine_mesh_layer.mat" 1 material 84 shaders 1ms Loading "core/materials/default/unigine_mesh_noise.mat" 1 material 106 shaders 2ms Loading "core/materials/default/unigine_mesh_stem.mat" 2 materials 2180 shaders 13ms Loading "core/materials/default/unigine_mesh_wire.mat" 1 material 45 shaders 0ms Loading "core/materials/default/unigine_terrain.mat" 1 material 1980 shaders 8ms Loading "core/materials/default/unigine_grass.mat" 2 materials 474 shaders 4ms Loading "core/materials/default/unigine_particles.mat" 1 material 109 shaders 1ms Loading "core/materials/default/unigine_billboard.mat" 1 material 51 shaders 1ms Loading "core/materials/default/unigine_billboards.mat" 2 materials 840 shaders 4ms Loading "core/materials/default/unigine_volume.mat" 6 materials 53 shaders 4ms Loading "core/materials/default/unigine_gui.mat" 1 material 82 shaders 0ms Loading "core/materials/default/unigine_water.mat" 1 material 533 shaders 19ms Loading "core/materials/default/unigine_sky.mat" 1 material 21 shaders 13ms Loading "core/materials/default/unigine_decal.mat" 1 material 99 shaders 1ms Loading "core/properties/unigine.prop" 2 properties 0ms Unigine Valley Benchmark 1.0 (1.0)Unigine~# world_load valley/valley Loading "valley/valley.cpp" 134ms Loading "valley/valley.mat" 72 materials 1288ms Loading "valley/sound/sound.prop" 142 properties 2ms Loading "valley/valley.world" 2516ms Benchmark running Benchmark results: Time: 189.064 Frames: 4218 FPS: 22.3099 Min FPS: 13.9408 Max FPS: 39.6422 Score: 933.445 Unigine~# quit Close "libopenal.so.1" Close "libGL.so.1" Memory usage: none Allocations: none Shutdown
(In reply to ben@besd.de from comment #20) > 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 ;) You're mixing lots of different concepts. The GLSL compiler supports a number of GLSL versions (as required by the standard). Each version has its own features, and ability to be extended by various extensions. The *driver* supplies a maximum GLSL version that it supports, above which the compiler will just error out. This is all further complicated by compat vs core, in which case some extensions are not made available, and maximum versions are restricted. Using version overrides just messes everything up, of course, so any results with that should be discounted. Lastly remember that piglit also selects compat vs core depending on the GL version you request. This also factors into the various test outcomes. Piglit tests are real GL applications. You're acting like a developer, so please be succinct and precise in what the problem is. You're too focused on solutions.
I honestly dont know what youre talking about. This is basically just fallout from me running captured piglit shaders in shader-db. Shouldn't make a difference, should it? But it does. It seems that shader-db is more strict when it comes to handling shaders and this exposes problems in the shaders piglit is using.
(In reply to ben@besd.de from comment #20) > 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 ;) The decision to use GLSL 4.00 seems to have been made because of the complex interactions of the spec: commit 6f1edf3cbf0ce4cb8e95f2d8bd68c9c26d3f840c Author: Ilia Mirkin <imirkin@alum.mit.edu> Date: Sat Aug 9 20:00:20 2014 -0400 mesa/st: enable ARB_gpu_shader5 if the reported GLSL version >= 400 The ARB_gpu_shader5 extension is made up of a lot of small sub-parts. Instead of adding PIPE_CAP's for each of these, just rely on the GLSL version reported by the pipe driver. The remaining extensions lend themselves naturally to being checked through a single CAP. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(In reply to ben@besd.de from comment #24) > I honestly dont know what youre talking about. > > This is basically just fallout from me running captured piglit shaders in > shader-db. > > Shouldn't make a difference, should it? > > But it does. > It seems that shader-db is more strict when it comes to handling shaders and > this exposes problems in the shaders piglit is using. shader-db shouldn't do anything different. As I tried to explain above if a shader fails to compile then we will end up with a version of 0.00 when dumping. There are multiple reasons why a piglit test might fail compilation, sometimes its even expected and we are explicitly testing a shader will fail to compile under a certain condition. Just because Mesa still dumped the attached shaders doesn't mean they should compile successfully. Another issue could be that the piglit test is broken and never tests for a successful compile as per [1]. Finally test may be relying on an extension being available at a certain GL/GLSL version but don't actually check if the extension is supported. Tests should only do this if the extension was made part of the GL version attempting to be used or a lower version. For ARB_gpu_shader5 that is GLSL 4.00. Each needs to be investigated separately to know for sure what the problem is by I suspect these will all be issues with piglit in one way or another. The only one so far that does look like a mesa bug is the issue described in comment 8 but as I said that piglit test seems to fail so I don't think there is any reason for tracking it in a bug. [1] https://cgit.freedesktop.org/piglit/commit/?id=e60d247eb359f044caf0c09904da14e39d7adca1
Created attachment 138903 [details] [review] last one failing because of mixed version requirements / deprecation gl_FragColor was deprecated in GLSL 130 GL_ARB_GPU_SHADER5 minimum version requirement is GLSL 150 whatever the rationale behind setting GLSL>=400 for allowing shader5 was it seems to be gone now at least for radeonsi maybe there was reason, but it is not a problem any more? maybe it is different for other drivers?
This shader was failing with this error in shader-db: ERROR: shaders/piglit/9507c01b2b65bf17ae8fd442d0dd46aabfc940cd_3.shader_test failed to compile: 0:2(12): error: extension `GL_ARB_gpu_shader5' unsupported in fragment shader
If I understand correctly from Ilias commit above then checking for GLSL = 400 is just a convenience so you dont have to check for every bit that is needed for shader5 could this be written like so ? if driver supports GLSL >= 400 then if user requests GLSL >= 150 then expose GL_ARB_GPU_SHADER5
(In reply to ben@besd.de from comment #29) > If I understand correctly from Ilias commit above then checking for GLSL = > 400 is just a convenience so you dont have to check for every bit that is > needed for shader5 > > could this be written like so ? > > > if driver supports GLSL >= 400 then > if user requests GLSL >= 150 then > expose GL_ARB_GPU_SHADER5 Yes. I believe that is the intention.
ok then, at the moment its like this if driver supports GLSL >= 400 then expose GL_ARB_GPU_SHADER5 how can the if user requests GLSL >= 150 then be added ?
What's the problem again? You're proposing solutions, but I haven't seen a problem description. What's a sequence of GL calls + replies that you feel is done incorrectly? Saying "xyz doesn't work in piglit's shader_runner" could just as well be a bug in the input to shader_runner or an unexpected input into it. If I were you, I'd assume that the current code in mesa regarding exposing extensions is correct and look for problems elsewhere. This bug is filed against piglit... is the supposed issue in piglit somewhere? What's the issue?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/piglit/issues/8.
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.