Kimmo, do you think you could triage this?

Thanks for filing the issue...

Tried to reproduce the issue on reported chrome version 71.0.3578.98 using Ubuntu 17.10 and Windows 10. Attaching screen-cast for reference.
Steps: 
------
1. Launched reported chrome 
2. Navigated the URL "https://www.shadertoy.com/view/3slGWS"
3. Ran the code as per attached screen-cast 
As we have observed that the fps is max 13.14

@Reporter: Could you please check the attached screencast and let us know if we missed anything from our end and if possible provide screencast for better understanding of the issue.

Thanks.!

Deleted: 922029.webm 3.1 MB

	922029.webm 3.1 MB View Download

Thanks, but sorry, you didn't tested anything.
-> I rewrap below in more step by step details.

- prerequisite:  
    - nVidia GPU
    - recent drivers ( >= 396.54 )
    - either linux or trueOpenGL mode in windows.

- perfs measurements:
  - better if you let fps stabilize.
  - if too fast ( > 30fps ), edit the code to lengthen the loop + the unrolled version by a factor (2 or 4 or 8 if powerfull GPU). But seems ok as is for your GPU.


- bench set up:

  - line 17: #if triggers either the loop (case 1, default) or the explicit unrolling. lenghts are different on purpose (same cost on my machines).
    -> you will have to edit the code to try #if 1 and #if 0

  - line 25: outputting the result in fragColor (default) or commenting this line so as almost all code becomes dead code. 
    ->  you will have to edit the code for having the line either active or commented.


- showing the bug:   
  watch the perfs in the 4 combinations below:

  - default case ( line 17: #if 1  line 25: active )
     ~ 5-13fps in your case (would be better to stabilize, but clearly slow).

  - comment line 25:  the fps should jump to ~maxfps (deadcode eliminated)

  - restore line 25, + set #if 0 line 17.( now testing explicit unroll ).
    First anomaly: 30 explicit call of T cost ~as much as a loop of 800.

  - comment line 25:  the fps keeps low (almost not changing), despite the compiled code should be near empty: deadcode has not been detected.
Which is a serious regression, and optimization now probably bad in various cases.

thanks,

Thanks for the report.
Yeah, the performance difference can be observed with Windows 416.34, GTX 1080. GPU utilization of 85% vs 100%. FPS does not saturate for me.

Likely this is not a Chromium issue, so probably it's not fully ok to assess this further here. There's no action for Chromium, so maybe it's better to close this one.

I moved the discussion to our public "bug tracker" at:
https://devtalk.nvidia.com/default/topic/1046314/opengl/bug-report-glsl-perf-dead-code-unrecognized-unrolled-code-25-times-more-costly-than-loop/

If I manage to create a non-browser repro and if that does not repro the problem, then we should revisit investigating this in WebGL/Chromium context.

Usually there was an nVidia guy ( used to be Olli ) that either treat it directly or forward the bug report to an internal place at nVidia ( or Angle or else ).
Many bugs have been corrected that way.

One of the great thing here is that there are several key people from related community that can handle things through better place.

Note sure closing it so soon is good for that management to occurs.

Yeah, I'll can treat it directly and forward the bug report to our internal tracker.
I just closed this one as it does not seem to be polite to use Chromium bug tracker as NV public bug tracker -- for me personally this is fine too. I'll let kbr@ deal with the closing :)

 I'd imagine logic wrt keeping a particular bug open here would be if there's 
a) a chromium workaround in the works 
b) the particular driver bug would block chromium test functionality, and such tracking the driver fix would result in Chromium related actions, such as enabling of the tests in Chromium.

I just wanted to be sure it would not end up sunk in the sands.
-> If you handle it, this is perfect ! (thanks !)

NB: this one bug seems to be a pure NV driver bug that probably must be tackled quickly at this level, but previous ones happened to be either more mix or easier to be tackled by Angle rewriting rules at short-mid term. 
More generally, webGL bugs are a mix of many levels not always easy to sort-out at first, or that might be turned-around at Angle level. So I guess it's not bad to at least keep the possibility to put here bug reports that are probably NV related, even if they can be triagged out to NV by you soon later ;-) .

thanks,