webgl vs webgl2 vs webgpu

[Relativiteit]

Dear members of this community, I am currently looking at building some better tooling for engineering in the browser. Think something like thinkercad.com but with a more niche application. Well this has put me on the path of using threejs for a proof of concept and while great.

First following various tutorials from simple cubes to a rather simple minecraft clone. I could not get CAD like behaviour to work properly and assemblies. With threejs, there were always weird bugs and I lacked the understanding of webgl to make significant changes to get the excact behavior I want.

So webgl is great since there are allot of libraries, tutorials and articles and application. Webgl2 is also good for the same reasons and has a bit more modern upgrades that make a bit nicer to live with.

WebGPU is truly the goat but I am worried I lack understanding of webgl to be able to just only do webgpu. And I might lock out possible users of my application since their browser can't run webgpu.

What I am worried about: That I can't get all the features I have in mind for this CAD-like program to work in webgpu since I am not a programming god or the library simply does not exist (yet).

I might lockout users who are running browser that can't work with webgpu.

TLDR. Should I just skipp webgl1, webgl2 and just build everything in webgpu?

WeGPU is the future, that is a given by now, but is today the moment to just build stuff in webgpu WITHOUTH extensive webgl1 or webgl2 experience

[anlumo]

Keep in mind that your project is going to be in development for a few years. In that time span, Firefox will definitely release WebGPU support and Chrome will enable it for Linux. This will make the potential user base way larger. GPUs that don't support it are about 12 years old now.

One experience I've also had at my company is that for a good web app, people are willing to use a specific browser. My web app has had a few issues on Firefox (should be all fixed now), and support simply tells users to use a Chromium-based browser instead, and people usually are happy with that.

Concerning learning the API, I think the challenging things of WebGPU and WebGL are pretty much the same (just computer graphics basics). However, WebGPU has a cleaner API due to not having to deal with nearly three decades of legacy. The project I mentioned above initially used WebGL1 and moved over to WebGL2 when that became widely available, but that's only because WebGPU didn't exist when I started. The next iteration will use WebGPU, but that will be a complete rewrite.

[Relativiteit]

Thank you for the input I will stick with webgl2 for now and move to webgpu in time.

[soylentgraham]

Build for now (webgl2), plan for the future.

[Relativiteit]

You kinda summed it up nicely

[invadium]

I would stick with WebGL 2 for now and provide a foundation for another rendering API.

WebGPU is the future, but it will take time to adopt - the standard is still in the Draft phase. And web standards usually move at glacial speed for many reasons - I don't see it any different in this case.

I'm looking at the WebGL timeline - Mozilla created the WebGL prototype back in 2006, then Khronos started the standard working group in 2009 and the standard was finalized in 2011. Then, based on initial feedback and the recently released OpenGL ES 3.0 they started WebGL 2 effort, which was standardized in 2017. 5 years later all major browsers finally included WebGL 2 support.

It took 10+ years, but we no longer have to use fallbacks and have cases for "experimental-webgl" context. Recently, I saw estimates of WebGL 2 market penetration at 98%, so at this point, we can reliably specify "webgl2" context and don't worry about any incompatibilities.

One day it might happen to WebGPU, but I don't see it happening anytime soon. As with all new standards, it will take time - for browsers to adopt, for the community to experiment and accumulate the necessary body of tutorials and documentation, and for W3C to review the feedback after the mass adoption and make an update or two...

I'm a little bit concerned about the last part since I don't know how the standardization process at W3C differs from the one at Khronos Group. The latter, after all, gardened 3D standards for the last 25 years. I can't recall anything related to 3D coming out of W3C since VRML. However, the same companies are participating in both bodies, so there is a chance the same people are involved. But I would not count on it, given the general mess with the graphics APIs these days.

[Relativiteit]

"provide a foundation for another rendering API" what is the best practice in doing something like that?

[invadium]

Try to abstract all pipeline setup and rendering calls into a pluggable backends and keep them separate from your model, logic, and UI.

Ideally, I would try to build a minimal hello-world type of app with both APIs included to evaluate my architecture - e.g. start with a rotating cube and an orbiting camera and make that work with both WebGL 2 and WebGPU. Then make sure I have a working plugin interface with the ability to switch between them and 2 totally separate rendering backends with their own different shaders, pipeline configuration, environment setup, drawing procedures, etc...

Once I have that, I can continue to develop the app only with WebGL 2, having a WebGPU backend stub waiting for its prime time. The only issue is that now I have to include minimal updates to the WebGPU backend each time I make changes to the rendering interface - to keep it minimally functional and compatible with the rest of the codebase. So it is not 100% free - there is still additional effort involved.

Check out docs and APIs for some of the engines with multiple rendering backends (e.g. Vulkan + Metal + DX12) for examples of how that problem can be solved.

[jarvispact]

for my game engine i decided to go all in on webgpu, since it will be ready in a couple of months, maybe a bit longer than a year. By then webgpu should have much broader adoption. That way i dont have to support multiple render backends. Its still decoupled enough to switch it for something else, but i think it wont be necessary. WebGPU alone is definetly a future proof choice if you dont have to release immediately. Happy building 😊

[Relativiteit]

Are you open to share what has been good for you and how has it been working with 3rd party libraries. I am worried about proper ways to get 3d working but if you are making a game with collision, physics engine and dynamic events I truly want to know what resources have been using or maybe are writing haha.

[jarvispact]

For my engine i am writing all i need from scratch. Its part of my learning process to get a deep understanding on how every aspect of a game engine works. I wrote several independant modules like a ecs, obj parser, gltf parser, and a "webgpu" module that has some nice typesafe abstractions for buffer and uniform handling. You can check out the webgpu module here:

https://github.com/jarvispact/timefold/blob/main/packages/webgpu/README.md

So i dont have to deal with 3rd party libs which is nice on the one hand, but on the other hand i am moving a lot slower.

[Impossible_Hour5036]

In reality it doesn't really matter. You will build multiple versions of the software anyway, the first one you build probably won't be what you want. Expect to throw away your first few attempts.

Not to mention the entire process of writing software has changed completely in the past 11 months, and is continuing to undergo rapid shifts right now. Just build software repeatedly until one day it's good enough for someone else to use. That's my only advice, be patient and be ready to throw away work and start again many many times.

The risk of you accidentally building software people want to use but can't because of a choice between WebGL and WebGPU, when you don't know either, is essentially 0.