[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] shader compilation hangs/crashes
- To: Florian Bösch <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] shader compilation hangs/crashes
- From: Dean Jackson <email@example.com>
- Date: Thu, 7 May 2015 08:07:39 +1000
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; email@example.com; t=1430950063; x=2294863663; h=From:Sender:Reply-To:Subject:Date:Message-Id:To:Cc:Mime-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=T6sqKLDEidCTcThgxSe29h9TmrjA+jW9usjTwPwhkoU=; b=nCL/oiqbQlLwZlmqujh6APqKwXZuDVYyfH7DD+YGzzk2TwdJjCh0oKGKhP1v0b6p 8kx0U+3uwRAkU34hNF7AQXqILdUHfZAxd+g2Kcdf3whwC84CvOQOYODnF4CR5Xpo q/wTXyQV9sFoOMzobws3Snx+SsV4lncSJf6o+iiAmr9SprR+H8NRD/S6PttC2Hvy U2TXmpB5Vws0E0+6AZrG/TYyhu98HIvYKjUi9kBcNheev7e8FH/+KrByI9wCPqeW i5UBoZ6wqXWT/yet0nZT1koNsZw47eTHfehscJ0cwBrFN2rFhOaViflffgrcs47W KA4lPZXfvHKkpEbmeomTxw==;
- In-reply-to: <CAOK8ODgPSQVg3ExU9_yF+W6sr3vQ=ZwL+_mUNU2DMjaiHTCR5A@mail.gmail.com>
- List-archive: <https://www.khronos.org/webgl/public-mailing-list/archives/>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- List-owner: <mailto:firstname.lastname@example.org>
- List-post: <mailto:email@example.com>
- List-subscribe: <mailto:firstname.lastname@example.org?body=subscribe%20public_webgl>
- List-unsubscribe: <mailto:email@example.com?body=unsubscribe%20public_webgl>
- References: <CAOK8ODgPSQVg3ExU9_yF+W6sr3vQ=ZwL+_mUNU2DMjaiHTCR5A@mail.gmail.com>
- Sender: firstname.lastname@example.org
> On 28 Apr 2015, at 4:33 pm, Florian Bösch <email@example.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.
> 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.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: