I've been doing something of a deep dive into the suitability of WebGPU and WGSL for "serious" compute tasks (ie potentially competing with CUDA). Here's my take on the current state.
The upside is that it's very pleasant to program compared with existing APIs, and is portable. Even when the GPU doesn't quite meet the requirements, it's possible to polyfill compute shaders with SwiftShader. As this standard becomes more mature, it will be reasonable to expect that it will be correct and performant pretty much everywhere.
Note that both web and non-web implementations are viable.
The biggest drawback is that the "MVP" covers the basics of compute shaders but not the advanced features. It's roughly equivalent to DX11 / Shader Model 5, which is of course good for compatibility on pre-Windows 10 devices. It's missing subgroup operations, scalar types other than 32 bits, an explicit memory model, and some other goodies. This potentially leaves quite a bit of performance on the table, but that will depend on the exact workload. For example, machine learning inference workloads will probably suffer considerably due to the lack of f16. Thus, if you want to ship something based on compute shaders today, it makes sense to build your own portability layer on top of existing APIs such as Vulkan, DX12, and Metal.
I do think WebGPU is an excellent on-ramp to learning compute shader programming, as it will get stronger over time, and concepts will transfer to other APIs as listed above.
Watch my Twitter feed for more depth on the points I listed above.
Could someone correct me? I am pretty new to graphics programing but I was learning wgpu (the Rust binding of WebGPU) the other day. I was under the impression that the shader language is GLSL (version 450) and it is then converted into SPIR-V.
This is still in transition, and the full story is complicated.
The official shader language for WebGPU is WGSL, and that will almost certainly be the only language supported for web deployment. Originally this was going to be a textual representation that had exactly the same semantics ("bijective") as SPIR-V, but that's been diverging a bit[1]. Only very recently have atomics been added to the spec, and implementations are still catching up.
Because WGSL is still under construction, for native deployment, wgpu supports SPIR-V shaders as well. On Vulkan, those are passed pretty much straight through to the GPU driver (with some validation). On DX12 and Metal, those are translated into HLSL and MSL, respectively. Until recently, in wgpu, all those translations were handled by spirv-cross. More recently, the new naga crate is doing those translations. Again, this is under construction and not everything works yet.
> When writing SPIR-V, you can’t have two integer types of the same width. Or two texture types that match. All non-composite types have to be unique for some reason. We don’t have this restriction in Naga IR, it just doesn’t seem to make any sense. For example, what if I’m writing a shader, and I basically want to use the same “int32” type for both indices and lengths. I may want to name these types differently
This doesn't really make sense for IR. IR is not meant to be human writeable. It's meant to be generated by a compiler. So, having a one to one mapping between concept and name in the IR is a feature, not a bug.
Honestly, WGSL just repeats the JavaScript mistake: where we should have started with something like WASM instead of JavaScript. And JS could have been just one of the many languages that targeted WASM.
We were this close to not repeating this mistake by adopting an IR language (SPIR-V) for WebGPU, but then that got abandoned mostly for political reasons. Too bad. Now we get to write transpilers and hacks for decades to come, just like web people have been trying to paper over JS problems for decades.
> This doesn't really make sense for IR. IR is not meant to be human writeable. It's meant to be generated by a compiler. So, having a one to one mapping between concept and name in the IR is a feature, not a bug.
Do you consider the name for a type to be a part of the concept? SPIR-V doesn't.
Overall, if you wanted one-to-one mapping, at least that would be consistent. But SPIR-V decided to require this only for simple types, while you can still have duplicate composite types.
> Honestly, WGSL just repeats the JavaScript mistake: where we should have started with something like WASM instead of JavaScript. And JS could have been just one of the many languages that targeted WASM.
We don't know if Web would be nearly as successful if it started with WASM instead of JS. The ability to just open a text editor and make a web page has served well in the early days.
> We were this close to not repeating this mistake by adopting an IR language (SPIR-V) for WebGPU, but then that got abandoned mostly for political reasons.
Look at the situation today: the very same people who were rooting for SPIR-V are currently introducing features the diverge WGSL away from SPIR-V, further and further. It's quite telling, I think. The moral of the story is: regardless of reasons (which we can argue a ton), WG members admit that what we ideally need is not SPIR-V, and this is supported by the way WGSL is shaping.
> We don't know if Web would be nearly as successful if it started with WASM instead of JS. The ability to just open a text editor and make a web page has served well in the early days.
And you would be able to do that just fine. All you'd need to do is include the JS compiler (helpfully hosted at http://cdn.google.com/ecmascript-2015.wasm) in the <head> of the HTML file's script tag, open a text editor and type away. Or, you know, include a more sane language like typescript, or python. Heck even lisp if you're so inclined. Or, and this is like totally crazy, but say you need performance, and want tight control over memory layout and allocations, then go for C or rust! Oh and no need to minify your JS. Just ship the WASM precompiled. Save on browser compilation time and network bytes at the same time. So long as you generate WASM that the browser understands use whatever lang makes you happy. Type it right into a text editor and include the compiler in the head of the HTML. Easy peasy.
It's without question that JS has held back web development for decades. Of course, people didn't know any better back then, and really JS was added as almost an afterthought, so we can't really blame them for getting it wrong.
We do know better now though. And still we get WGSL. Looking forward to 2041, when we finally get WGASM. The hottest new thing in web gpu technologies.
I see. Thank you for the detailed information. I will read the linked content.
I don't know if this is a good place to ask. But I was interested in wgpu because of the interest in building a cross-platform non-web UI library. I read a few of your articles and also looked at druid. I am pretty new to it and there seems to be no books on this topic. Do you have any recommendations?
More seriously. There is very good reason to be encouraged about wgpu as a cross-platform low-level GPU drawing interface for UI work. There are already successful UI toolkits using it, of which probably the most impressive is iced.
For 2D graphics in general, a good starting point is Diego Nehab's 2D graphics course. It has links to a bunch of resources including papers on GPU rendering.
Of course, I'm working on my own stuff, which in time I hope will become a very strong foundation for building things such as UI toolkits, but it's not ready yet, and of course you're already aware of it.
Yes, I agree building a UI library from scratch is hard and probably not worthy doing (too many people tried and gave up in the middle; probably better to channel that enthusiasm on improving existing ones). I should state that more clearly. I was looking at something more modest, like a canvas implementation based on wgpu that enables others to build their UI libraries on top.
I guess it would be something like Skia, but it also sounds like a tremendous effort, and I could probably just use Skia instead. However, I guess I am not going to match what Skia has (maybe what HTML canvas has is enough?). Also, I have played with skia-safe crate but I personally feel the dev experience could be better (not to blame skia-safe, it's wonderful and even provides a build process that automatically downloads a precompiled skia library).
Thanks for pointing out Iced. I didn't know they are using wgpu under the hood. I will take a good look at their code. I have been reading nannou's code to learn how to work with wgpu. If we skip my last paragraph, I think building a UI library on top of nannou is pretty doable.
The shader language you write in does not matter, as it can be converted into whatever format the API expects.
wgpu historically accepts SPIR-V, but the latest version released ~a month ago has moved to WGSL as much as it can in the examples. Have you upgraded yet?
"Does not matter" is overstating the case. There are lots of tools for converting between shader languages (naga, spirv-cross, glslangValidator, dxc), but these conversions aren't 100% lossless and not all shader languages have the same capabilities. To give one example, HLSL (Shader Model 6) has a fairly complete set of subgroup (wave) operations, but is missing nonuniform shuffle. Another gap is that only GLSL (Vulkan flavor) has support for explicit memory semantics. Of course, WGSL currently has none of this, as it's something of a lowest common denominator.
In the game world, it is very common to write shaders in HLSL because of good support on Windows, and then use the tools mentioned above to translate into other shader languages. I explored this for my own work but ultimately settled on GLSL because it allows access to advanced features.
Fans of shader languages should also be aware of rust-gpu, which promises to be considerably higher level; most existing shader languages show their clear lineage to C (through Cg).
Do we know yet what the evolution and conditional-support mechanism is going to look like? Will there be "feature levels" like D3D, or ad-hoc independent extensions like interim GL, or some mix of the two?
Now that basically all relevant browsers are evergreen (sit down, IE11) I wonder whether an API roadmap could take advantage of that in a way that's less pesky than the traditional approaches.
Note that not even with the same browser version there are any guarantees regarding GPGPU support.
A big difference between browsers and native 3D APIs is the blacklisting of client hardware/drivers, so one never knows what is actually being accelerated.
Could you explain blacklisting? What does this mean? Couldn't there be an API to probe whatever information the developer needs to determine acceleration?
You'll probably be interested in section 3.6 of the spec[1], "optional capabilities." One such is timestamp queries, which I find especially annoying when they're not available.
Given the slow uptake on WebGL and the hit-and-miss on browser hardware support, I fear it will take several years for WebGPU to be an usable target beyond learning purposes.
I took the opportunity to base my visual computing project for this semester on the Rust WebGPU implementation (wgpu-rs). Working with it is very nice, compared to OpenGL and Vulkan. The biggest pain point right now is WGSL because it still is a moving target, but it's already good enough to work with in my case.
The repository for my project currently lacks any info at all unfortunately: https://github.com/niklaskorz/linon/
It is a ray caster that I plan to evolve into a nonlinear ray caster where the viewing rays travel along a vector field which thus distorts the image. You can enable the nonlinear mode by setting the "linear_mode" constant in "src/compute.wgsl" to false. I also implemented hot reloading for the shaders, which made experimenting a lot easier. The project doesn't have any non-Rust dependencies, so giving it a go is as easy as "cargo run" in the repository directory.
For an idea of what I'm aiming for, see the "Visualizing Strange Worlds" paper by Eduard Gröller from 1995: https://www.cs.drexel.edu/~david/Classes/Papers/Groller95.pd...
You can also drag&drop .obj models to load them, but I advise you to only use small models (500 triangles max) in linear mode and completely avoid it in nonlinear mode right now, as the performance is really bad at the moment. :)
I'm looking into acceleration structures next, so hopefully this will improve.
You can trigger some insane GPU bugs from just user-space programs, and while using the WebGPU Python wrapper, I’ve managed to completely corrupt the screen buffer (which required a restart), completely frozen the GPU, and can consistently trigger denial of service attacks. I can guarantee that WebGPU opens a huge attack space that is relatively unexplored.
The current implementations are heavy WIP and incomplete. The fact that you managed to screw them up is not a big surprise. Once all of the safety and validation work is done, we'll need to check again and see.
Those bugs are in the graphics drivers, not in the WebGPU implementation. Any remotely powerful GPU interface will probably be able to talk to the drivers in a way that will exploit those bugs. On the other hand, if you artificially restrict the interface so those bugs are out of reach, it will probably not be powerful enough for what it wants to be.
Graphics card vendors will have to step up their game and improve their drivers.
I cannot speak to the feasibility of such a thing, but it feels a lot like OS vendors should be very seriously looking into moving GPU drivers away from the kernel and into userspace. GPUs are increasingly looking like a massive hole in otherwise secure systems, even without the added possibilities of GPUs being exposed to the web.
Windows has already done that for a while now, macOS is doing that for all drivers, Android has Treble, is the BSDs and Linux kernel that are still stuck with monolithic designs.
Isn't macOS still using kernel extensions (kexts) for GPU drivers? That might not technically be in the kernel itself but it's still pretty close and certainly not userspace.
Keeping the drivers in the Linux kernel means they're covered by the GPL. It's the only reason some of the drivers are decent, otherwise GPU manufacturers would all do what Nvidia and Qualcomm do.
It feels like this is something a "Web-" prefixed API should protect us from.
I'm curious if such catastrophic behaviour is inherent to the WebGPU API as specified, or of the current implementation is failing to provide the level of safety that it should according to the spec?
> It feels like this is something a "Web-" prefixed API should protect us from.
It's worth noting here that the Python wgpu library (which I'm assuming is the one GP is referring to?) is a WebGPU-inspired API to wgpu. wgpu is the library that Mozilla created as a native graphics abstraction layer to build WebGPU on top of. It's possible that Mozilla has implemented (or intends to implement) the security/validity checks between wgpu and the JavaScript interface exposed to the browser, in which case they would not automatically apply to the Python bindings.
wgpu is work in progress, we don't have all the validation in place yet. Also, it's not a Mozilla project, it's a part of gfx-rs work by Rust community.
Was always separate. There was a movement towards trying to make Mozilla-Central an upstream for it, but it hasn't happened. So technically right now it's a community project used by Firefox.
Working Drafts are essentially just "drafts with stable URLs for review purposes and historical interest".
First Public Working Drafts also have consequences under the W3C Patent Policy, primarily starting a timer under which any participant of the group has to say they wish to exclude any patents they hold from the W3C royalty-free grant.
Idk if WebGPU will ever be fully supported by enough browsers to be viable for the web. Even if it is eventually supported people are saying it will take 10+ years.
I do think WebGPU can be a great cross-platform compute shader framework outside of the web. My experience with compute shaders is that they're really really platform specific: you need not just the right OS, but also the right graphics chip. It would be nice to write cross-platform high-end 3D apps without relying on Unity or Unreal.
Also, hopefully WebGPU has better debugging tools (if they're even possible). I tried GPU programming before but it's a mess: almost every example I tried to run crashed terribly (e.g. system reboot), and even at best, I couldn't get much debugging output other than "code = problem".
Who is saying that? Genuinely curious. It has strong buy-in from Apple, Google and Mozilla, and all 3 are implementing the spec right now (and updating implementations as the spec changes). Seems very doubtful that it'd take anywhere near 10 years to be supported by major browsers. I guess it depends on what subset of graphics/compute features you need for it to be viable for your specific use case.
Ok, maybe not 10 years. But look at WebGL2. From wikipedia:
> Development of the WebGL 2 specification started in 2013 with final in January 2017
Moreover, WebGL2 support was only added to Edge since January 2020, and as of now it's still not supported in Safari (excluding Safari TP) (from https://caniuse.com/webgl2).
I don't think you's want to use WebGL2 as an analogue here. Radically different depth and breadth of buy-in across the browser ecosystem. I'm no expert, but I'm genuinely curious where you got the 10+ year figure from (is there an up-to-date estimate/roadmap from any of the people working on this?). I was under the impression that we'd see an MVP stabilise relatively soon (i.e. within a couple of years at most). Of course, there will still be features being added in 10 years time, since graphics APIs and GPUs are always evolving.
WebGL spec came about reasonably fast but took a very long time to become robust and well supported across all OS/hw/browser combos. Go read hn comment threads on webgl submissions and count people complaining about os or browser caches.
GPU drivers are really buggy, especially if you try to cope with what is installed vs prompting users to upgrade their os or drivers.
Tried attaching pix to chrome the other day. And it was not a pleasant experience, eventually just gave up. When mentioned in the meetup it kinda seemed like a tounge in cheek answer as in it is technically possible...
I imagine that this, in addition to WebAssembly, could lead in the future to playing more complex games from the browser with the benefit of being platform agnostic (in kind of device, hardware architecture, OS) as long as the browser, the OS, and the hardware is compatible. Am I wrong?
The main problem isn't CPU and GPU performance, those problems had (to some extent) already been solved with asm.js and WebGL, at least for some types of games. It's all the other APIs and the general "feature churn" in browsers which are problematic for games.
Some examples:
- The fullscreen and pointerlock APIs show popup warnings which behave entirely differently between browsers.
- Timer precision has been reduced to around 1ms post-Spectre/Meltdown, and jittered on top. This makes it very hard to avoid microstuttering (we don't even need a high-precision timer, just a way to query the display refresh rate... but guess what, there is no way to query the display refresh rate)
- WebAudio is ... I don't even know what... all we need is simple buffer streaming but we got this monstrosity of a node-based audio API. And the only two ways to do this in WebAudio are either deprecated (ScriptProcessorNode) or not usable without proper threading (audio worklets), and guess what, threading is also disabled or behind HTTP response headers post-Spectre.
- Games need UDP style non-guaranteed networking, but we only get this as a tiny part of WebRTC (DataChannels).
...and the list goes on. In theory there are web APIs useful for gaming, but in practice those APIs have been designed for entirely different and very specific high-level use cases (such as creating an audio synthesizer in a webpage, or creating a video chat solution for browsers), and those rigid high-level APIs are not flexible enough to be reassigned to different use cases (like games). The web needs a "game mode", or better a "DirectX initiative", a set of low level APIs and features similar to WASM and WebGL/WebGPU, and if not designed specifically for games, than at least low-level and generic enough to be useful for games.
This isn't a new idea, see the Extensible Web Manifesto:
It's not just very hard to avoid microstuttering. It's quite literally impossible. And it's not just the timer precision. Chrome's `requestAnimationFrame` actually provides a full precision frame start time, but even if all your page does is render a single solid-color triangle (that alternates between cyan and magenta every frame), you still cannot avoid microstuttering, because the compositor will periodically drop frames. Ironically, the browser engines on mobile phones seem to do better, presumably because of limited multitasking.
Source: I've spent more hours than I care to admit trying to avoid dropped frames in https://sneakysnake.io . To see how bad it remains, check out the triangle in the bottom left corner of https://sneakysnake.io?dev=true . If it looks anything other than grey, then the browser is dropping frames.
> threading is also disabled or behind HTTP response headers post-Spectre
It seems like you've written a long-winded complaint that you have to add a http header (like this[0]) to your server's response? Though it's true that the Spectre stuff broke everything for a little while there (and there are still ergonomics-related teething problems with headers that are being worked on).
> Games need UDP style non-guaranteed networking, but we only get this as a tiny part of WebRTC (DataChannels).
WebRTC DataChannels work fine though? Does it matter that it's a small part of the whole WebRTC spec or that server-client use is a bit of a hack? Either way, WebTransport hits origin trial in Chrome in about a week, and it's specifically designed for UDP-like client-server communication, so the WebRTC approach can be swapped out once that is stable.
Ruffle developer here. A good chunk of our incoming issue volume used to be "how do we configure the WASM mime type" disguised in various "omg it doesn't work, what does this error mean" type issues. This is because we were using WASM's instantiateStreaming function to load our module, which requires valid HTTP headers on the WASM file which most web servers weren't configured to produce. Adding a fallback to a slower WASM load approach that doesn't require a header made all those complaints go away.
In our experience the average webmaster does not know how to configure proper HTTP headers and should not be expected to for a basic web library. So any web API that will not work with the standard web server configurations of Apache, nginx, or IIS is a non-starter for us. (Not to mention that the site isolation headers have non-trivial implications for sites that use iframes...)
That's a fair point. I hope you're involved in the spec discussions around these topics! There's definitely room for improvement in terms of ease of use.
> We've been exploring ways to deploy Cross-Origin-Resource-Policy at scale, as cross-origin isolation requires all subresources to explicitly opt-in. And we have come up with the idea of going in the opposite direction: a new COEP "credentialless" mode that allows loading resources without the CORP header by stripping all their credentials. We are figuring out the details of how it should work, but we hope this will lighten your burden of making sure the subresources are sending the Cross-Origin-Resource-Policy header.
> It seems like you've written a long-winded complaint that you have to add a http header (like this[0]) to your server's response?
So how does this work on Github Pages or other hosting solutions where the user has no control over the web server configuration?
> WebTransport hits origin trial in Chrome in about a week
How long until this shows up in Firefox, and will Safari ever support this before it's deprecated in Chrome again because another better solution shows up?
Spectre called for some drastic measures, and it'll be up to Github/Netlify to decide how they react. Developers who want simple hosting solutions for their little projects will host elsewhere (e.g. replit.com, glitch.com) if they need to. This isn't exactly a massive obstacle if you've set out to build a complex game in the browser. It's just a couple of headers...
>How long until this shows up in Firefox
WebRTC data channels work fine in the mean time. Have you seen games like krunker.io and dotbigbang.com et al? It's perfectly possible to create real-time games in the browser using WebRTC.
> This isn't exactly a massive obstacle if you've set out to build a complex game in the browser.
It is an obstacle (at least a massive annoyance) for library authors (like this: https://github.com/floooh/sokol). Those libraries can be used for extremely simple and small WASM snippets embedded in blog posts (like here: https://floooh.github.io/2019/01/05/wasm-embedding.html), or in "proper" games hosted through "proper" hosting services which allow to set the response headers.
Right now the choice is to either support WASM threading, but tell library users that the library will most likely not work on the hosting solution of their choice, or not support WASM threading and work everywhere. At least to me it's clear that "works everywhere" is better than "it's complicated", so I'll ignore WASM threading until the problem is solved somehow (either most hosting services turn on those response headers, or there's another way to enable threading without requiring control over the web server configuration).
And we’re using WebSockets right now for the networking in dot big bang! Although we’ve talked a lot about moving to WebRTC we’ve not gone as far as doing it yet.
More generally things get a lot simpler if you’re “web first”. It’s a lot easier to just be pragmatic about it and build when you’re not straight jacketed by existing designs reliant on common low level OS APIs.
WebRTC is designed for client to client architecture. We want to use it in a dedicated server architecture. WebRTC is not designed to integrate into kubernetes. Ultimately, this has pushed us to stay on websockets and try to handle TCP congestion. We have theorized a network architecture that could use webrtc in our cluster, but it involves routing data out to a TURN/STUN server and back in, which would cost a lot more due to paying double for egress/ingress.
Overall, WebRTC is a poorly designed protocol which will be quickly obsoleted.
What does WebRTC--or any protocol for that matter--have to do with your container solution? When I develop a protocol now, do I have to "design it to integrate into kubernetes"?! FWIW, WebRTC works great for client-to-server deployment, as using it like that means you don't have to worry at all about the oft-cited peer-to-peer NAT incompatibility issues.
The issues that we ran into were related to the port range that WebRTC attempts to use.
If I understand it correctly, WebRTC requires you to open a range of thousands of ports and kubernetes load balancers are designed to forward individual ports to individual services.
Basically at the end of the day what happened was that the Web people killed Flash, slowed online gaming for 10 years, while nowadays everyone that cares about games moved into native mobile gaming.
It is quite telling that the cloud gaming efforts rather render everything server side with video streaming for the browser than fixing the games APIs on the browser.
Maybe worth noting that Deno 1.8 has WebGPU support[1]. Deno's quest to be the web-platform compatible alternative to Node is expansive & impressive!! I have high hopes for it!
It's a successor to WebGL, along the lines of newer graphics APIs like Metal/Vulkan/DirectX 12. Google and Mozilla are also developing a C-compatible library that should be available as an OpenGL alternative for native code.
So if successful it might end up as the most convenient cross-platform graphics library (across desktop/mobile/the web). Currently the alternatives in this space are:
- OpenGL (which Apple has deprecated and is stuck on an older version on their platforms)
- Vulkan, which is the lowest level and most difficult to get started on of the APIs, and also doesn't work on the web, but is supported on Apple systems by using the MoltenVK library to translate it to Metal
- some non-standardized libraries written by third party developers like bgfx and Oryol.
For the shading language they settled on a text based language designed to be easily translatable to/from Vulkan SPIR-V bytecode, with the goal of being able to re-use existing shader compilation toolchains (and most of the work put in to SPIR-V), while still having the ability to write/read shaders without a shader compiler. Also SPIR-V files are fairly large and apparently don't compress well with standard algorithms (see SMOL-V) so the text based format should probably be more efficient to transmit on the web.
> Google and Mozilla are also developing a C-compatible library that should be available as an OpenGL alternative for native code.
To clarify, Google and Mozilla are both developing separate libraries: Dawn (in C++) and wgpu (in Rust) respectively. Both are designed to be usable behind the same native C API - https://github.com/webgpu-native/webgpu-headers
> For the shading language they settled on a text based language designed to be easily translatable to/from Vulkan SPIR-V bytecode
A question, I was wondering if you happen to know whether there is a long term commitment from these orgs/companies to support WebGPU, say for at least 10 years?
If it's approved as a web standard, I would expect them to support it basically forever, since otherwise websites would stop working. I don't think there's any plan to deprecate the previous standard (WebGL) that came out around 10 years ago.
> I don't think there's any plan to deprecate the previous standard (WebGL) that came out around 10 years ago
There's basically zero uncertainty around this. It would break the internet. As you probably know it's extremely difficult to make even tiny backwards-incompatible changes to features that have become web standards and have been implemented on all major browsers.
Don't hold your breath in anticipation of an updated WebGL standard. WebGPU seems to have a lot more support these days and is a bit closer to DX12, Vulkan and Metal in its concepts, so easier to implement in theory.
At this point, I'm not even waiting for a new OpenGL version anymore. The good stuff has been mostly Vulkan exclusive for a while now.
it will hardly come, but most people learning 3D are better suited with modern OpenGL or some middleware built on top of last generation APIs.
With Vulkan Khronos keeps the OpenGL tradition of leaving as rite of passage to learn everything from scratch, while hunting for libraries, because community.
Don't expect Vulkan SDK to provide the confort of Metal Kit, DirectXTK, Playstation PhyreEngine, ....
I guess most WebGL development currently happens in Safari, because Safari is switching from their own WebGL implementation to ANGLE. Other then that, AFAIK there is no "WebGL 2.1" or "WebGL 3" planned.
I'm looking at the complex specs of the shading language which accomplish almost the same thing as other modern high level shading languages, and thinking is there any possibility we'll reach a state of consensus on a single unified GPU graphics interface? Right now things seem to go more fragmented instead of unified, we moved away from "cross-platform" OpenGL to extremely vendor specific Vulkan, Metal, D3d and WebGPU, looks like cross platform graphics programming is becoming more and more far away, have to rely on abstraction layer which are often huge dependencies and tedious to develop / maintain.
Thanks for the article it's a great write up! Do you mean it's possible in the future venders will ship WebGPU drivers built in their product (couldn't find any evidence on that yet) or it's the best option for the interface of a translation layer like wgpu? Right now wgpu is already pretty solid as a translation layer, but direct driver support will be so good. (Also thanks for your works on Rust graphics related stuff! They benefit me a lot)
I don't expect any driver support for this in the nearest future. The promise of WebGPU on native is not in wgpu library quality, although it's a part of the equation. The promise is in a well-thought specification (of WebGPU API) and the standardized API headers with multiple implementations. This matches best practices from Khronos.
The irony is that with OpenGL and WwbGL getting left behind, graphics programming becomes a bit more uniform across platforms as a result, even though the underlying APIs are different. They are based on very similar modern concepts. OpenGL on the other hand really shows its age and isn't a good fit anymore. Some newer things have been bolted on awkwardly over time, but they are either optional extensions or part of versions that are newer than what certain target platforms actually support.
Looking at the various rendering backends for our product, the OpenGL backend is the most byzantine one. The Vulkan backend has more code, but all of that is fairly sane. It doesn't have accidental complexity like having to pick the right GL function to upload a specific texture out of about a dozen possibilities depending on the texture type and target OpenGL version/extensions.
I don't, given that I did my thesis in porting a particle system from NeXTSTEP to Windows in OpenGL back in 1999, and am relatively confortable with Khronos APIs.
The only thing that saves Vulkan is that it isn't as old as OpenGL, with a similar timeframe it will get just as bad, or even worse given its complexity for the average graphics programmer that doesn't hold a master on GPGPU hardware design to understand the nuances of all those extensions.
From the start WebGPU has been build with native use in mind, so ideally you'd just target WebGPU for both your web and native builds. The WebGPU native implementation can then drive the native graphics API for your system (and one day perhaps we'll see WebGPU at the driver level)
Do you mean they're thinking "this can easily be translated to other graphic interfaces" or "we're going to convince vendors to ship products with WebGPU driver built-in like OpenGL"? I'll be so happy to see WebGPU on driver level, but can't find evidence on if anyone is interested in providing.
Expect having to ship a WebGPU implementation with your application, similar to how you need to include ANGLE for WebGL support. A platform level API needs a lot of additional considerations about plumbing layers between applications and one or more separately installed drivers. I don't see this addressed for WebGPU.
That is very ugly and full of noise, c'mon people, that's one thing to like rust, but let's not import its ugly and noisy cluttered syntax..., it took me few seconds to understand what's going on there
---
var<private> x: f32;
---
let's not confuse things even more, we have vec4<f32> already, C'MON PEOPLE
It's really not that bad. I had some complaints about WGSL a few months ago but it was surprising how quickly it improved. Here are some simple real-world shaders you can look at:
If you combine it with a quick build step to give you shader compilation errors before your program runs, it becomes a pretty nice shading language. There are still a few rough edges but it's not _that_ bad to work with.
This is very similar to what you'd write in HLSL, except maybe for `[[stage(fragment)]]` part (since this information is provided externally in HLSL) and `vec4<f32>` instead of `float4`. Are these the only things you are concerned about? If so, then I'd be happy with this, given that it's an artificial example.
I was looking under security and I don’t see any mention of misuse, but that can also be hard to identify.
Potential misuse should not stop WebGPU from moving forward, but isn’t there a concern that the make JavaScript injection attacks more attractive? Rather than buying and operate a crypto mining setup it now becomes more attractive to attempt to utilize the GPUs of unsuspecting web users. Or am I misunderstanding how much of the GPU this will grant you access to?
The GPU is already accessible to JavaScript through WebGL. WebGPU should hopefully be somewhat faster in many cases, and simpler to use with a simpler/less buggy implementation. But it's not really exposing a ton of attack surface that's not already available in WebGL. Things like coin mining are already possible with WebGL, and a small-to-medium sized speed boost isn't going to change much.
Neither WebGL nor WebGPU will today give you 100% of native (e.g. CUDA) performance for applications like coin mining or machine learning. And even WebGPU may never get all the way there, at least in a form that can be exposed in browsers, because top performance requires deep knowledge of the user's specific hardware configuration and specialized hardware-specific code paths. Exposing that to the web raises legitimate fingerprinting and portability concerns.
That said, I think there is a lot of promise for WebGPU as a portable graphics API for native applications outside of browsers, where said fingerprinting and portability concerns are much less of an issue. In a native context, hardware-specific extensions could easily be exposed and there's no reason in theory why you couldn't have the best performance possible on any given hardware.
> The GPU is already accessible to JavaScript through WebGL.
Mine isn't. Disabling WebGL is DEFINITELY on the checklist for a new browser profile
GPUs are way too complicated, way too opaque, and way too privileged to be safely exposed to the Web. We're not talking about some Web page using your machine to mine crypto here. We're talking about some Web page owning your kernel.
WebGL has been part of browsers for many years now and the security track record is public. This fear has not proven true in reality. Overall, WebGL has not had more or worse security problems than other components of the browser. Great care has been taken to properly isolate and sandbox WebGL, far in excess of what any other graphics API has ever had in terms of security. WebGPU in browsers will have the same level of protection.
Your machine is way more likely to get owned through some bug parsing a dumb string. Anything your browser displays ends up in the graphics driver, one way or another. WebGL is arguably a much smaller surface to deal with than all the code involved in rendering a web page efficiently.
I find interesting that WGSL is clearly influenced by Rust.
GSL and WGSL are completely unrelated, apparently time to rewrite shaders.
And in what concerns debugging, better get good at understanding what is the actual application code and browser own rendering engine, as the best solution keeps being to use native GPGPU debuggers.
This isn't actually the reason. The first draft of WGSL, proposed by Google team, already had Rust-like syntax. As far as I'm aware, nobody from that team had any significant work done in Rust.
So the long march towards the "other" future continues ...
Failure #1: to get operating systems to ever agree on a truly common API for most modern computing
Failure #2: to implement a write-once, run-anywhere language capable of being used for the majority of software development (mostly because the main efforts at doing so all rely on VMs that come with their own costs and benefits)
Conclusion: just give up. Postulate the existence of a virtual machine inside a web browser. Spend a decade or three slowly extending the scope of that virtual machine. Put in a little bit of effort to persuade people that this new, evolving VM is the new key to "write once, run anywhere".
Result: a new platform, distinct from all the rest (i.e. "native") with its own costs and benefits.
It would be cool if the shading document has an example ... just diving into details makes it hard to get the flavor. Anyone have a smallish SL example?
Are webGL and webasm mining "omnipresent" in web pages? What does that even mean exactly?
You can turn off local storage, cookies, sound and javascript itself in per page permissions, you think every web page is going to have an unavoidable crypto currency miner embedded in it when webGPU becomes more common?
Do you think that people won't be able to see that a specific iframe is using 99% of their GPU or do you think people will just live with it and won't care?
This benchmark has little to do with the first public draft of the API we are discussing. Safari's old implementation hasn't been updated in years, and it's probably missing all the safety checks we'll need to ship this, such as array out-of-bound access handling.
Yuck. So now there's 3 of them. What's wrong with GLSL? HLSL? Somebody link that xkcd about competing standards.
But seriously, why do they reinvent the wheel? Either make javascript work on the GPU (because that's the language of the web, just like C++ and Cuda go hand in hand), or just stick with HLSL.
Apple has tried to collaborate with Microsoft on making HLSL viable for the Web and standardizing it. IIRC, we figured that we can't accept HLSL as is anyway, and we'd have to develop a flavor of it for the Web, in which case the point about using an existing language becomes moot.
Control-flow oriented languages like JavaScript are not a good fit for GPUs. That's the accepted belief, at least.
Allegedly GLSL and HLSL do not come with enough protections / guarantees for anyone to have felt comfortable porting them to the web. That rules them out cleanly.
Also, these are both fairly legacy technologies, both predating Vulkan by a good bit more than a decade. WebGPU at it's core is a remake of Vulkan for the web. Then there's a shading language that works with this base. My understanding is this is a far more competent, capable means of setting up & orchestrating work, so that it can happen & flow effectively on GPUs. Doing less than WebGPU sounds supremely unappealing.
The upside is that it's very pleasant to program compared with existing APIs, and is portable. Even when the GPU doesn't quite meet the requirements, it's possible to polyfill compute shaders with SwiftShader. As this standard becomes more mature, it will be reasonable to expect that it will be correct and performant pretty much everywhere.
Note that both web and non-web implementations are viable.
The biggest drawback is that the "MVP" covers the basics of compute shaders but not the advanced features. It's roughly equivalent to DX11 / Shader Model 5, which is of course good for compatibility on pre-Windows 10 devices. It's missing subgroup operations, scalar types other than 32 bits, an explicit memory model, and some other goodies. This potentially leaves quite a bit of performance on the table, but that will depend on the exact workload. For example, machine learning inference workloads will probably suffer considerably due to the lack of f16. Thus, if you want to ship something based on compute shaders today, it makes sense to build your own portability layer on top of existing APIs such as Vulkan, DX12, and Metal.
I do think WebGPU is an excellent on-ramp to learning compute shader programming, as it will get stronger over time, and concepts will transfer to other APIs as listed above.
Watch my Twitter feed for more depth on the points I listed above.