Bug 106052

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.