linkProgram performance
Patrick Cozzi
I have a complex fragment shader that takes ~5,300 ms to link in WebGL
(on Linux and Windows without ANGLE). In desktop OpenGL, the whole
program compiles and links almost instantaneously.
By commenting out parts of the shader, it looks like functions with
loops in them create quite a compile/link performance hit. Some
functions have nested for loops with four iterations. I found similar
performance both with and without shader validation in Chrome,
assuming "--disable-glsl-translator --use-gl=desktop" is still valid
in 18.0.1. Is all this time spent in loop unrolling?
Can anyone share insights and best practices for minimizing WebGL
compile/link times? Obviously, use loops sparingly, but that is
rather unfortunate as we push the boundaries of 3D on the web.
Regards,
Patrick
Benoit Jacob
Firefox currently doesn't ask the ANGLE compiler to unroll loops.
Benoit
2012/2/3 Patrick Cozzi <pjcoz...@gmail.com>:
Kenneth Russell
the shader validator that needs to be fixed. Could you please provide
a complete, self-contained test case and file a bug on
http://crbug.com/ ? Please send me the bug ID and I'll make sure it
gets routed.
For the record, I don't believe Chromium is currently unrolling loops
in the shader translator. That functionality was implemented as a
workaround for driver bugs, but I can't find evidence that it's turned
on. The shader translator does however enforce the WebGL spec's
limitations on loop structure, and there may be a performance bug
there.
-Ken
Zhenyao Mo
condition is met. Apparently that's not your case.
I'd love to see and fix this performance issue if you can provide a test case.
Mo
Patrick Cozzi
Ken has the test case.
> Can you reproduce this on Firefox?
> Firefox currently doesn't ask the ANGLE compiler to unroll loops.
you the test case and/or submit a bug? Perhaps this is actually a
driver issues; we'll seen it on many different NVIDIA cards, but
haven't tested others.
With WebGL, I'm not quite sure what the browser does vs. what the
driver does. I would be really interested in learning about what the
browser does when we call linkProgram before it goes to the driver/
ANGLE. Just validation?
Regards,
Patrick
On Feb 6, 7:26 pm, Zhenyao Mo <z...@google.com> wrote:
> Ken's right. We only unroll for-loops on Mac when a very specific
> condition is met. Apparently that's not your case.
>
> I'd love to see and fix this performance issue if you can provide a test case.
>
> Mo
>
>
>
>
>
>
>
> On Mon, Feb 6, 2012 at 1:34 PM, Kenneth Russell <k...@chromium.org> wrote:
> > This sounds simply like a bug, or at least a performance problem in
> > the shader validator that needs to be fixed. Could you please provide
> > a complete, self-contained test case and file a bug on
>
> > For the record, I don't believe Chromium is currently unrolling loops
> > in the shader translator. That functionality was implemented as a
> > workaround for driver bugs, but I can't find evidence that it's turned
> > on. The shader translator does however enforce the WebGL spec's
> > limitations on loop structure, and there may be a performance bug
> > there.
>
> > -Ken
>
> >> Can you reproduce this on Firefox?
>
> >> Firefox currently doesn't ask the ANGLE compiler to unroll loops.
>
> >> Benoit
>
Benoit Jacob
> Thanks for the info. I submitted http://code.google.com/p/chromium/issues/detail?id=113009.
> Ken has the test case.
>
>> Can you reproduce this on Firefox?
>> Firefox currently doesn't ask the ANGLE compiler to unroll loops.
>
> Benoit, I see the same behavior on Firefox. Do you want me to send
> you the test case and/or submit a bug?
Please do file a bug with a test case, and we'll CC our NVIDIA
contacts on it as it does seem like a possible driver bug.
> Perhaps this is actually a
> driver issues; we'll seen it on many different NVIDIA cards, but
> haven't tested others.
>
> With WebGL, I'm not quite sure what the browser does vs. what the
> driver does. I would be really interested in learning about what the
> browser does when we call linkProgram before it goes to the driver/
> ANGLE. Just validation?
The WebGL implementation of linkProgram does really not much more than
call glLinkProgram (and then, query some status.
The WebGL implementation does all the shader validation in the
implementation of compileShader. This is where the ANGLE shader
compiler is used to validate the input.
What typically happens is that the underlying graphics system (D3D or
OpenGL) will delay the actual shader compilation until the time
glLinkProgram is called. So if you're seeing glLinkProgram take
inordinately long, it's quite plausible that it's the GL doing delayed
shader compilation there.
The fact that you're seeing this on both Linux and Windows rules out
the hypothesis of a Direct3D bug, so I'm leaning for a NVIDIA bug.
Cheers,
Benoit
Gregg Tavares (勤)
Kenneth Russell
I've confirmed that the problem is reproducible in Chromium on Linux
and goes away if the ANGLE shader translator is sidestepped, so it's
clearly a performance bug in ANGLE. We'll continue to investigate.
-Ken
Benoit Jacob
Patrick said the bug also happened in Firefox, which uses the ANGLE
compiler immediately in compileShader, so at least in Firefox the
slowness of linkProgram can't be explained by ANGLE? Unless perhaps
the problem is in the GLSL (non-ES) code generated by the ANGLE
compiler?
Benoit
2012/2/7 Kenneth Russell <k...@chromium.org>:
Kenneth Russell
figure out where the time is going.
The best hypothesis I have is that renaming of long variables might be
causing hash collisions in the underlying GLSL compiler.
-Ken
Benoit Jacob
> It's certainly mysterious. I'm instrumenting the code right now to
> figure out where the time is going.
>
> The best hypothesis I have is that renaming of long variables might be
> causing hash collisions in the underlying GLSL compiler.
Firefox is not yet doing long variables renaming, yet Patrick says
that the bug also occurs in Firefox.
Benoit
Patrick Cozzi
I submitted a Firefox issue, https://bugzilla.mozilla.org/show_bug.cgi?id=725467.
However, I am not convinced that this is a browser issue. On Firefox
10 without ANGLE, linkProgram took ~5,900 ms in one test case.
However, if I refresh the page or even close and reopen the browser,
linkProgram takes 34 ms. I assume the driver caches the shader
because if I change the source, linkProgram takes a while again. I
have also had the video driver reset once. On Firefox with ANGLE, the
tab hangs when calling linkProgram. I recognize that this is not the
simplest shader in the world, and may very well exceed some limitation
that I am not aware of.
Ken and Benoit, thanks for your attention and interest; beers are on
me at SIGGRAPH.
Patrick
On Feb 7, 3:36 pm, Benoit Jacob <jacob.benoi...@gmail.com> wrote:
> 2012/2/7 Kenneth Russell <k...@chromium.org>:
>
> > It's certainly mysterious. I'm instrumenting the code right now to
> > figure out where the time is going.
>
> > The best hypothesis I have is that renaming of long variables might be
> > causing hash collisions in the underlying GLSL compiler.
>
> Firefox is not yet doing long variables renaming, yet Patrick says
> that the bug also occurs in Firefox.
>
> Benoit
>
>
>
>
>
>
>
>
>
> > -Ken
>
> >> Ken, how can a ANGLE compiler bug affect linkProgram performance?
> >> Patrick said the bug also happened in Firefox, which uses the ANGLE
> >> compiler immediately in compileShader, so at least in Firefox the
> >> slowness of linkProgram can't be explained by ANGLE? Unless perhaps
> >> the problem is in the GLSL (non-ES) code generated by the ANGLE
> >> compiler?
>
> >> Benoit
>
> >> 2012/2/7 Kenneth Russell <k...@chromium.org>:
> >>>> 2012/2/7 Patrick Cozzi <pjcozzi...@gmail.com>:
> >>>>> Thanks for the info. I submittedhttp://code.google.com/p/chromium/issues/detail?id=113009.
Roy Williams
As a New Year's resolution, I'll be trying out empty inbox for the next month. I will only be checking email in the morning, after lunch, and before I leave. If you need me sooner than that, IM or call.