[rice7th]

Isn't webGL's GLSL directly delegated to the driver just like normal OpenGL? Also one could easily write a lot of frontends and a single massive centralised backend with multiple processor targets and optimisation profiles. Think about V8 which works for both JavaScript and WebAssembly. This would create a much simpler codebase and if you're going to use a parser generator it could very well be a breeze.

[jsheard]

> Isn't webGL's GLSL directly delegated to the driver just like normal OpenGL?

Perhaps you could in an MVP implementation, but in practice no, none of the serious implementations do that by default. First because native OpenGL drivers are generally a mess, so browsers actually implement WebGL on top of DirectX, Vulkan or Metal wherever they can, and even when those aren't available the browsers still parse, validate and reconstitute the GLSL rather than passing it straight through to OpenGL as a layer of insulation against driver bugs. Chrome and Firefox do have hidden feature flags which bypass that behavior and call the native GL implementation directly, but you probably shouldn't enable those unless you're really into ShaderToy and want it to compile faster.

[rice7th]

Wow that was something I wasn't expecting. Well I guess it does kinda make sense that running untrusted code on a gpu wouldn't be the best idea, however I seriously thought that browsers just passed their glsl directly to the GPU. Also since linux doesn't have its own graphics API I am afraid that WebGL support would introduce a lot of complexity, since you can definitely pass via OpenGL but Vulkan could be also an option.

Thank you for the tip!