Keep viability for compilation to WebAssembly or transpilation via Emscripten in mind

[thokra1]

First off, something on the status-quo as I perceive it. My major gripe with WebGL is its horribly slow adoption rate and the fact that WebGL2 will be outdated as soon as it is ratified compared to GLES3.2 and OpenGL 4.5 certainly does not help. I currently find myself implementing an OpenGL 4.5/GLES2 based rendering framework for a special purpose (so Unity and Unreal are currently intentionally out of the picture). While being able to (de-facto) seemlessly transpile the GLES codepath to WebGL, it is very disconcerting having to drop all the goodness we have come to expect from OpenGL 4.5 (including but not limited to the AZDO paradigm). I imagine Unity and Unreal developers feel the same way. Frankly, as a developer mainly dabbling in stuff on the desktop, it is beyond me why exposing desktop OpenGL in a browser and on mobile devices should not be possible today - current hardware certainly should not pose much of a problem (please correct me if I'm wrong there).

Despite that major problem, having a single code base, for instance in C++, which can be compiled for different targets like x86_64 and ARM and (at this time) transpiled to JavaScript is pretty sweet. As a developer working primarily on and for the desktop, I'd like to be able to reuse my C++ code wherever possible. IIUC, the formalization of WebAssembly and the possibility to let your compiler spit out the IR will only make this more convenient - which is also a major step in the right direction. Even though my knowledge of the Web as a platform is limited, step-by-step elimination of hurdles for multi-platform deployment and consistent user experience is what I consider one of the most important mid- or long-term goals.

This also applies to the WebGPU proposal. For example, I'd like to be able to write something on the desktop and deploy it on all relevant platforms - ideally using the same set of features. Having a close or even one-to-one API correspondence currently enables me to do that when I limit myself to GLES2 and WebGL. I urge you to keep that in mind when specifying a WebGPU API - I don't care how this is achieved, but I desperately want it and I think we all need it. Ideally, I imagine a unified approach to all platforms which currently can be (at least to a degree) achieved with the help of Emscripten and frameworks like electron.

This immediately impacts certain choices currently made for the proposal which I find highly debatable, including the choice of shading language. Being forced to deploy shaders written in two different languages unnecessarily increases complexity. Also, why would you demand that developers learn a fringe shading language and why would you define another IR for something that is already in place with e.g. SPIR-V? I can see some of the benefits of the Metal SL (like being able to modularize properly without having to employ a de-factor VFS with GL_ARB_shading_language_include). I also understand that for something that comes out of Apple, it makes sense to advertise in-house technology, but I think we all might be better off if you just turn to your fellow Khronos members and handle this business with all members of the industry participating. Just improve GLSL or define something new as a concerted industry effort (unless you want the Metal SL to be just that, in which case I want you to provide a SPIR-V compiler).

Something on which I'd like to have some clarification is the fact that OpenGL and Vulkan, while usable to achieve the same observable result, they are very different APIs which both exist in their own right. I can see a ton of scenarios where implementing a Vulkan renderer is not necessary. On the other hand, OpenGL carries some historically based design flaws which can be properly handled with Vulkan (e.g. multi-threaded command buffer submission) and, by design and due to resulting implementations, is (supposedly) not able to outmatch Vulkan in regards to performance.

While the WebGPU proposal addresses the necessity to expose something akin to Vulkan in the browser, this does not solve any problems for people wanting to use the latest GPU features through OpenGL - unless someone comes up with an implementation of OpenGL atop WebGPU. I don't want to be forced to use either technology - I want to be enabled to choose the API according to necessity. Do you think this is possible and something to strive for?

[GunpowderGuy]

Why is webgl 2 adoption is so slow? It may have something to do with a company not supporting all of its features , due to still using a 6 year old open GL version . In the other hand , browser developers had their hands full implementing new standards and mozilla is also doing a major rewrite

[thokra1]

@diegor8: I don't care for assigning blame (you could say a lot about other vendors when discussing the evolution of OpenGL on the desktop as well, but that doesn't help anybody). All I care about is how we move forward from here. Apple has interests as a business that might not align with your view of how things are supposed to be. However, @grorg has already stated in another issue that nothing is off the table for WebGPU at this point. Please stay on the subject matter.

[Kangz]

@thokra1: the issues in this repository are to talk about the draft charter for the community group. I believe discussions about Apple's WebGPU proposal should be done somewhere else, like its GitHub repo if/when it gets uploaded.

The point you are trying to make with respect to the charter is that it should include WebAssembly as a first class Web language to which the API is exposed (meaning the shim to Javascript should be as small as possible).

@diegor8 WebGL2 adoption being low might have to do with the fact that it has been shipped in stable versions of Chromium and Firefox just last month.

[thokra1]

@Kangz: Thx for pointing that out. I will gladly move the issue if someone points me to a more appropriate place.

[grorg]

I've moved it to gpuweb/gpuweb#1

Unfortunately this means that @thokra1 isn't the originator, but hopefully that will be ok. My bad for not creating the technical repository sooner :(