Wow, WebGPU support is really cool. Graphics is usually an afterthought in programming language runtimes, which is crazy when you consider that most devices these days have a GPU which is physically larger and has far more raw compute power than the CPU.
I understand why. The extremely proprietary and platform specific nature of graphics APIs and hardware makes it hard. WebGPU is a good choice for portability.
Looks like they are using wgpu, which is the main (only?) implementation of WebGPU. Seems like WebGPU will work because everyone is going to ship the same shim (wgpu) over the top of proprietary APIs.
There are three implementions of WebGPU in development for the three browser engines. Dawn for Blink and wgpu for Gecko are cross platform, and I think Apple may be doing something Metal-specific for WebKit.
Both Dawn and wgpu are standalone libraries too, so applications other than Blink/Gecko can plug either in to get a Metal-ish abstraction that works everywhere
It will be nice to finally have a portable 3D API that's sanely designed (unlike OpenGL) and that non-experts can be expected to handle (unlike Vulkan)
There's not that much boilerplate actually. Much less than in Vulkan. WebGPU abstracts away memory management, synchronization and image transitions, which make up for a lot of boilerplate code in Vulkan (and easy to get wrong). The WebGPU hello world code is not that much longer than equivalent OpenGL 3.x code, however it is a more strict API and in some cases requires a redesign of a renderer. For example, you can't update uniforms in the middle of a render pass, you have to create a large buffer and use dynamic offsets to move inside that buffer. In OpenGL the driver did that for you transparently.
Whereas in most middleware you can say "here is my scene, do your best", and only dig deeper if it needs some help to do its best.
As traditionally in all Khronos APIs, the step from "I managed a rotating cube with gourad shading", to loading a game scene with PBR material, is a gigantic step full hunting for libraries and trying to put them together, somehow.
It is no surprise that even with WebGL, most people end up picking ThreeJS or BabylonJS, after getting their first triangle.
Khronos APIs aren't meant to be middleware. They are meant to offer a thin low level abstraction for different vendors, upon which you can create middleware which offers higher level abstractions. Most famously in Vulkan, where each part of the spec is built almost for a specific vendor. Image transitions in Vulkan were mostly designed for AMD, NVidia doesn't require image transitions in Vulkan code at all. Renderpass APIs were developed mostly for tiled (usually mobile) renderers which can optimize when they know which render targets will be written to ahead of time.
Yet. Middleware renders the "portability"[0] of Khronos APIs a moot point, by having the best 3D API for each platform hardware, while at the same time exposing a more developer friendly infrastructure.
[0] - Anyone that was used Khronos APIs in anger across multiple OS and GPGPUs, knows the painful way of multiple code paths due to extensions, driver and hardware workarounds.
Easy and simple are not the same, and one still needs to go hunting for libraries to do basic stuff like loading textures, in good old Khronos tradition.
Which are shipped by the same companies as the 3D APIs, on the same OS SDK, where are the Khronos utility libraries?
The attempt to create an OpenGL SDK repository was a joke, and the best Vulkan SDK can offer is a tool to avoid loading all the layers by hand, as it reached the same extension spaghetti as any Khronos API.
But for cross-platform code it makes more sense anyway to use an independent cross-platform image loader library, instead of depending on the platform-specific utility APIs provided by D3DX or MetalKit.
That was just an example of a library, we can carry on with fonts, scene management, 3D math, .....
I did my thesis porting a particle engine from NeXTSTEP into Windows 98, and was big into OpenGL for a couple of years, went through the Longs Peak drama, eventually my focus switched to other 3D APIs by the GL 3.x timeframe.
WebGPU is the common cross-section of the modern 3D APIs (Metal, D3D12 and Vulkan). In general, and somewhat simplified, those APIs move all the expensive render-pipeline-configuration out of the render loop and into the initialization phase. So your code is much more "front-loaded" than GL, but once everything's initialized, the actual rendering is much less code and has much less overhead because most render-state has been pre-compiled into immutable objects. OpenGL on the other hand is a highly dynamic state machine where flipping a single "switch" can lead to expensive reconfiguration of the render pipeline during rendering.
I've been using wgpu for quite some time (in D, through wgpu-native bindings). What exactly do you find it horrifying? It's much closer to DX12/Vulkan than OpenGL. The main difference is that it introduces the concept of a render pipeline, encapsulating all render state from shaders used, shader input layouts, vertex layouts, depth/stencil states, color attachments, which can be pre-created and then bound with a single API call. It's a big improvement over OpenGL which required you to track the state yourself or pre-emptively restore most of the state to avoid side effects between calls.
Have you seen a Vulkan "Hello Triangle" in comparison? That's a least a thousand lines of code, and that's with taking shortcuts :)
132 lines isn't really that much for a triangle in any 3D API, except 90's style OpenGL 1.x (which was a nice and convenient API, but also very inefficient).
I'm sure there will be plenty of high-level Javascript libraries built on top of WebGPU which will cater to different philosophies and use cases, and those will also allow a Hello Triangle with fewer lines of code (but also will involve compromises at flexibility or performance).
Kinda :/ on there not being a GPU permission (that I can find in the post or the docs); GPUs/GPU drivers have been a vector for some pretty nasty attacks in the past...
For years WebGL has been exposed to every website you visit with no permission prompt, and WebGPU soon will be too. It is possible to expose GPUs securely and the WebGPU API is designed with sandboxing and security in mind.
Edit: I believe the bug you linked below (https://bugs.chromium.org/p/project-zero/issues/detail?id=20...) can't be exploited through WebGL or WebGPU in the browser because all GPU access is remoted to a separate process with a special GPU sandbox. I don't know if Deno does this but it should.
The thing is that without read/write or net permissions, a malitious script that turns your computer into a mining rig will throw because it can't connect to any server or use your filesystem. We already expose CPU to third party code, doing the same for GPU is trivial in that sense if you remove the possibility to do anything with it without your consent
That's part of my concern, though since scripts can use the CPU arbitrarily, they could already mine on the CPU. A larger concern is bugs like [0], since GPU drivers are highly complex and highly privileged code.
Yeah that could happen. There was some discussion about a permission in the Discord though, but I don't think it was ever added or thought about on GH.
I was under the impression that Deno is a runtime mostly intended for the server environment which is probably an area where GPU presence isn't generally as strong as on other types of devices outside of the applications that specifically need it. I could be wrong of course about anything or everything.
I understand why. The extremely proprietary and platform specific nature of graphics APIs and hardware makes it hard. WebGPU is a good choice for portability.