14871 2011-11-18 01:49:47 +0000 Should there be a feature detect if a shader fails to load 2013-07-04 22:35:32 +0000 1 1 1 Unclassified CSS Filter Effects unspecified PC All RESOLVED FIXED P2 normal --- 1 vhardy dino cmarrin dschulze eoconnor mike public-html-admin public-html-wg-issue-tracking robin smfr public-css-bugzilla oldest_to_newest 60131 0 vhardy 2011-11-18 01:49:47 +0000 See the discussion at: http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0148.html Chris is advocating a feature detection for shaders that do not load and Vincent draws a parallel with JavaScript. Issue not resolved on the thread. 60132 1 vhardy 2011-11-18 01:53:41 +0000 I would like to understand when a shader would actually fail to load because of hw support. I thought that with the strict definitions bounding WebGL shaders, if an implementation supports WebGL shader, it is guaranteed to run (with more or less performance) any conformant shader. In that case, it seems to me that it is the same as for JavaScript. If that is not the case, an example showing how it is different would help me understand. 60166 2 vhardy 2011-11-19 02:27:24 +0000 Discussion on public-fx: (http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0158.html) On Fri, Nov 18, 2011 at 11:27 AM, Chris Marrin <cmarrin@apple.com> wrote: On Nov 18, 2011, at 9:54 AM, Gregg Tavares (wrk) wrote: > WebGL does not say all valid shaders work. WebGL just defines the language, "GLSL". After that it's up to the individual hardware/driver's limits. We've already had to re-write several valid working shaders in the WebGL conformance tests because while they worked fine on desktop hardware they were too large for certain mobile hardware. And so the question is, where did they fail? I assume they failed somewhere in the compile/link cycle, in which case an @supports type of scheme where an alternative can be selected after such failures, would work, right? Yes, the shaders in question failed in the compile/link cycle as they used too many instructions for certain mobile hardware. > > Some example of platform dependent limits: > > *) Max Instructions for a shader. Low-end hardware can be as low as 96 instructions, high end hardware is currently around 32k instructions > *) Max textures you can references in a vertex shader. Low-end limit is 0, high end is 32 > *) Max textures you can reference period. Low-end is 8, high end is 32 > *) Max precision. "highp" is optional > *) ... > > It's also arguably impossible to know how many instructions a given shader will take. Some drivers may optimize better than others. Some WebGL implementations may re-write the shader to work around bugs in drivers. You could choose some even smaller limit like 64 instructions and then hope that was enough wiggle room for workarounds. You could also require higher end hardware with higher limits before allowing CSS shaders to function. Otherwise you probably need a way for devs to check for failure. ----- ~Chris 81772 3 robin 2013-01-21 16:00:38 +0000 Mass move to "HTML WG" 81880 4 robin 2013-01-21 16:03:17 +0000 Mass move to "HTML WG" 81889 5 dschulze 2013-01-21 16:28:50 +0000 (In reply to comment #4) > Mass move to "HTML WG" Please read bug reports before moving. This is unrelated to HTML5. Not even WebGL would be related to HTML5. 81890 6 robin 2013-01-21 16:34:51 +0000 (In reply to comment #5) > (In reply to comment #4) > > Mass move to "HTML WG" > > Please read bug reports before moving. This is unrelated to HTML5. Not even > WebGL would be related to HTML5. Hmmm, sorry about that, but it doesn't look like it came from something I did wrong. I moved all the bugs that were in the "HTML.next" product to "HTML WG" because they are now open for work. That's a perfectly legit move that shouldn't require going through each and every bug. Looking at the paper trail for this bug I see, on 2012-11-08: """ Dirk Schulze <dschulze@adobe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dschulze@adobe.com, | |mike@w3.org, robin@w3.org Component|Filter Effects |default Assignee|dino@apple.com |dave.null@w3.org Product|CSS |HTML.next QA Contact|dave.null@w3.org |public-html-bugzilla@w3.org """ So it looks like *you* gave us this bug, initially :) 81892 7 dschulze 2013-01-21 16:38:50 +0000 (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Mass move to "HTML WG" > > > > Please read bug reports before moving. This is unrelated to HTML5. Not even > > WebGL would be related to HTML5. > > Hmmm, sorry about that, but it doesn't look like it came from something I > did wrong. I moved all the bugs that were in the "HTML.next" product to > "HTML WG" because they are now open for work. That's a perfectly legit move > that shouldn't require going through each and every bug. > > Looking at the paper trail for this bug I see, on 2012-11-08: > > """ > Dirk Schulze <dschulze@adobe.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |dschulze@adobe.com, > | |mike@w3.org, robin@w3.org > Component|Filter Effects |default > Assignee|dino@apple.com |dave.null@w3.org > Product|CSS |HTML.next > QA Contact|dave.null@w3.org |public-html-bugzilla@w3.org > """ > > So it looks like *you* gave us this bug, initially :) Interesting. You are right. Sorry :) 90375 8 dschulze 2013-07-04 22:35:32 +0000 Custom shaders require WebGL support of HW. A failure here is violation WebGL already. Beside that, the @filter rule supports fallback shaders.