This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
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
Mass move to "HTML WG"
(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.
(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 :)
(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 :)
Custom shaders require WebGL support of HW. A failure here is violation WebGL already. Beside that, the @filter rule supports fallback shaders.