Unable to reproduce this issue on Ubuntu 14.04 with reported version 61.0.3163.100 and latest dev 63.0.3238.0 with steps mentioned below.

1.Naviagted to https://www.shadertoy.com/view/4sBBWy and uncommented lines #77 and #78.
2.Hit compile button and observed nothing.

@Reporter: Could you check the above steps and let us know if we are missing anything. And could you please attach a screencast of what is expected. This would help us in further triaging of this issue.

Thanks!

now in my lab, on dektop ubuntu 16.04, chrome version Version 58.0.3029.81 (64-bit), nvidia GeForce GTX 760/PCIe/SSE2.

- uncommenting both lines #77 and #78 : subtab "Image" get red, and if you scroll up you see image err1 below.

- uncommenting only line #77: browser tab freeze for 40 seconds,  then subtab "Image" get red, and if you scroll up you see image err2 below (indeed, ultralong compilation report including arb sources).

Deleted: err2.png 55.6 KB

	err2.png 55.6 KB View Download

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

err1 is there: 

Deleted: err1.png 40.5 KB

	err1.png 40.5 KB View Download

Thanks for providing the feedback!!

Checked the issue on reported version 61.0.3163.100 and 63.0.3238.0 using Ubuntu 14.04, Mesa driver and unable to reproduce issue with steps mentioned in comment#4. Attaching screencast of same.

This might be specific to vidia GeForce GTX 760/PCIe/SSE2. As ET Team don't have that setup could some one from Inhouse take a look into this. 

Thank you!! 

Deleted: ISsue 762659.ogv 4.4 MB

	ISsue 762659.ogv 4.4 MB View Download

- The bug also shows on my laptop ( ubuntu 14.04 / Quadro K2100M/PCIe/SSE2 )
- The bug also shows on firefox / linux
- The bug also shows on a windows PC in OpenGL mode
...

TE-doesn't have a linux machine with nvidia GeForce GTX 760/PCIe/SSE2, adding TE-NeedsTriageFromMTV for further triage.

I'll try reproducing here.

I can reproduce the compilation error on a machine with this NVIDIA GPU and driver:

GL_VENDOR	NVIDIA Corporation
GL_RENDERER	Quadro M2000/PCIe/SSE2
GL_VERSION	4.5.0 NVIDIA 381.22

Submitter, you're surely running into hardware limitations. The compilation failure is coming from NVIDIA's driver. You need to feed large amounts of constant data like that into your shader in a different way, for example as a texture.

CC'ing Olli Etuaho from NVIDIA as a heads up, but I doubt there is anything that can be done about this. Marking ExternalDependency.

kbr, did you read the explanations ?
- The main point is that if data are fetched several times (e.g. 8, for trilinear interpolation), openGL compilation into arb reach the resource limit 8 times sooner than the Angle/HLSL compiler due to silly registers allocations.
- And for values close to the limit, the compiler hang for minutes.
- Of course one can use textures in this example ! Making acid tests to easily underline bugs purposely make strange looking code. Anyway, many real applications do needs arrays, and OpenGL-side world is limited by many folds compare to HSLS-side world due to this bug: it's like having a poor GPU, local-memory wise !

Thanks to CC'ing Olli Etuaho.

fabrice.neyret@: I read your explanations. The browser is (or should be) doing very few transformations to the shader on the way to the driver's GLSL compiler. Certainly it does no loop unrolling or other optimizations, and no translation to ARB assembly language is being done by the browser. The compilation errors you're seeing are coming directly from the driver, and I suspect are not something that can be worked around in the browser.

If you convert your ShaderToy example to a standalone HTML example which loads the vertex and fragment shaders from source and which uses the WEBGL_debug_shaders extension to dump the translated sources, and it looks like transformations done by the browser are the cause of the compilation failure, we can look into this further.

It seems like the NVIDIA GLSL compiler produces suboptimal code from this shader, and I'll take the bug to be investigated.

There's no issue in ANGLE.

@Olli Etuaho : thanks a lot !

@kbr: I'm not telling it's browser's fault. But for all these webGL bugs it's very tricky to sort who's fault in the stack browser/angle/OS/driver/GPU/API . I was advised to report them here since the community is pretty smart and trans-projects, and it prove a very good idea for the series of "GLSL bugs" I reported here recently. Several have been rerouted to Angle, HLSL, nvidia; one was due to a GLSL patch activated on chrome and not on firefox. etc. So the "forward to Olli" fate is a perfect solution, within the expected. ;-)

@Olli Etuaho : maybe there is something specific to this bug, but it might be something more general: the optimisation rules not accounting for resources: on shadertoy some big shaders require a dozen of second to compile, or minute, or fail, with OpenGL. As if the "unroll everything / map arrays several times", which is a good strategy with infinite resources, didnot checked that the result could run on the board. Or it might also be a timeout issue.

Thanks for the report.
The arrays larger than 1024, smaller than 4094 causing compilation failure has been worked in NV internal bug 2008435.
Currently newest public drivers should fix this particular problem. I've verified this on Windows 416.34.
Note: The above only verifies arrays of size 0..4094.

My repro verification steps: copy-paste the existing 1023 sized array elements few times.


Pending problems:
Arrays of size 4095-~4099 compile for a long time and then fail with unexpected error message. I'll try to file this internally.

Arrays of size >=4100 compile fast and fail with an error message that seems sort of reasonable if you know the implementation path (does break the WebGL abstraction, though).

On same drivers, D3D11 path works up to 4096 elements, so to achieve WebGL abstraction, it'd be nice to support the same value.