[Public WebGL] WEBGL_debug_shader_precision extension proposal

Gregg Tavares [email protected]
Thu Nov 13 17:31:02 PST 2014


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
> > -----------------------------------------------------------
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20141113/77c924ab/attachment.html>


More information about the public_webgl mailing list