[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Public WebGL] WEBGL_debug_shader_precision extension proposal



WEBGL_shader_ast is a neat idea, but that would require a large spec if it was a WebGL extension, and it would add possibly unwanted constraints on how the parsing infrastructure in browsers should work. Implementing that as a JS library might actually be less effort. In this case the additions to the API are minimal. Also, one important goal here is to make using the emulation as easy as possible. To that end, just a few added lines of code is much better than integrating a big library to a JS app

I come up with an alternative on how toggling the emulation on a shader-by-shader basis should work, by the way - using a "#pragma webgl_disable_precision_emulation;" directive in shaders could be simpler to both understand and implement. Thoughts on this?

From: Florian Bösch <pyalot@gmail.com>
Sent: Thursday, November 6, 2014 3:32 PM
To: Olli Etuaho
Cc: public_webgl@khronos.org
Subject: Re: [Public WebGL] WEBGL_debug_shader_precision extension proposal
 
On Thu, Nov 6, 2014 at 2:29 PM, Olli Etuaho <oetuaho@nvidia.com> wrote:
I commented on implementing this as a JS library in my first message. Making it a WebGL extension is just the simplest way to expose this, since the functionality is easiest to implement by reusing the existing infrastructure in ANGLE. But if someone really wants the emulation as a JS library, they would be free to emscripten-compile the relevant parts of ANGLE and use it that way.
I agree that reusing the existing ESSL parsing infrastructure makes this much easier as then it can be implemented as an AST visitor relatively trivially. Though a variety of other usecases would benefit from that ability as well. I'd much rather see an extension along the lines of WEBGL_shader_ast that offers an api/format to parse a shader to an AST, modify it, and pass it back to be compiled.