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

[Public WebGL] shader compilation hangs/crashes

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. 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.