New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 604357 link

Starred by 2 users
Status: WontFix
Owner:
█ martina....@intel.com
Last visit > 30 days ago
Closed: Jan 2017
Cc:
█ kbr@chromium.org
cwallez@chromium.org
█ qiankun....@intel.com
bajones@chromium.org
█ dongseong.hwang@chromium.org
yunchao...@intel.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug

Blocking:
issue 347163



Sign in to add a comment

WebGL conformance test glsl_misc_shaders_with_varyings fails on Intel GPU

Project Member Reported by martina....@intel.com, Apr 18 2016 
You can reproduce this with:
chromium-browser ./third_party/webgl/src/sdk/tests/conformance/glsl/misc/shaders-with-varyings.html

This failure is a regression, the test succeeds on my packaged version 48.0.2564.82, but fails on the dev build. I suspect this is because in the older version, the line "#version 130" is added to the shader and therefore there is no error - Mesa considers this an error only on shaders older than 120.

This test has been disabled in https://codereview.chromium.org/1581693003 in an attempt to get the Intel GPU test bot working, together with many others.

Mesa is correct to make it an error in GLSL older than 1.20 to make this an error, see https://cgit.freedesktop.org/mesa/mesa/commit/?id=16b53005a7df4249fecb6641af0934c32181fdea

However, one thing is confusing me - I thought WebGL used GLSL ES? For GLSL ES, this should be only a warning in Mesa, not an error - as you can see in the above patch (I checked this in the newest Mesa master and it still holds true).

Comment 1 by kbr@chromium.org, Apr 18 2016

Cc: cwallez@chromium.org
Components: Blink>WebGL
Owner: martina....@intel.com
Status: Assigned (was: Untriaged)
On desktop platforms Chrome's WebGL implementation uses an OpenGL context, not an OpenGL ES context. If you can submit a patch for this (probably to ANGLE's shader translator, or the code in the command buffer which initializes it) we'll be happy to integrate it to enable more tests on our Linux Intel bots.

Comment 2 by martina....@intel.com, Apr 19 2016 

Problem is, the "#version 130" was removed for OpenGL 3.0 (which I have) here:

https://codereview.chromium.org/1540483002/

So in short, for Mesa and OpenGL 3.0, if you try to use GLSL 1.30, you will get the error in  issue #569907 , if you don't use 1.30, you will get this issue. So how to resolve the conflict?

Comment 3 by kbr@chromium.org, Apr 19 2016 

This sounds like an insoluble problem.

If some later version of OpenGL mandates support for dynamic indexing of sampler arrays, then we could change Chrome's code to request or require that version.

Comment 4 by martina....@intel.com, Apr 25 2016 

It could theoretically be solved by using GLSL 120, but angle doesn't seem to support it (in third_party/angle/include/GLSLANG/ShaderLang.h, ShShaderOutput, SH_GLSL_120_OUTPUT isn't present).

Comment 5 by cwallez@chromium.org, Apr 25 2016 

I don't get any failure when opening https://www.khronos.org/registry/webgl/sdk/tests/conformance/misc/shader-precision-format.html
Using top of tree Chromium on Mesa 11.2 Broadwell, with our without ANGLE.

Comment 6 by kbr@chromium.org, Jan 13 2017

Cc: yunchao...@intel.com qiankun....@intel.com
Status: WontFix (was: Assigned)
I don't think this is reproducible on current hardware and drivers.
►

Sign in to add a comment