[Public WebGL] WEBGL_debug_shader_precision extension proposal

Kenneth Russell [email protected]
Wed Nov 19 14:31:43 PST 2014

It looks like it's feasible to compile ANGLE's shader translator with
Emscripten. https://code.google.com/p/angleproject/wiki/CompilingTranslatorWithEmscripten
describes how to get it working.

Given this, it looks like the best way forward is to write some
helpers that make it easy to invoke the Emscripten-compiled shader
translator from JavaScript, and provide this precision emulation as a
JavaScript library.


On Mon, Nov 17, 2014 at 11:04 AM, Kenneth Russell <[email protected]> wrote:
> It's been a problem for a while that WebGL developers accidentally
> write desktop-only content because they couldn't test on mobile
> devices that have lower precision. Olli's work helps address this
> longstanding problem. He's found a significant amount of content
> (including from expert graphics developers) that doesn't work properly
> on mobile hardware due to its lower precision.
> I think it's important to get this functionality into the hands of
> developers. To be pragmatic, there are two options for doing so in a
> reasonable timeframe.
> 1. Provide it in the browser. Firefox's webgl.min_capability_mode pref
> is useful to help developers see if their content will run on low-end
> devices. Precision emulation could plausibly be put behind a pref such
> as this, instead of exposed as a WebGL extension. It could also be
> built into browsers' developer tools, though that's a longer path.
> 2. Use Emscripten to compile ANGLE's shader translator, provide it as
> a JavaScript library, and include precision emulation as an option to
> the translator.
> Writing a brand new GLSL compiler in JavaScript as a prerequisite for
> this work is not a viable option. There will be too many bugs and
> corner cases to handle.
> Option 1 can be provided fairly quickly in at least a couple of
> browsers with very little work. It's for this reason I think it is
> worth exposing this extension.
> Option 2 is certainly better in the long term, and from the standpoint
> of providing the functionality on all browsers transparently.
> I'll invest some time to see how feasible it is to compile ANGLE's
> shader translator with Emscripten. If it looks like this is easy then
> we can pursue that option. Landing Olli's patches to ANGLE will
> proceed in parallel.
> -Ken
> On Mon, Nov 17, 2014 at 8:30 AM, Olli Etuaho <[email protected]> wrote:
>> I've already written some of the code in ANGLE because it was the only
>> reasonable way to write the code. When I started to work on this, I was
>> looking at two options:
>> a) Implementing this inside ANGLE, which already had proven,
>> production-quality infrastructure for parsing GLSL and pretty good precision
>> tracking.
>> b) Writing my own GLSL parser.
>> Since I wanted to get this done without pouring a huge amount of time into
>> it, I went for option a) after discussing this with ANGLE maintainers.
>> Granted, I didn't know of Tibor's GLSL debugger project back then, but that
>> also seems to have a long way to go before something like this could be
>> integrated. After that I started thinking about different ways to expose
>> this, all of which have their ups and downs.
>> WebGL extension:
>> +The least work to implement and maintain, fairly convenient for both manual
>> and automated testing of JS apps, every major desktop platform has some
>> browser where this could be used
>> -Conflicts with the idea of a minimal API, less flexibility for changes,
>> doesn't help people who exclusively use non-ANGLE browsers for development
>> Browser developer tools:
>> +Convenient for manual testing of JS apps, not much work to implement and
>> maintain either, more flexibility
>> -Not convenient for automated testing of JS apps, doesn't help people who
>> exclusively use non-ANGLE browsers for development, exact behavior may be
>> more opaque to users
>> Emscripten-compiled library:
>> +Available absolutely everywhere, browser APIs stay minimal, convenient for
>> both manual and automated testing of JS apps, the most flexibility
>> -A lot more work to setup and maintain, exact behavior may be more opaque to
>> users
>> The positives seemed to outweigh the negatives in the case of a WebGL
>> extension, so I submitted the proposal. I also think the browser vendors
>> agree that this problem is so big and fundamental that it makes sense for
>> them to spend some effort to help fix it. But maybe the principle of having
>> a minimal API is more important than the pragmatic considerations, and I
>> should prioritize getting this exposed as a part of browser developer tools,
>> and then maybe later as a library, depending on what results from getting
>> this out there in the developer tools. I was not expecting this level of
>> opposition to the extension.
>> We could also consider other measures to mitigate the problem: for example,
>> always using highp precision in vertex shaders, disregarding their precision
>> qualifiers. This would be allowed in an implementation of WebGL 1.0 as it is
>> currently specified, and could be explicitly specified for WebGL 2.0. The
>> performance cost for getting more content to run correctly on some of the
>> more exotic WebGL platforms might be a good tradeoff. I'd also suggest
>> changing what the MDN WebGL best practices page says about mediump in
>> fragment shaders, since that advice has probably led to more bugs appearing
>> than it has helped to avoid.
>> -Olli
>> ________________________________
>> From: [email protected] <[email protected]> on
>> behalf of Gregg Tavares <[email protected]>
>> Sent: Monday, November 17, 2014 6:43 AM
>> To: Olli Etuaho
>> Cc: Tibor Ouden, den; Gregg Tavares; Jeff Gilbert; Mark Callow; Florian
>> Bösch; Kenneth Russell; public webgl
>> Subject: Re: [Public WebGL] WEBGL_debug_shader_precision extension proposal
>> If I understand correctly your arguments boil down to (a) You've already
>> written the code and (b) It's based on ANGLE which is in C++ therefore you
>> can shove it into Chrome. And maybe Firefox and Safari can use it too. Not
>> IE. You're still requiring all browser teams to invest time into this
>> integration. They're stuck maintaining it forever. Of course they can choose
>> to never support it since it's an extension but then you aren't really
>> achieving your goal in that case.
>> I still don't see the point of making it an extension. Like Tibor said,
>> extensions should be for core functionality.
>>> The standard has gone on for years without any tools to address this
>>> fairly large problem.
>> While tools to help with this are great the standard doesn't need to address
>> this. A library will address this better for all the reasons mentioned
>> before. I'm really not seeing the argument that it should be an extension
>> except you've already written some code. It seems like it should come down
>> it if it's the right thing to do. Maybe it is but I haven't seen a good
>> argument for why.  Making it an extension won't make it any more likely to
>> be used. In fact the most likely way for something like this to be used
>> would be to add it to the WebGL Inspector or something similar so that the
>> user doesn't have to change any code, they can just visit any page and click
>> some button that's outside the page.  You could also build it into a
>> browser's devtools, but that again won't help because it will only be
>> available in those browsers that implement it.
>> It seems like if you really want to hit the most devs you'd make it a
>> library because then any dev on any browser could use it.
>> On Fri, Nov 14, 2014 at 7:50 AM, Olli Etuaho <[email protected]> wrote:
>>> I don't think that being able to set a ton of settings is actually that
>>> useful. If a shader runs correctly on a configuration where the floating
>>> point values have the minimum number of bits allowed by the spec and where
>>> subnormal numbers are flushed to zero, it is very likely to also run
>>> correctly on a configuration with a slightly higher number of bits and where
>>> subnormal numbers are not flushed to zero. So an explosion of the amount of
>>> test configurations can be avoided by only testing in an environment which
>>> implements the minimums.
>>> I agree that not simulating the internals of built-in functions is an
>>> issue in the extension as it is currently specified, and I could still put
>>> some work into evaluating the significance of that, but we'll also have to
>>> remember that perfect is the enemy of good enough. The standard has gone on
>>> for years without any tools to address this fairly large problem. Now, when
>>> a solution comes along that would help with more than 90% of the issues, it
>>> seems like an odd response to me to say that this won't do and something
>>> better is needed. The working group agreed in a recent meeting that the
>>> extension is potentially a good way to expose this functionality for
>>> pragmatic reasons, even if it's also going to become a part of browser
>>> developer tools and even if ideally a JS library would be preferable.
>>> That being said, I'm interested in hearing more about the debugging tool
>>> you're working on, it sounds like it can help developers fix related
>>> problems as well. Do you have it up somewhere on the web? Feel free to reply
>>> outside the thread if you think that's appropriate.
>>> -Olli
>>> ________________________________
>>> From: Tibor Ouden, den <[email protected]>
>>> Sent: Friday, November 14, 2014 3:53 PM
>>> To: Olli Etuaho
>>> Cc: Gregg Tavares; Jeff Gilbert; Mark Callow; Florian Bösch; Kenneth
>>> Russell; public webgl
>>> Subject: Re: [Public WebGL] WEBGL_debug_shader_precision extension
>>> proposal
>>> To easily change the precision to inspect the effect on the computation is
>>> useful debug functionality.
>>> But a next request could be to have control over the exact count of bits
>>> in the significand.
>>> And then I would like to specify the amount of guard bits used.
>>> And then for sqrt() I would like to be able to specify a certain look up
>>> table algorithm because the gpu
>>> in device xyz uses that.
>>> Change the treatment of subnormal numbers ?
>>> Emulate the 'exact' numerical behaviour of gpu xyz ?
>>> ... etc.
>>> I think this is part of a larger set of debug features related to
>>> numerical precision issues.
>>> I think extensions should be related to the functionality of WebGL
>>> (running code from a web page on the gpu)
>>> Everything related to enhancing the implementation process of a polished
>>> WebGL application is 'tool' functionality
>>> and should be done in a library if possible in my opinion. It allows for
>>> more flexibility and prevents the WebGL
>>> spec from increasing.
>>> If you allow this functionality to be an extension where do you draw the
>>> line ?
>>> I have nothing against a browser vendor implementing a full blown shader
>>> debugger in their browser.
>>> But that is not part of the WebGL spec.
>>> While attempting to implement a physics engine on the gpu
>>> (http://www.borbitsoft.com/)
>>> using WebGL, I encountered some interesting numerical issues.
>>> Due to the experiences with that project I started working on a shader
>>> debugger in javascript which allows
>>> the user to inspect every single variable by rewriting the shader on the
>>> fly and warn against common mistakes (at least for me :-) ).
>>> Specifying reduced precision is an interesting feature, as is selecting
>>> the 'exact' numerical
>>> profile of target device xyz.
>>> Also warning against constructs like vec3(float, vec3) (silent drop of
>>> last component of 2nd argument)
>>> Not setting gl_PointSize when rendering points
>>> ...
>>> This done in in-between-projects-time so will take a while.
>>> Cheers,
>>> Tibor
>>> 2014-11-14 11:10 GMT+01:00 Olli Etuaho <[email protected]>:
>>>> I agree that having a tool for detecting other kinds of undefined shader
>>>> behavior would be useful. There's multiple kinds:
>>>> -Math function limitations (asin, acos, atan, pow, log, log2, sqrt,
>>>> inversesqrt, clamp, smoothstep all have these)
>>>> -Accessing textures inside non-uniform control flow
>>>> -Reads from uninitialized shader variables and missing return values
>>>> -Not writing to gl_Position
>>>> -Some details of integer computations
>>>> But even with all of these possibilities of undefined behavior, most of
>>>> the errors I've seen are still definitely related to precision. To put some
>>>> data behind my claims that they're extremely widespread: they're in some
>>>> three.js examples, some Blend4Web demos, all except the latest version of
>>>> Babylon.js, turbulenz engine, some other proprietary WebGL content, and as a
>>>> guesstimate in half of recent shader demos in glslsandbox and shadertoy. Of
>>>> course you won't ever see the precision issues unless testing on a variety
>>>> of mobile hardware.
>>>> If someone is willing to put in the work to implement a more versatile
>>>> shader debugging library, that would be useful, but I think the precision
>>>> emulation can still stand on its own. Having it as an extension in browsers
>>>> doesn't prevent building more things on top of it.
>>>> -Olli
>>>> ________________________________
>>>> From: Gregg Tavares <[email protected]>
>>>> Sent: Friday, November 14, 2014 3:31 AM
>>>> To: Olli Etuaho
>>>> Cc: Jeff Gilbert; Gregg Tavares; Mark Callow; Florian Bösch; Kenneth
>>>> Russell; public webgl
>>>> Subject: Re: [Public WebGL] WEBGL_debug_shader_precision extension
>>>> proposal
>>>> As an example of something that I'd want added to this and an argument
>>>> for making it a library,
>>>> I'd like to see something that re-wrote the shaders to find all the
>>>> undefined behavior. For example I just tried to use this shader on iOS
>>>>      http://threejs.org/examples/webgl_shader.html
>>>> It turns out it's calling pow(x, y) with x < 0 which is undefined
>>>> according the spec and therefore doesn't work on all GPUs.
>>>> That seems like something a shader debugging re-writing library could
>>>> easily do, maybe by rewriting pow to some kind of expression that returns a
>>>> different color by mod(gl_FragCoord, 2) or something such that the results
>>>> hopefully stick out. Personally I've found these errors far more common than
>>>> precision errors but that might just be my experience.
>>>> It seems like other re-writes for debugging would be useful too. You
>>>> could probably implement shader debugger. But if you make it an extension no
>>>> one else can't augment it.
>>>> Also not every browser uses ANGLE AFAIK.
>>>> -gregg
>>>> On Wed, Nov 12, 2014 at 3:57 AM, Olli Etuaho <[email protected]> wrote:
>>>>> I do see the upsides of having this as a library, but as I stated
>>>>> before, the best way to implement said library would be to run ANGLE's
>>>>> shader compiler through emscripten. This is possible to do whether the
>>>>> extension is accepted or not, but from a purely technical perspective, it's
>>>>> much more work and overhead. As counterpoints to Gregg's message:
>>>>> -The specification is fairly small, so making it exact is not very hard.
>>>>> -The specification can still spend a while as a proposal/draft, so it
>>>>> can be more freely edited and the issues can be worked out.
>>>>> -I'll be doing the implementation work in ANGLE. ANGLE maintainers
>>>>> already expressed that they'd likely be willing to accept the patches. After
>>>>> that, it's fairly trivial to expose the extension. I already have a working
>>>>> prototype for Chromium. So I hope it will require only a minimal amount of
>>>>> work from anyone else.
>>>>> -I can't foresee any pressing need to extend and update the extension.
>>>>> The extension should be compatible with both ESSL 1.00 and ESSL 3.00 already
>>>>> in its current form. The need to do large updates to it would arise only if
>>>>> WebGL switched to a drastically different shading language.
>>>>> -This is an extension for testing, so not having support in every
>>>>> browser is more of a slight inconvenience rather than something that would
>>>>> greatly hinder its usefulness.
>>>>> -If it was a library, a spec like this would still be beneficial, so
>>>>> that what it does would be clear to the user.
>>>>> I also can't stress enough how widespread precision-related shader bugs
>>>>> are. I've seen them frequently in content developed by professional and
>>>>> hobbyist developers alike, every once in a while even in content that was
>>>>> specifically written with mobile devices in mind. If you're still not
>>>>> convinced, I'll have to look at other alternatives besides the extension,
>>>>> but something needs to be done, and I think tooling like this is a big part
>>>>> of the answer.
>>>>> -Olli
>>>>> ________________________________________
>>>>> From: Jeff Gilbert <[email protected]>
>>>>> Sent: Wednesday, November 12, 2014 4:26 AM
>>>>> To: Gregg Tavares
>>>>> Cc: Mark Callow; Florian Bösch; Olli Etuaho; Kenneth Russell; public
>>>>> webgl
>>>>> Subject: Re: [Public WebGL] WEBGL_debug_shader_precision extension
>>>>> proposal
>>>>> I agree with Gregg.
>>>>> I will add that if it's something that we feel is important enough as a
>>>>> working group, we could canonize the library and maintain it as part of our
>>>>> github repo.
>>>>> -Jeff
>>>>> ----- Original Message -----
>>>>> From: "Gregg Tavares" <[email protected]>
>>>>> To: "Mark Callow" <[email protected]>
>>>>> Cc: "Florian Bösch" <[email protected]>, "Jeff Gilbert"
>>>>> <[email protected]>, "Olli Etuaho" <[email protected]>, "Kenneth
>>>>> Russell" <[email protected]>, "public webgl" <[email protected]>
>>>>> Sent: Tuesday, November 11, 2014 6:16:19 PM
>>>>> Subject: Re: [Public WebGL] WEBGL_debug_shader_precision extension
>>>>> proposal
>>>>> If this works just fine as a JavaScript library why add it as an
>>>>> extension?
>>>>> As an extension what it does has to be specifically specified.
>>>>> As an extension it can't be upgraded without making and proposing a new
>>>>> extension.
>>>>> As an extension it passes all work to the browser vendors who each need
>>>>> to
>>>>> implement it
>>>>> As a library it can be updated and extended whenever
>>>>> As a library it only needs one implementation and everyone can use it
>>>>> As a library it can do whatever it wants, no spec needed
>>>>> From the discussion above it doesn't seems like it needs to be an
>>>>> extension. It doesn't seem like there is some specific OpenGL
>>>>> functionality
>>>>> that needs to be exposed to make it possible. It also doesn't sound like
>>>>> a
>>>>> speed issue given that the resulting shaders are up to 10x slower.
>>>>> Also as a library it should be easy to patch it the same way the WebGL
>>>>> Inspector patches itself in or various other libraries that patch things
>>>>> like WebGLRenderingContext.prototype.compileShader
>>>>> On Tue, Nov 11, 2014 at 2:23 PM, Mark Callow <[email protected]> wrote:
>>>>> >
>>>>> >
>>>>> > > On Nov 12, 2014, at 7:19 AM, Florian Bösch <[email protected]> wrote:
>>>>> > >
>>>>> > > What's wrong with it is that it does not allow you to isolate an
>>>>> > > issue
>>>>> > with any of your shader code buried in use somewhere in your
>>>>> > application.
>>>>> > >
>>>>> >
>>>>> > You have to find either the buried shader code or the buried call to
>>>>> > compileShader for that shader. These efforts may or may not be much
>>>>> > different, depending on the structure of your code. I would not object
>>>>> > to
>>>>> > supporting both an API toggle and a pragma, getting the best of both
>>>>> > worlds.
>>>>> >
>>>>> > Regards
>>>>> >
>>>>> >     -Mark
>>>>> >
>>>>> >
>>>>> > -----------------------------------------------------------
>>>>> > You are currently subscribed to [email protected]
>>>>> > To unsubscribe, send an email to [email protected] with
>>>>> > the following command in the body of your email:
>>>>> > unsubscribe public_webgl
>>>>> > -----------------------------------------------------------
>>>>> >
>>>>> >

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list