Summary: | #version 300 es compute shaders should not be possible | ||
---|---|---|---|
Product: | Mesa | Reporter: | Kenneth Graunke <kenneth> |
Component: | glsl-compiler | Assignee: | mesa-dev |
Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | itoral, randy.xu |
Version: | git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 94448 |
Description
Kenneth Graunke
2016-10-07 00:32:58 UTC
*** Bug 98241 has been marked as a duplicate of this bug. *** 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 (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. (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. 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.