Bug 98132 - #version 300 es compute shaders should not be possible
Summary: #version 300 es compute shaders should not be possible
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
: 98241 (view as bug list)
Depends on:
Blocks: i965-deqp
  Show dependency treegraph
 
Reported: 2016-10-07 00:32 UTC by Kenneth Graunke
Modified: 2019-03-14 08:40 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Kenneth Graunke 2016-10-07 00:32:58 UTC
dEQP-GLES31.functional.debug.negative_coverage.callbacks.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.log.shader.compile_compute_shader

expect #version 300 es compute shaders to fail to compile.  presumably compute shaders only work with #version 310 es.
Comment 1 Tapani Pälli 2016-10-14 03:50:35 UTC
*** Bug 98241 has been marked as a duplicate of this bug. ***
Comment 2 Iago Toral 2016-10-14 12:36:31 UTC
I have sent a couple of patches for review that fix these tests:

https://lists.freedesktop.org/archives/mesa-dev/2016-October/131942.html
https://lists.freedesktop.org/archives/mesa-dev/2016-October/131943.html
Comment 3 Iago Toral 2016-10-18 12:24:59 UTC
(In reply to Iago Toral from comment #2)
> I have sent a couple of patches for review that fix these tests:
> 
> https://lists.freedesktop.org/archives/mesa-dev/2016-October/131942.html

This patch has been reviewed and merged. It fixes the problem with the GLSL version.

> https://lists.freedesktop.org/archives/mesa-dev/2016-October/131943.html

This second patch addressed a different subcase of the same tests, related to unsized arrays in SSBOs.

The original patch I sent for this subcase fixed the tests but it had some issues that I describe in my reply to it in the mailing list. I have sent a new version of the patch that should be correct:

https://lists.freedesktop.org/archives/mesa-dev/2016-October/132359.html

But this patch won't fix the dEQP tests, because for the reasons I explain in the patch, I think this dEQP subcase is bogus.
Comment 4 Iago Toral 2016-10-20 06:31:17 UTC
(In reply to Iago Toral from comment #3)
> (In reply to Iago Toral from comment #2)
> > I have sent a couple of patches for review that fix these tests:
> > 
> > https://lists.freedesktop.org/archives/mesa-dev/2016-October/131942.html
> 
> This patch has been reviewed and merged. It fixes the problem with the GLSL
> version.
> 
> > https://lists.freedesktop.org/archives/mesa-dev/2016-October/131943.html
> 
> This second patch addressed a different subcase of the same tests, related
> to unsized arrays in SSBOs.
> 
> The original patch I sent for this subcase fixed the tests but it had some
> issues that I describe in my reply to it in the mailing list. I have sent a
> new version of the patch that should be correct:
> 
> https://lists.freedesktop.org/archives/mesa-dev/2016-October/132359.html
> 
> But this patch won't fix the dEQP tests, because for the reasons I explain
> in the patch, I think this dEQP subcase is bogus.

This second patch is now in master. As mentioned, the dEQP tests still fail, but I think they fail for wrong reasons, so I think we might want to resolve this as INVALID now.
Comment 5 Tapani Pälli 2017-04-27 10:32:16 UTC
commit 5bc222ebafddd14f2329f5096287b51d798a6431
Author: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Date:   Fri Feb 10 14:25:27 2017 +0100

    glsl: non-last member unsized array on SSBO must fail compilation on GLSL ES 3.1
    
    From GLSL ES 3.10 spec, section 4.1.9 "Arrays":
    
    "If an array is declared as the last member of a shader storage block
     and the size is not specified at compile-time, it is sized at run-time.
     In all other cases, arrays are sized only at compile-time."
    
    In desktop GLSL it is allowed to have unsized-arrays that are
    not last, as long as we can determine that they are implicitly
    sized, which is detected at link-time.
    
    With this patch Mesa reports a compilation error as glslang does with
    the following shader:
    
    buffer SSBO { vec4 data[]; vec4 moreData;};
    void main (void)
    {
    }
    
    Fixes:
    dEQP-GLES31.functional.debug.negative_coverage.log.shader.compile_compute_shader
    dEQP-GLES31.functional.debug.negative_coverage.callbacks.shader.compile_compute_shader
    dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.compile_compute_shader
    
    Cc: "17.0" <mesa-stable@lists.freedesktop.org>
    Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>


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.