Approach to built-ins

[mattdesl]

Currently if a builtin isn't hard-coded it could break shaders (for example, fwidth not being listed might get mangled to fwidth_2_1). As WebGL2 and new extensions come to browsers, we should be wary of new functions/constants.

Some things not listed in the built-ins:

• pragmas like GL_ES and __VERSION__ -- not sure if that matters tho
• gl_MaxFragmentUniformVectors, gl_MaxVaryingVectors, gl_MaxVertexUniformVectors
• I added dFdx / dFdy, but there is also fwidth
• transpose (GLES 3)

Some other things like gl_InstanceID, gl_ClipDistance, outerProduct, shadow2DProj, etc may or may not eventually end up in WebGL (in spec or through extensions).

Maybe there is another way of handling this? Like only mangling function names when necessary?

[hughsk]

I think in the long term only mangling function names when necessary is probably the best approach, but I suspect it's going to be a tricky change. In the short term I don't think it's too much for us to update the list of builtins when we run into something that isn't catered for though :)

Something that might help a little: it's specced out that all variables beginning with gl_ and GL_ are reserved for builtins, so we can catch all of those ones with a tweak to glsl-tokenizer.

[milcktoast]

I ran into this the other day with use of standard derivative extension methods in an imported function body. A quick hacky fix that works for now is to pass a reference of the method name to the module.

i.e.

#pragma glslify: myFn = require(./my-std-deriv-fn, fwidth=fwidth)

Ideally, these methods would be either known to glslify or could be augmented by a user with some configuration file (.glslifyrc?)