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

Issue 873077 link

Starred by 1 user
Status: Duplicate
Merged: issue 849576
Owner:
█ kbr@chromium.org
OOO until 2019-01-24
Closed: Aug 10
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Shader Async compilation: inconsistent results

Reported by p...@sketchfab.com, Aug 10 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.84 Safari/537.36

Steps to reproduce the problem:
1. visit https://sketchfab.com/models/f31b2477e50f4fe284d80ea136c94d8e?async_shader=3 and profile until the model is loaded 
2. check profile results
3. see that one call "checkFramebufferStatus" takes 500ms where it doesnt without async shader (?async_shader=0 or no url options)

Using more frames between compilation and link is possible with https://sketchfab.com/models/f31b2477e50f4fe284d80ea136c94d8e?async_shader=15 it wait 15 frames for instances

What is the expected behavior?
we should get the "hotspot" on profiler at gl compilation/link commands, not afterwards (sometimes in texmage2D sometimes in checkframebufferstatus )

What went wrong?
We get hotspot at other place making it hard to know when we will be able to avoid the "freeze"

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 68.0.3440.84  Channel: n/a
OS Version: 10.0
Flash Version: 

hopefully https://bugs.chromium.org/p/chromium/issues/detail?id=849576#c19 solves it, but it may also appears in the new code so posting the bug.

Comment 1 by kbr@chromium.org, Aug 10

Mergedinto: 849576
Owner: kbr@chromium.org
Status: Duplicate (was: Unconfirmed)
Even without the KHR_parallel_shader_compile extension, Chromium attempts to allow shader compilation and program linking to run in parallel with other OpenGL (in this case, WebGL) command submission.

However, *any* synchronous WebGL API call – including checkFramebufferStatus – will currently end up waiting for those shader compiles or program links to complete, since they came earlier in the command stream, and didn't truly run asynchronously.

In order to fully take advantage of the current pseudo-asynchronous mechanism you must issue all of your shader compilations and program links as early as possible, and wait until as late as possible to query the status of those programs, or use them. You also need to avoid all synchronous API calls in between.

This is why KHR_parallel_shader_compile will help so much. We're trying to get this in place ASAP. Duplicating this into the bug for enabling that extension.

P.S. I ran profiles of your test on both Mac and Windows and even without the async_shader URL parameter, getOrCreateProgram is still immediately querying the link result, taking 500 ms per program. See attached profile. You should avoid immediately querying compilation or link results.
Profile-20180810T135023-no-async-shaders.zip
3.7 MB Download
►

Sign in to add a comment