[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] shader compilation hangs/crashes



A recent issue I hit on Linux: https://code.google.com/p/chromium/issues/detail?id=477306 https://bugzilla.mozilla.org/show_bug.cgi?id=1154688

Conformance test I filed because it made a lot of problems on Windows at the time: http://codeflow.org/issues/unroll-problem/ https://github.com/KhronosGroup/WebGL/blob/master/sdk/tests/conformance/glsl/misc/large-loop-compile.html

This morning browsing the new section of shadertoy (https://www.shadertoy.com/results?query=&sort=newest&filter=) on page 3 (https://www.shadertoy.com/results?query=&sort=newest&from=36&num=12) the first shader (https://www.shadertoy.com/view/4tBGzc) crashes the GPU process in chrome on OSX (next page load is "rats ..." bar). It crashes Firefox instantly, and in Safari it does a "a problem occured to this page was reloaded", it reloads it a few times and then DOS the whole of OSX for about half a minute while beechball of death and then safari crashes completely.

It took me around 5 minutes of idle browsing on shadertoy to find a cross-browser crash/hang/beachball of death shader for an OS of choice.

On Thu, May 7, 2015 at 12:07 AM, Dean Jackson <dino@apple.com> wrote:

> On 28 Apr 2015, at 4:33 pm, Florian Bösch <pyalot@gmail.com> wrote:
>
> For various reasons (ANGLE, drivers, etc.) it's possible to:
>
> - crash firefox
> - hang chrome (with an eventual GPU process crash)
>
> I'm sure other UAs are affected as well. I and others have observed this phenomenon on any OS, and it's nothing that's isolated.
>
> I have personally filed tickets (and even a conformance test) towards this issue.

Can you provide links to the bugs you've filed? I'd at least like to try to make sure WebKit either doesn't crash or we have a plan to avoid it. I agree that being able to crash a browser while compiling a shader is bad.

Dean


> Many others have also filed tickets. Some of these tickets are of substantial age. Some pages (such as shadertoy, for reasons I get to shortly) has become the butt of a joke in some online communities (such as r/graphicsprogramming).
>
> I can understand if a shader fails to compile. I can understand if a shader, once compiled will run incredibly slow. What I cannot understand is that simply compiling a shader should hang/crash the software attempting to compile it.
>
> Shadertoy is a particular victim of this effect. This is because they're blasting up to 10 canvases each compiling a shader somebody submitted to their site at the UA. The likelyhood of encountering a UA busting shader on shadertoy is very high. You usually don't have to navigate very many overview pages to meet one for your platform.
>
> Shadertoys author is categorically refusing to do any of these things:
>
> - limit pages to one shader at a time
> - track which shaders provoke issues
> - inform shader authors about issues with their shaders
>
> Which is his prerogative. I personally don't agree with that stance, but it is a fairly valid stance to take, that UA should fix something which is obviously broken (see hangs/crashes).
>
> This has been a long-running issue, documented in many tickets. It's also become the main topic of debate whenever shadertoy pops up in a social media site somewhere. This is harmful to WebGL.
>
> For whatever reasons UAs think it's not their mission to fix a broken shader compilation pipeline, that is a sadly mistaken point of view. The bucket stops at UAs unfortunately. It's not possible to get all GPU drivers fixed right this day, even if GPU vendors could be bothered to introduce these fixes.
>
> The practice of ignoring this issue is self-defeating and just serves to cast popular WebGL pages in a bad light, and it casts WebGL as a whole in a bad light. It's a disservice to the work UA WebGL implementor teams do, because it cheapens the fruits of their labor. I'd implore every UA to take a long hard look at this issue and put it on top of their priority list to make sure their software is well behaved even with input they consider unreasonable.