Use GLSL version 100 for OpenGL context versions prior to 3.2.

Use GLSL version 100 for OpenGL context versions prior to 3.2.

Using #version 130 for OpenGL 3.0 contexts was causing problems with
sampler arrays in loops on Intel's drivers.

BUG=550487
Committed: https://crrev.com/e202d8cf21883ff9fb52ebf48a85cbb9cfa7d5d1
Cr-Commit-Position: refs/heads/master@{#366539}

[Ken Russell (switch to Gerrit), 2015-12-18 00:09:02]

kbr@chromium.org changed reviewers:
+ piman@chromium.org, zmo@chromium.org

[Ken Russell (switch to Gerrit), 2015-12-18 00:09:02]

Mo, Antoine: please review. Thanks.

Others: FYI.

[piman, 2015-12-18 06:39:14]

LGTM, but, are we losing anything? Should we consider making this a
driver-specific workaround?

[Kimmo Kinnunen, 2015-12-18 07:03:22]

kkinnunen@nvidia.com changed reviewers:
+ kkinnunen@nvidia.com

[Kimmo Kinnunen, 2015-12-18 07:03:23]

https://codereview.chromium.org/1540483002/diff/1/gpu/command_buffer/service/...
File gpu/command_buffer/service/shader_translator.cc (left):

https://codereview.chromium.org/1540483002/diff/1/gpu/command_buffer/service/...
gpu/command_buffer/service/shader_translator.cc:143: return
SH_GLSL_150_CORE_OUTPUT;
Would version 150 also have the same problem?

https://www.opengl.org/registry/doc/GLSLangSpec.1.50.11.pdf still has that "can
only be indexed with integral constant expressions"...

https://codereview.chromium.org/1540483002/diff/1/gpu/command_buffer/service/...
File gpu/command_buffer/service/shader_translator.cc (right):

https://codereview.chromium.org/1540483002/diff/1/gpu/command_buffer/service/...
gpu/command_buffer/service/shader_translator.cc:148: // in loops, which causes
problems like crbug.com/550487 .
Just verifying: so not using 130-150 would be a workaround for ANGLE not being
able to translate WebGL SL to GLSL version 130-150? Or fundamental issue that
WebGL SL can not be supported with 130-150?

[Ken Russell (switch to Gerrit), 2015-12-22 02:45:18]

https://codereview.chromium.org/1540483002/diff/1/gpu/command_buffer/service/...
File gpu/command_buffer/service/shader_translator.cc (left):

https://codereview.chromium.org/1540483002/diff/1/gpu/command_buffer/service/...
gpu/command_buffer/service/shader_translator.cc:143: return
SH_GLSL_150_CORE_OUTPUT;
On 2015/12/18 07:03:23, Kimmo Kinnunen wrote:
> Would version 150 also have the same problem?
> 
> https://www.opengl.org/registry/doc/GLSLangSpec.1.50.11.pdf still has that
"can
> only be indexed with integral constant expressions"...

Looking more deeply, yes, it looks like this restriction wasn't lifted until
OpenGL 4.0. However, for some reason, it's only Intel's driver that seems to
enforce it. Both NVIDIA's and AMD's drivers compile these sampler array indexing
expressions without complaint. I'm not sure whether that's because they are
using the compatibility profile, which didn't exist until OpenGL 3.2. Intel's
drivers on Linux seem to default to using OpenGL 3.0 at the latest.

https://codereview.chromium.org/1540483002/diff/1/gpu/command_buffer/service/...
File gpu/command_buffer/service/shader_translator.cc (right):

https://codereview.chromium.org/1540483002/diff/1/gpu/command_buffer/service/...
gpu/command_buffer/service/shader_translator.cc:148: // in loops, which causes
problems like crbug.com/550487 .
On 2015/12/18 07:03:23, Kimmo Kinnunen wrote:
> Just verifying: so not using 130-150 would be a workaround for ANGLE not being
> able to translate WebGL SL to GLSL version 130-150? Or fundamental issue that
> WebGL SL can not be supported with 130-150?

OpenGL ES 2.0 / WebGL 1.0 require sampler arrays to be indexable with a
constant-index-expression, which strictly speaking isn't supported by the
desktop OpenGL shading language between versions 130 and 330, inclusive. It's a
fundamental problem with the OpenGL shading language spec, but for some reason,
only some drivers enforce it.

[Ken Russell (switch to Gerrit), 2015-12-22 02:48:39]

On 2015/12/18 06:39:14, piman (OOO until 2016-1-4) wrote:
> LGTM, but, are we losing anything? Should we consider making this a
> driver-specific workaround?

Nothing's being lost with this change. Neither core Chrome nor WebGL 1.0 require
any language features that might have been introduced in these GLSL versions.

We may have to characterize this behavior more carefully though going forward,
especially with ES 3.0 / WebGL 2.0. I don't understand why the behavior is
Intel-specific. Until we understand it better I'd rather not add a workaround
whose logic might be incorrect.

[Ken Russell (switch to Gerrit), 2015-12-22 02:48:44]

The CQ bit was checked by kbr@chromium.org

[commit-bot: I haz the power, 2015-12-22 02:49:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1540483002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1540483002/1

[commit-bot: I haz the power, 2015-12-22 03:55:50]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-12-22 03:57:18]

Description was changed from

==========
Use GLSL version 100 for OpenGL context versions prior to 3.2.

Using #version 130 for OpenGL 3.0 contexts was causing problems with
sampler arrays in loops on Intel's drivers.

BUG=550487
==========

to

==========
Use GLSL version 100 for OpenGL context versions prior to 3.2.

Using #version 130 for OpenGL 3.0 contexts was causing problems with
sampler arrays in loops on Intel's drivers.

BUG=550487

Committed: https://crrev.com/e202d8cf21883ff9fb52ebf48a85cbb9cfa7d5d1
Cr-Commit-Position: refs/heads/master@{#366539}
==========

[commit-bot: I haz the power, 2015-12-22 03:57:19]

Patchset 1 (id:??) landed as
https://crrev.com/e202d8cf21883ff9fb52ebf48a85cbb9cfa7d5d1
Cr-Commit-Position: refs/heads/master@{#366539}