Bindless is pretty much _the_ most important feature we need in WebGPU. Other stuff can be worked around to varying degrees of success, but lack of bindless makes our state changes extremely frequent, which heavily kills performance with how expensive WebGPU makes changing state. The default texture limits without bindless are also way too small for serious applications - just implementing the glTF PBR spec + extensions will blow past them.
I'm really looking forward to getting bindless later down the road, although I expect it to take quite a while.
By the same token, I'm quite surprised that effort is being put into a compatibility mode, when WebGPU is already too old and limiting for a lot of people, and when WebGL(2) is going to have to be maintained by browsers anyways.
> Bindless is pretty much _the_ most important feature we need in WebGPU. Other stuff can be worked around to varying degrees of success, but lack of bindless makes our state changes extremely frequent, which heavily kills performance with how expensive WebGPU makes changing state.
Yes.
This has had a devastating effect on Rust 3D graphics. The main crate for doing 3D graphics in Rust is WGPU. WGPU supports not just WebGPU, but Android, Vulkan, Metal, Direct-X 12, and OpenGL. It makes them all look much like Vulkan. Bevy, Rend3, and Renderling, the next level up, all use WGPU. It's so convenient.
WGPU has lowest common denominator support. If WebGPU can't do something inside a browser, then WGPU probably can't do it on other platforms which could handle it. So WGPU makes your gamer PC perform like a browser or a phone. No bindless, no multiple queues, and somewhat inefficient binding and allocation.
This is one reason we don't see high-performance games written in Rust.
After four years of development, WGPU performance has gone down, not up. When it dropped 21% recently and I pointed that out, some people were very annoyed.[1]
Google pushing bindless forward might help get this unstuck. Although notice that the target date on their whiteboard is December 2026. I'm not sure that game dev in Rust has that much runway left. Three major projects have been cancelled and the main site for Rust game dev stopped updating in June 2024.[2]
> This is one reason we don't see high-performance games written in Rust.
Rendering is _hard_, and Rust is an uncommon toolchain in the gamedev industry. I don't think wgpu has much to do with it. Vulkan via ash and DirectX12 via windows-rs are both great options in Rust.
> After four years of development, WGPU performance has gone down, not up. When it dropped 21% recently and I pointed that out, some people were very annoyed.[1]
Performance isn't most of the wgpu maintainer's (who are paid by Mozilla) priority at the moment. Fixing bugs and implementing missing features so that they can ship WebGPU support in Firefox is more important. The other maintainers are volunteers with no obligation besides finding it enjoyable to work on. Performance can always be improved later, but getting working WebGPU support to users so that websites can start targeting it is crucial. The annoyance is that you were rude about it.
> Google pushing bindless forward might help get this unstuck. Although notice that the target date on their whiteboard is December 2026.
The bindless stuff is basically "developers requested it a ton when we asked for feedback on features they wanted (I was one of those people who gave them feedback), and we had some draft proposals from (iirc) 1-2 different people". It's wanted, but there are still major questions to answer. It's not like this is a set thing they've been developing and are preparing to release. All the features listed are just feedback from users and discussion that took place at the WebGPU face to face recently.
WGPU dev here. I agree with everything JMS55 says here, but I want to avoid a potential misunderstanding. Performance is definitely a priority for WGPU, the open source project. Much of WGPU's audience is very concerned with performance.
My team at Mozilla are active contributors to WGPU. For the moment, when we Mozilla engineers are prioritizing our own work, we are focused on compatibility and safety, because that's what we need most urgently for our use case. Once we have shipped WebGPU in Firefox, we will start putting our efforts into other things like performance, developer experience, and so on.
But WGPU has other contributors with other priorities. For example, WGPU just merged some additions to its nascent ray tracing support. That's not a Mozilla priority, but WGPU took the PR. Similarly for some recent extensions to 64-bit atomics (which I think is used by Bevy for Nanite-like techniques?), and other areas.
WGPU is an open source project. We at Mozilla contribute to the features we need; other people contribute to what they care about; and the overall direction of the project is determined by what capable contributors put in the time to make happen.
> But WGPU has other contributors with other priorities. For example, WGPU just merged some additions to its nascent ray tracing support. That's not a Mozilla priority, but WGPU took the PR. Similarly for some recent extensions to 64-bit atomics (which I think is used by Bevy for Nanite-like techniques?), and other areas.
Yep! The 64-bit atomic stuff let me implement software rasterization for our Nanite-like renderer - it was a huge win. Same for raytracing, I'm using it to develop a RT DI/GI solution for Bevy. Both were really exciting additions.
The question of how performant and featureful wgpu is is mostly just a matter of resources in my view. Like with Bevy, it's up to contributors. The unfortunate reality is that if I'm busy working on Bevy, I don't have any time for wgpu. So I'm thankful for the people who _do_ put in time to wgpu, so that I can continue to improve Bevy.
> Rendering is _hard_, and Rust is an uncommon toolchain in the gamedev industry. I don't think wgpu has much to do with it. Vulkan via ash and DirectX12 via windows-rs are both great options in Rust.
Yes. I think I'm beginning to see what's gone wrong with the Rust crates. It's an architectural problem.
Vulcano and WGPU try to create a Rust safety perimeter at an API that's basically a wrapper around Vulkan. This may be the wrong boundary for that safety perimeter.
Moving buffer allocation inside the safety perimeter may eliminate a level of locking and checking. Bindless really brings this out, because somebody has to keep the descriptor table and buffer allocation in sync. The GPU depends on that. So that has safety implications.
If this problem is partitioned differently, the locking problems for concurrent GPU content updating may become simpler. Right now, both Vulcano and WGPU force more serialization than Vulkan itself requires. The rendering thread is too often stalled on a lock waiting for some content updating operation that should not interfere with rendering.
Too much detail for this forum. I'll continue this elsewhere. This has been useful.
Back in the day I did a similar error with wrapping C graphic libraries directly 1:1 with improved C++ bindings, until I realised it was more ergonomic to think in higher level C++ abstractions, and exposed those concepts instead, fully hiding the underlying unsafe C APIs.
WGPU has to decide, either stay compatible with WebGPU, and thus be constrained by the design of a Web 3D API, or embrace native code and diverge from WebGPU.
But even more, the level at which WebGPU exists (not too high level, not too low level) necessitates that if a native API graphics abstraction sticks with the WebGPU's API design and only 'extends' it, you actually end up with three totally different ways to use the API:
* The one with your native 'extensions' -> your app will only run natively and never in the browser unless you implement two different WebGPU rendering backends. Also won't run on Chromebook-type devices that only have GLES-era hardware.
* The WebGPU browser API -> your app will run in the browser, but not on GLES-era hardware. Perish in the verbosity of not having bindless support.
* The new 'compatability' mode in WebGPU -> your app runs everywhere, but perish in the verbosity of not having bindless, suffer without reversed-z buffers because the underlying API doesn't support it.
And if you want your app to run in all three as best as possible, you need to write three different webgpu backends for your app, effectively, as if they are different APIs and shading languages.
> The WebGPU browser API -> your app will run in the browser, but not on GLES-era hardware. Perish in the verbosity of not having bindless support.
Note, regarding "GLES-era": WGPU does have a GLES/WebGL2 backend; missing WebGL1 is unfortunate, but at least it covers most recent browsers/hardware that happens to not have WebGPU supported yet.
(and there's necessarily some added overhead from having to adapt to GLES-style api; it's especially silly if you consider that the browser might then convert the api calls and shaders _again_ to D3D11 via ANGLE)
There's a *massive* difference in capabilities between GLES3.0 (e.g. WebGL2) and D3D11 though (GLES3.0 is more like 'late D3D9 era') ;)
And interestingly, WebGL2 in Chrome on Windows (which runs on top of D3D11) handily beats WebGPU in some of my tests (with setBindGroup being the bottleneck).
Is WGPU even a Mozilla project? I think he is just saying that those paid developers (paid by Mozilla) have that priority, and everyone else is volunteer. Not that WGPU is a Firefox project.
There have been a bunch of significant improvements to WGPU's performance over the last few years.
* Before the major rework called "arcanization", `wgpu_core` used a locking design that caused huge amounts of contention in any multi-threaded program. It took write locks so often I doubt you could get much parallelism at all out of it. That's all been ripped out, and we've been evolving steadily towards a more limited and reasonable locking discipline.
* `wgpu_core` used to have a complex system of "suspected resources" and deferred cleanup, apparently to try to reduce the amount of work that needed to be done when a command buffer finished executing on the GPU. This turned out not to actually save any work at all: it did exactly the same amount of bookkeeping, just at a different time. We ripped out this complexity and got big speedups on some test cases.
* `wgpu_core` used to use Rust generics to generate, essentially, a separate copy of its entire code for each backend (Vulkan, Metal, D3D12) that it used. The idea was that the code generator would be able to see exactly what backend types and functions `wgpu_core` was using, inline stuff, optimize, etc. It also put our build times through the roof. So, to see if we could do something about the build times, Wumpf experimented with making the `wgpu_hal` API use dynamic dispatch instead. For reasons that are not clear to me, switching from generics to dynamic dispatch made WGPU faster --- substantially so on some benchmarks.
Animats posts frequently about performance problems they're running into, but when they do it's always this huge pile of unanalyzed data. It's almost as if, they run into a performance problem with their code, and then rather than figuring out what's going on themselves, they throw their whole app over the wall and ask WGPU to debug the problem. That is just not a service we offer.
He's reporting a 23% drop in performance and seems to have invested quite some time in pinning down what's causing it, plus he's provided a repro repository with benchmarks.
I honestly don't get your annoyed response; any OSS project wishes they had such detailed bug reports, and such a performance regression would concern me very much if it happened in a project I maintain.
What? They even provided a benchmarking tool. You should be ecstatic at users providing such detailed reports. Most projects just attract reports that go like "its slow, fix it!!111"
> When it dropped 21% recently and I pointed that out, some people were very annoyed.[1]
Someone was seemingly "annoyed" by an impatient end-user asking for an status update ("It's now next week. Waiting.") and nothing more. They didn't seem to be annoyed about that you pointed out a performance issue, and instead explained that their current focus is elsewhere.
Tbh I was annoyed reading it too as an open source developer. The people you are talking to are volunteering their time, and you weren’t very considerate of that. Open source software isn’t the same support structure as paid software. You don’t file tickets and expect them to be promptly fixed, unless you do the legwork yourself.
Tbf, tons of games have been created and are still being created without bindless resource binding. While WebGPU does have some surprising performance bottlenecks around setBindGroup(), details like that hardly make or break a game (if the devs are somewhat competent they'll come up with ways to workaround 3D API limitations - that's how it's always been and always will be - the old batching tricks from the D3D9 era still sometimes make sense, I wonder if people simply forgot about those or don't know them in the first place because it was before their time).
Nobody forgot about batching. It's a foundational strategy in any efficient realtime renderer. The bar has simply moved and even the cheaper binding logic you get from Vulkan or D3D12 is getting too expensive for the object counts we're trying to push in modern games.
Bindless lets you reduce the amount of book keeping you have to do per-object on the CPU, but much more importantly opens the door for GPU driven rendering.
The problem with WebGPU is there's no bindless and the 'bindful' path is quite expensive to meet the safety requirements of a browser API. There's no way around the slow path, and the slow path is quite slow. In this case the workaround is cut features because the API simply imposes too much overhead.
BindGroups being a hard to fix design wart is true indeed (which I have been complaining about pretty much from the beginning, not because of the performance problems - which surprised me too - but because of their inflexibility compared to a traditional bindslot based model like in Metal1 or D3D11).
But I would prefer to first bring the peformance of the slot-based binding model to a point where it is similar to D3D11 or Metal instead of ignoring that part of the API and 'skipping ahead' to bindless (which will probably have to be behind an extension anyway). Otherwise WebGPU will become a cemetery of abandondend attempts like OpenGL.
As far as I know, Unity doesn't support bindless either. However thousands of Unity games are released on Steam every year. So it's safe to say performance isn't the main (or major) reason why Rust gamedev isn't getting much traction.
The lack of traction is mostly because Rust game development, with exception of Bevy efforts, it is still pretty much on the dark ages of everything is code.
The industry has moved beyond that, with teams where programmers only have a minor role (quite important nontheless), on the whole game design, with plenty of tooling for designers and other non-programmer folks to do their tasks.
Eventually with more graphical tooling, or scripting systems, it will start to gain more steam.
Note that TinyGlade also created most of their tooling in-house, they only partially depend on Bevy.
Another reason is that exploratory programming is hard by design in Rust. Rust is great if you already have a spec and know what needs to be done.
Most of the gamedev in my opinion is extremely exploratory and demands constant experimentation with design. C/C++ offer fluidity, a very good and mature debug toolchain, solid performance ceiling and support from other people.
It will be really hard to replace C++ in performance/simulation contexts. Security takes a backseat there.
Author of Renderling here. Thanks for the shout out Animats!
Bindless is a game changer - pun intended. It can’t happen soon enough.
Just curious, what are the three major projects that were cancelled?
I also want to mention that folks are shipping high performance games in Rust - the first title that comes to mind is “Tiny Glade” which is breathtakingly gorgeous, though it is a casual game. It does not run on wgpu though, to my knowledge. I may have a different definition of high performance, with lower expectations.
> What are the three major projects that were cancelled?
Here are some:
- LogLog Games [1]. Not happy with Bevy. Not too unhappy about performance, although it's mentioned.
- Moonlight Coffee [2]. Not a major project, but he got as far as loading glTF and displaying the results, then quit. That's a common place to give up.
- Hexops. [3] Found Rust "too hard", switched to Zig.
Tiny Glade is very well done. But, of course, it's a tiny glade. This avoids the scaling problems.
2. It's very much still alive and well today, not 'cancelled'
3. We never even used WebGPU in Rust, this was before WebGPU was really a thing.
It is true that we looked elsewhere for a better language for us with different tradeoffs, and have since fully embraced Zig. It's also true that we were big proponents of WebGPU earlier on, and have in recent years abandoned WebGPU in favor of something which is better for graphics outside the browser (that's its own worthwhile story)..
But we've never played /any/ role in the Rust gamedev ecosystem, really.
I think the future is getting rid of all the APIs and driver overhead, compile directly to GPU compute and write your own software renderers in a language targeting GPUs (Could be Zig)
A better way to think about the problem is to recognize that the APIs and drivers are providing various services that pretty much every user is going to need, and which you will now need to reimplement yourself.
Nobody needs all of Vulkan, but everyone needs quite a bit of it. Buffer allocation? Command encoding? Scheduling? Synchronization? Abstracting GPU architecture differences (and GPUs vary a lot)? Render pipeline fixed-function stages like primitive assembly, tiling, and blending? You're signing up to implement all of that - good luck!
In this view, your idea is the assertion, "I could do a better job at all that stuff than the driver developers." Maybe so! They're only human. Drivers do have bugs. But you're only human too.
I agree; however, engine developers are already dedicated to building massive behemoths of software that is the game engine and they constantly do collaborate with driver devs, essentially sharing much of the same skillset.
Also, the onus is actually on the GPU manufacturers (not game engine devs) to simplify the programmability of the GPUs to the level we have for CPUs (we also do not write microcode, however, the programmability is much much simpler with access to good compiler toolchains). This will massively help non game engine developers who need GPUs for other kinds of compute.
None of those are “major projects” by any definition of the word though. And none of the three has anything to do with wgpu's performance.
Rust for game engine has always been a highly risky endeavor since the ecosystem is much less mature than everything else, and even though things have improved a ton over the past few years, it's still light-years away from the mainstream tools.
Building a complete game ecosystem is very hard and it's not surprising to see that Rust is still struggling.
WGPU (https://wgpu.rs/) is one of currently three implementations of the WebGPU specification (the other two being Google's Dawn library used in Chrome, and the implementation in WebKit used in Safari).
The main purpose of WebGPU is to specify a 3D API over the common subset of Metal/D3D12/Vulkan features (e.g. doing an 'on-the-fly translation' of WebGPU API calls to Metal/D3D12/Vulkan API calls, very similar to how (a part of) Proton does an on-the-fly translation of the various D3D API versions to Vulkan.
You're describing the WebGPU spec and its different implementations.
OP claimed WGPU had native support for VK, DX and others. But as far as I know, WGPU just supports WebGPU being translated on the fly to those other backends, with the obvious performance hit. If I'm wrong, I'd be interested to know, as this would make WGPU a more interesting choice for many if, in reality, the code was native instead of translation.
Those three WebGPU implementation libraries are compiled to native code (they are written in Rust or C/C++), and at least WGPU and Dawn are usable as native libraries outside the browser in regular native apps that want to use WebGPU as a cross-platform 3D API.
Yet still, those native libraries do a runtime translation of WebGPU API calls to DX/Vk/Metal API calls (and also a runtime translation of either WGSL or SPIRV to the respective 3D backend API shading languages) - in that sense, quite similar to what Proton does, just for a different 'frontend API'.
Then performance of WGPU will always be problematic, below that of the native APIs (DX, vk and Metal), and constrained within the limits of the WebGPU spec.
I think it's more about low-end mobile GPUs which WebGPU needs to support too (which is also the main reason why Vulkan is such a mess). The feature gap between the low- and high-end is bigger than ever before and will most likely continue to grow.
I am yet to see anyone deliver in WebGL something at the level of Infinity Blade that Apple used to demo OpenGL ES 3.0 capabilities of their 2011 iPhone model, a mobile phone GPU from almost 15 years ago.
Unless we are talking about cool shadertoy examples.
That's more a business problem than a technical problem. Web games are in a local maximum of minimal production cost (via 2D assets) versus maximized profits (via free-2-play), and as long as this works well there won't be an Infinity Blade because it's too expensive to produce.
The chicken egg problem caused by killing Flash games, and that nowadays no one cares about the browser, because everyone doing Flash moved into mobile phones or Steam, with better APIs?
Game Pass, GeForce Now, are doing alright.
Stadia failed, because Google doesn't get games industry.
> The default texture limits without bindless are also way too small for serious applications
I'm not disagreeing that bindless is needed but it's a bit of hyperbole to claim the texture limits are too small for serious applications given the large list of serious graphics applications that shipped before bindless existed and the large number of serious graphics applications and games still shipping that don't use them.
It's partly because WebGPU has very conservative default texture limits so that they can support old mobile devices, and partly it's a problem for engines that may have a bunch of different bindings and have increasingly hacky workarounds to compile different variants with only the enabled features so that you don't blow past texture limits.
For an idea of bevy's default view and PBR material bindings, see:
They're talking about the 16 sampled texture binding limit which is the same as webgl2. If you look at eg. the list of devices that are stuck with that few texture bindings they don't even support basic GL with compute shaders or vulkan, so they can't even run webgpu in the first place.
Yes. If you're stuck with that limitation, you pack up related textures into a big texture atlas. When you enter a new area, the player sees "Loading..." while the next batch of content is loaded. That was the state of the art 15 years ago. It's kind of dated now.
You might be getting “sampled textures in a single call” with “total textures loaded” mixed up. Sampled texture limits affect complexity of your shader and have nothing to do with loading content from elsewhere.
Quick note: I looked at the bindless proposal linked from the blog post and their description of Metal is quite outdated. MTLArgumentEncoder has been deprecated for a while now, the layout is a transparent C struct that you populate at will with GPU addresses. There are still descriptors for textures and samplers, but these are hidden from the user (the API will maintain internal tables). It's a very convenient model and probably the simplest and most flexible of all current APIs. I'd love to see something similar for WebGPU.
The nice thing about WebGPU's "compat mode" is that it's designed so browsers don't have to implement it if they don't want to. Chrome is really excited about it; Safari has no plans to implement it, ever.
I agree that compat mode takes up more of the WebGPU standard committee's time than bindless. I'm not sure that's how I would prioritize things. (As a Mozilla engineer, we have more than enough implementation work to do already, so what the committee discusses is sort of beside the point for us...)
We do when there available, but I think the way browsers implement limit bucketing (to combat fingerprinting) means that some users ran into the limit.
I never personally ran into the issue, but I know it's a problem our users have had.
Yeah I went down the rabbit hole of trying to rewrite all our shaders to work on webgpu’s crazy low limits. I’m embarrassed to say how long I worked that problem until I tried requesting higher limits, and it worked on every device we were targeting.
The default limits are like the lowest common denominator and typically way lower than what the device actually supports.
It only goes to show the limitations of browser 3D APIs, and the huge mistake some folks do for native games using it instead of a proper middleware engines, capable of exposing modern hardware.
I don't necessarily disagree. But I don't agree either. WebGPU has given us as many positives as it has negatives. A lot of our user base is not on modern hardware, as much as other users are.
Part of the challenge of making a general purpose engine is that we can't make choices that specialize to a use case like that. We need to support all the backends, all the rendering features, all the tradeoffs, so that our users don't have to. It's a hard challenge.
I don't think Google cares. If it works on Chromebooks and most Android phones, their job is done. On to the next API, let's make WebWiFi or WebAI.
WebGPU demos never work for me, so I personally consider the tech dead until that gets fixed. WebGL is barely stable enough to use as well, so I guess I'll just have to keep doing GPU stuff outside of the browser.
When they see a business value on GNU/Linux Desktop WebGPU support for Chrome, note that other Linux kernel based systems from Google already support it.
So that's how it worked with MacOS and Windows? Color me surprised.
But bth, Google doesn't seem to care about Android either. Chrome supports it on Snapdragons and that's it. Do you have Xclipse GPU? Like, I don't know, Samsung's current flagship line Galaxy S24 does? Too bad, not good enough.
Honest question: Can someone explain to me why people are excited about WebGPU and WASM and similar technologies?
To me, one of the greatest things about the web is that the DOM is malleable in that you can right click -> view source -> change things. This is dead in an era where the server just sends you a compiled WASM dll.
It seems to me that the inevitable result of things like WASM and WebGPU will be "rich media web 4.0 applications" that are just DRM, crypto miners, and spyware compiled so that they're more difficult to circumvent, and delivered via the browser. An excuse to write web apps with poor performance because "well the user just needs a stronger GPU". It seems like an express train back to the bad old days of every website being written in flash.
I honestly cannot see the upsides of these technologies. Is it gaming? Why would I want to play a 3D game in my fucking browser of all places? That's a strict downgrade in almost every way I can think of. Why would anyone want that? Is it "AI"? Why would I want to run an LLM in the browser, I could just run it natively for better performance?
All I can see and have seen over the last several years is a steady parade of new technologies that will make the internet (and in some cases the lives of every day people) objectively worse while enriching a handful of big tech douchebags.
Why are we going down this path? Who is asking for this stuff? Why the fuck would I want to expose my GPU to a website?
> Why would I want to play a 3D game in my fucking browser of all places?
To provide users a way to instantly play a game without having to download all assets at once. Give developers a potential way to avoid app store royalties of up to 30% on desktop or mobile. With wgpu in rust, you can also target WebGPU as a shared 3d runtime that will run across OS's natively rather than having to target Vulkan, Metal, and DirectX.
> Why would I want to run an LLM in the browser, I could just run it natively for better performance?
What about users who don't know how to download a model and run it locally? I would argue this is the vast majority of users in the world. Also, this specific use case is probably not going to be generalized with WebGPU yet due to model sizes, but rather other APIs like the Prompt API in Chrome which will use Gemini Nano embedded into the browser (assume it will eventually get standardized). https://developer.chrome.com/docs/ai/built-in-apis
I agree with you that WASM and WebGPU will be used for adware, targeting, and spyware - but if you don't want to use them, you should disable them in your browser settings - there's definitely value add for other users even if you can't see any benefits.
Browsers will never run games that aren't toys or use very simple assets in a way that doesn't completely suck. High quality assets need gigabytes of data. You either require users to download all the assets upfront (the thing we're trying to avoid) or streaming the assets dynamically.
You end up having to re-implement steam to keep a local copy of the assets on the client device yourself, expect browsers to do the same to manage caching the gigabytes of data transparently, or design your game around a very slow storage device or use tiny assets.
Flash games worked because they fit very nicely into the 'tiny assets' category.
> I don’t want to download a random executable from some unknown source
Why would you do that?
---
There's few applications that warrant having direct access to the GPU and other devices. And for those, a native app would be a much efficient way (for the user).
yeah but users don't care about technical efficiency, they care about having seamless experiences that aren't interrupted by long downloads, app/context switching, and loading screens.
Why make things perform worse when they can perform better?
Why shouldn't I be able to make an application that compiles to the Windows, macOS, and Linux desktops and also to the browser? This one does: https://bandysc.github.io/AvaloniaVisualBasic6/
For that matter, why would you expose your CPU to a website? Or your monitor? It could show you anything! ;)
Maybe you are not be aware of the number of good web apps that use some WebGL under the hood? You might be using office applications in your browser already that use WebGL when it’s available, and the reason is it makes things faster, more responsive, more scalable, and more efficient. Same would go for WebGPU.
There’s no reason to imagine that the web will do bad things with your resources that you didn’t ask for and don’t have control over. There have been hiccups in the past, but they got fixed. Awareness is higher now, and if there are hiccups, they’ll get fixed.
> There’s no reason to imagine that the web will do bad things with your resources that you didn’t ask for and don’t have control over.
Read some security update news from browser vendors and vulnerability researcher posts. There's some weak signals about vendors acknowledging the difficulty of securing the enormous attack surface of browsers built on unsafe foundations, eg MS "enhanced security mode" and Apple "lockdown mode".
I don't mind the browser using the GPU to speed up graphical operations. But I do mind random sites and apps going further than that. Native apps have better access, but there's an higher selection criteria than just opening a URL.
Last time I checked Runescape switched to a native client, too. And even in the browser back in the day it used to run absolutely terribly, so I hope we're not trying to replicate that experience.
> How could anyone not want games like Runescape to exist?!?
I mean, I wouldn't say I don't want it to exist. But Runescape is one of the shittiest, most boring games I've ever played. It's not exactly a strong argument for why we should run stuff in the browser
I agree. Trying to shove everything into the browser is absolutely stupid. Native apps are better than doing things in the browser in almost all cases. But that's not trendy, so people don't chase after it.
Native operating systems are garbage at maintaining user privacy and become maintenance burdens when too many applications have been installed and even uninstalled on the machine.
While not perfect, a browser tab is a stronger sandbox than you can easily get in any other context.
Why do you think wasm is harder to circumvent? The only way to instantiate a wasm module in the browser is through (drum roll) javascript. Install noscript if you're worried. The days of view source -> edit are basically over anyway due to every site's 1MB+ minified JS blobs.
> Why would I want to run an LLM in the browser, I could just run it natively for better performance?
Why would you try out a new app in a sandboxed browser, when instead you could give it complete access to your entire computer?
Sandboxing is about preventing code from accessing data it's not supposed to. Data like files or memory belonging to other tabs or other processes. Or data streams like your webcam or microphone. Data outside of its, well, sandbox.
So how are compute shaders accessing data they're not supposed to? How do you think they're escaping the sandbox?
It seems like you're just making up your own definitions now because you don't like the tech. What do think a sandbox is, exactly? And what do you think Chrome's GPU sandbox does, if it's not a sandbox?
You should try Chillin(https://chillin.online), browser-based video editor. Powered by WebGL, WASM, and WebCodecs, Chillin provides a full suite of video editing capabilities on the web. Trust me, Chillin is smoother than most native video editors, even on mobile. I believe Chillin can leverage WebGPU to bring even more powerful rendering features.
Yes, running LLMs on the web may not have significant advantages due to the speed limitations, but other models, such as those for bg removal, speech-to-subtitles, and translation, could become practical and efficient thanks to WebGPU.
"This is the next step in the standardization process, and it comes with stronger guarantees of stability and intellectual property protection."
I understand stability, and in the general sense I see that people feel they need to protect their IP, but in this specific case what is meant by "intellectual property protection"?
W3C generally requires Working Group participants to provide IPR licensing commitments for the spec in question [0]. As far as I understand, higher level of specification maturity implies stronger level of obligations, though the specifics of what specifically changes when were never clear to me.
I wish there were a good way to profile WebGPU code. I've seen this (very useful) article[1] on setting up PIX, but I'm ambitious. I want to see everything from draw call timings to flamegraphs of shader code.
Right now I feel like the only way to write efficient WebGPU code is to deeply understand specific GPU architectures. I hope some day there's a dev tools tab that shows me I'm spending too much time sampling a texture or there's a lot of contention on my atomic add.
Timestamp queries will give you essentially time spans you can use for profiling, but anything more than that and you really want to use a dedicated tool from your vendor like NSight, RGP, IGA, XCode, or PIX.
> Right now I feel like the only way to write efficient WebGPU code is to deeply understand specific GPU architectures. I hope some day there's a dev tools tab that shows me I'm spending too much time sampling a texture or there's a lot of contention on my atomic add.
It's kind of the nature of the beast. Something that's cheap on one GPU might be more expensive on another, or might be fine because you can hide the latency even if it's slow, or the CPU overhead negates any GPU wins, etc. The APIs that give you the data for what you're asking are also vendor-specific.
That's fine—same with CPUs, right? But if I do something that's slow on _my_ CPU, at least there's tooling that will show me!
I know that the reason is a lot of technical complexity (plus little standardization between vendors), but I think the end goal should be to make GPU programming more accessible.
It can absolutely be used for bad, and I know many sites do use it for bad. However, it does good as well, and I think it's important to develop but also it should come with similar permission requests that use of microphone or camera do.
I do research and develop ANN's for data analysis within chemistry. Making it possible for less tech literate people to visit a site, select a model, load their dataset, and get answers, is quite handy. The best part is because I can use their hardware to do it all, it all stays private, no one has to upload any sensitive research data etc. and I don't have to ship to various devices etc. I know if they have a mainstream updated browser they can likely use the tool. No endless requests for help, no mystery issues to solve, things just work.
Right, but I think it should change. I think consumers should have a say when a website wants to compute things that are out of scope for a normal page of text/information. I certainly dont want my laptop hot, slow, an poorly responsive because some news site's borderline malware is running several poorly built and implemented models that aim to track and predict my behaviour from mouse movement etc.
We've already seen Javascript cryptocurrency miners, so when WebGPU starts actually being used I suspect we'll see their use rise to new heights. It's a matter of time until some website starts offering WebGPU crypto mining as an alternative to their paywall.
Font drawing is very much out of scope for a 3D API, that's something you (or a library) would implement on top of WebGPU. Likewise for line drawing, the API may expose some simple line primitives that the hardware supports natively, but if you want anything fancier then you're expected to do it yourself with shaders which is already possible in WebGPU.
The 3D API is just meant to be a minimal portable abstraction over common low-level hardware features, composing those features into higher level constructs is intentionally left as an exercise for the user.
The problem is now you have to have all sorts of additional libraries you need to load across a network.
Web APIs need more standardized functionality built in, including high-level ones, and not rely on additional libraries, because they have to download across a network.
It's like having to install an app every time you visit a site.
Asking for lines is like asking for your CPU to support macros. The GPU is low-level, lines are high level. You build the high level on top of the low-level with libraries etc...
WebGPU does have line primitives of course, but only the type of lines that's supported in the underlying 3D APIs (e.g. 1-pixel wide). Since the whole purpose of WebGPU is to provide a thin API over the common feature set of D3D12, Metal and Vulkan that's totally expected though.
Same. I do a ton of 2D map stuff and it’s always quite uncomfortable to do in shaders or very slow in a Canvas context.
The last time I tried with pixi.js the problem was smoothly zooming polygons with a constant width border thicker than hairline. Doing that was basically just generating new textures on every frame.
My team (third party) has developed WebGPU support for Unreal Engine 5, along with an asset-streaming system that solves the large download, multi-gigabyte game in your webpage issue by only loading in what a player needs to see at any given moment. It's constantly loading and unloading data, which helps tremendously with memory management.
WebGPU is going to usher in a new era of web games, the biggest benefit being compute shaders which have never before been possible inside the browser.
DISCLAIMER - Will only work on a Windows device running Chrome or a Chromium browser. Mac and iOS isn't well supported yet.
This was cool (spacelancers didn't work in Arc but did in Chrome, forest demo 403's) - audio and fullscreen fail because they aren't initiated by a user gesture. Impressive how quick it is to get into a game with this level of fidelity, normally you'd need several minutes of downloading.
Where is this comment coming from? WebGPU enables compute shaders, and there are applications in anything that uses a GPU, from ML to physics to audio to … you name it. What is making you think game engines would be the only users? I bet a lot of companies are looking forward to being able to use compute shaders in JS apps and web pages.
> Godot has had zero development for WebGPU support.
Why would Godot be an indicator? I love Godot and their efforts, but it’s less than 1% of game engine market share, and a much smaller less well funded team. Of course they’re not on the bleeding edge. Unity is closer to 30% market share and is actively engaging with WebGPU, so it seems like you’re downplaying and contradicting a strong indicator.
> WebGPU enables compute shaders, and there are applications in anything that uses a GPU, from ML to physics to audio to … you name it.
I know.
If you have to go through a giant product like Unity for example to use WebGPU because Apple will essentially have its own flavor of WebGPU just like it has its own flavor of everything, is it really cross platform?
Does Apple support Vulkan? No. It was invented for middlewares!
Apple has a flag to toggle on WebGPU on iOS today. I know dude. What does that really mean?
They have such a poor record of support for gamey things on Mobile Safari. No immersive WebXR, a long history of breaking WASM, a long history of poor WebGL 2 and texture compression support. Why is this going to be any different?
I’m still not sure what the point is. WebGPU is an API, is that that you mean by middleware? What’s the issue? Apple will do their own thing, and they might not allow WebGPU on Safari. What bearing does that have on what people using Linux, Windows, Firefox, and Chrome should do? And where exactly is this cross platform claim you’re referring to?
The demo is doing a setBindGroup per triangle, so not exactly surprising since this is a well known bottleneck (Chrome's implementation is better optimized but even there setBindGroup is a surprisingly slow call). But since both implementations run on top of Metal there's no reason why Safari couldn't get at least to the same performance as Chrome.
The issue is, it's likely that a company with $2 BILLION spent on product development and a very deep relationship with Apple, like Unity, will have success using WebGPU the way it is intended, and nobody else will. So then, in conclusion, WebGPU is designed for Unity, not you and me. Unity is designed for you and me. Are you getting it?
> The issue is, it's likely that a company with $2 BILLION spent on product development and a very deep relationship with Apple, like Unity, will have success using WebGPU the way it is intended, and nobody else will.
Not really. Bevy https://bevyengine.org uses WebGPU exclusively, and we have unfortunately little funding - definitely not $2 billion. A lot of the stuff proposed in the article (bindless, 64-bit atomics, etc) is stuff we (and others) proposed :)
If anything, WebGPU the spec could really use _more_ funding and developer time from experienced graphics developers.
Why are people downvoting? The idea of Great High Performance Graphics Effortlessly on All Platforms is very appealing. It is fundamentally empathetic. It is an opium to game developers whose real antagonist is Apple and Nintendo, and who want a more organic journey in game development than Unity Learn. Is it a realizable goal? Time will tell.
Everyone should be advocating for more focused efforts, but then. Are you going to say, Bevy is better than Godot? It’s subjective right? Open source efforts are already spread so thin. An inability to rally behind one engine means achieving 2013’s Unity 5 level of functionality is years away.
Looking at it critically, in fact much effort in the open source ecosystem is even anti games. For example emulators used to pirate Nintendo Switch games have more mature multiplatform graphics engine implementations than Godot and Bevy do. It would be nice if that weren’t true, you might tell me in some sense that I am wrong, but c’mon. It’s crazy how much community effort goes into piracy compared to the stuff that would sincerely benefit game developers.
WebGPU is authored by giant media companies, and will have purposefully hobbled support by the most obnoxious of them all, Apple - the one platform where it is kind of impractical to pirate stuff, but also, where it is kind of impractical to deliver games through the browser. Precisely because of the empathetic, yet ultimately false, promises of WebGPU.
Why are you bringing up Godot again? Are you worried Godot will be left behind or unable to compete with Unity? Are you working on Godot? Why are you focused exclusively on games? What are the ‘false promises’ of WebGPU, and why do you think it won’t deliver compute shaders to every browser that supports it, like it says? I’m just curious, I get the sense there’s an underlying issue you feel strongly about and a set of assumptions that you’re not stating here. I don’t have a lot invested in whether WebGPU is adopted by everyone, and I’m trying to understand if and why you do. Seems like compute shaders in the browser will have a lot of interest considering the wild success of CUDA. Are you against people having access to compute shaders in the browser?
That you can write a "compute shader" once, and it will run "anywhere." This isn't the case with any accelerated compute API, so why is WebGPU going to be different?
Reality will be Chrome Windows Desktop WebGPU, Chrome Android (newish) WebGPU, Mobile Safari iOS 18 WebGPU, iPad WebGPU, macOS Safari WebGPU, macOS Chrome WebGPU, iOS default in app browser WebGPU, Instagram and Facebook in app browser WebGPU...
This isn't complicated! If that's reality, I'd rather have:
Apple Compute Shaders for Browser. Windows Chrome Compute Shaders for Browser. Android Chrome Compute Shaders for Browser.
Because I'm going to go through a middleware like Unity to deal with both situations. But look at which is simpler. It's not complicated.
> I’m trying to understand if and why you do.
I make games. I like the status quo where we get amazing game engines for free.
I cannot force open source developers to do anything. They are welcome to waste their time on any effort. If Bevy has great WebGL 2 support, which runs almost without warts everywhere, even on iOS, for example, it makes no sense to worry about WebGPU at all, due to the nature of the games that use Bevy. Because "runs on WebGPU" is making-believe that you can avoid the hard multiplatform engine bits. Engines like Construct and LOVE and whatever - 2D games don't need compute shaders, they are not very performance sensitive, use the browser as the middleware, and the ones that are, they should just use a huge commercial game engine. People have choices.
It seems like you’ve jumped to and are stuck on a conclusion that isn’t really supported, somewhat ignoring people from multiple companies in this thread who are actively using WebGPU, and it’s not clear what you want to have happen or why. Do you want WebGPU development to stop? Do you want Apple to support it? What outcome are you advocating for?
Unity spends the vast majority of its money on other things, and Unity isn’t the only company that will make use of WebGPU. Saying nobody will have success with it is like saying nobody will succeed at using CUDA. We’re just talking about compute shaders. What is making you think they’re too hard to use without Apple’s help?
You haven't substantiated why nobody else could make use of WebGPU. Are Google the only ones who can understand Beacons because they make $300B/year? GPU is hard, but it doesn't take billions to figure out.
Apple submitted Metal as a web spec and they turned this into WebGPU and Apple got everything they asked for to avoid apple going rogue again. The fear that Apple of all companies is going to drop WebGPU support is really not based in reality.
Sounds like an interesting idea at first until the point where they will probably create a Swift/ObjC API around it instead of the standard webgpu.h C API, and at that point you can just as well use Metal - which is actually a bit less awkward than the WebGPU API in some areas.
The number 1 use of WebGL is Google Maps by several orders of magnitude over any other use. At some point they'll likely switch to WebGPU making it the number 1 use of Google Maps. Google went over what this enables when they shipped it. Lots of features including being able to highlight relevant roads that change depending on what you searched for.
Web video editor(https://chillin.online), we are eagerly looking forward to the WebGPU API maturing and being extended to all major browsers, enabling faster rendering, bringing more effects, and facilitating the rendering and editing of 3D assets.
I'm new to GPU programming, and WebGPU and Rust's wgpu seem pretty nice to me (except the bindings!). The API is high-level enough that it's easy to learn. It hasn't grown deprecated parts or vendor-specific extensions yet.
When I visit a Construct 3 Ultra Pixel Survive on Mobile Safari on the latest production iOS with either WebGPU enabled and disabled, I only see black:
Which Construct 3 game should I try on Mobile Safari?
I know there are other game engines. Supporting Mobile Safari is very very hard. It has its own flavor of everything. I would never speak in absolutes about some web standard and how it will work on Mobile Safari.
Construct 3 doesn’t work with WebGPU disabled either. I’m sure it has official support for Mobile Safari, just not official enough to work when someone visits a Construct 3 experience.
I’m not dunking on the engine. It’s just to say, well this is what graphics programming in browser is: making shit work on mobile Safari.
Bindless is pretty much _the_ most important feature we need in WebGPU. Other stuff can be worked around to varying degrees of success, but lack of bindless makes our state changes extremely frequent, which heavily kills performance with how expensive WebGPU makes changing state. The default texture limits without bindless are also way too small for serious applications - just implementing the glTF PBR spec + extensions will blow past them.
I'm really looking forward to getting bindless later down the road, although I expect it to take quite a while.
By the same token, I'm quite surprised that effort is being put into a compatibility mode, when WebGPU is already too old and limiting for a lot of people, and when WebGL(2) is going to have to be maintained by browsers anyways.
> Bindless is pretty much _the_ most important feature we need in WebGPU. Other stuff can be worked around to varying degrees of success, but lack of bindless makes our state changes extremely frequent, which heavily kills performance with how expensive WebGPU makes changing state.
Yes.
This has had a devastating effect on Rust 3D graphics. The main crate for doing 3D graphics in Rust is WGPU. WGPU supports not just WebGPU, but Android, Vulkan, Metal, Direct-X 12, and OpenGL. It makes them all look much like Vulkan. Bevy, Rend3, and Renderling, the next level up, all use WGPU. It's so convenient.
WGPU has lowest common denominator support. If WebGPU can't do something inside a browser, then WGPU probably can't do it on other platforms which could handle it. So WGPU makes your gamer PC perform like a browser or a phone. No bindless, no multiple queues, and somewhat inefficient binding and allocation.
This is one reason we don't see high-performance games written in Rust.
After four years of development, WGPU performance has gone down, not up. When it dropped 21% recently and I pointed that out, some people were very annoyed.[1]
Google pushing bindless forward might help get this unstuck. Although notice that the target date on their whiteboard is December 2026. I'm not sure that game dev in Rust has that much runway left. Three major projects have been cancelled and the main site for Rust game dev stopped updating in June 2024.[2]
[1] https://github.com/gfx-rs/wgpu/issues/6434
[2] https://gamedev.rs/
> This is one reason we don't see high-performance games written in Rust.
Rendering is _hard_, and Rust is an uncommon toolchain in the gamedev industry. I don't think wgpu has much to do with it. Vulkan via ash and DirectX12 via windows-rs are both great options in Rust.
> After four years of development, WGPU performance has gone down, not up. When it dropped 21% recently and I pointed that out, some people were very annoyed.[1]
Performance isn't most of the wgpu maintainer's (who are paid by Mozilla) priority at the moment. Fixing bugs and implementing missing features so that they can ship WebGPU support in Firefox is more important. The other maintainers are volunteers with no obligation besides finding it enjoyable to work on. Performance can always be improved later, but getting working WebGPU support to users so that websites can start targeting it is crucial. The annoyance is that you were rude about it.
> Google pushing bindless forward might help get this unstuck. Although notice that the target date on their whiteboard is December 2026.
The bindless stuff is basically "developers requested it a ton when we asked for feedback on features they wanted (I was one of those people who gave them feedback), and we had some draft proposals from (iirc) 1-2 different people". It's wanted, but there are still major questions to answer. It's not like this is a set thing they've been developing and are preparing to release. All the features listed are just feedback from users and discussion that took place at the WebGPU face to face recently.
WGPU dev here. I agree with everything JMS55 says here, but I want to avoid a potential misunderstanding. Performance is definitely a priority for WGPU, the open source project. Much of WGPU's audience is very concerned with performance.
My team at Mozilla are active contributors to WGPU. For the moment, when we Mozilla engineers are prioritizing our own work, we are focused on compatibility and safety, because that's what we need most urgently for our use case. Once we have shipped WebGPU in Firefox, we will start putting our efforts into other things like performance, developer experience, and so on.
But WGPU has other contributors with other priorities. For example, WGPU just merged some additions to its nascent ray tracing support. That's not a Mozilla priority, but WGPU took the PR. Similarly for some recent extensions to 64-bit atomics (which I think is used by Bevy for Nanite-like techniques?), and other areas.
WGPU is an open source project. We at Mozilla contribute to the features we need; other people contribute to what they care about; and the overall direction of the project is determined by what capable contributors put in the time to make happen.
> But WGPU has other contributors with other priorities. For example, WGPU just merged some additions to its nascent ray tracing support. That's not a Mozilla priority, but WGPU took the PR. Similarly for some recent extensions to 64-bit atomics (which I think is used by Bevy for Nanite-like techniques?), and other areas.
Yep! The 64-bit atomic stuff let me implement software rasterization for our Nanite-like renderer - it was a huge win. Same for raytracing, I'm using it to develop a RT DI/GI solution for Bevy. Both were really exciting additions.
The question of how performant and featureful wgpu is is mostly just a matter of resources in my view. Like with Bevy, it's up to contributors. The unfortunate reality is that if I'm busy working on Bevy, I don't have any time for wgpu. So I'm thankful for the people who _do_ put in time to wgpu, so that I can continue to improve Bevy.
> Rendering is _hard_, and Rust is an uncommon toolchain in the gamedev industry. I don't think wgpu has much to do with it. Vulkan via ash and DirectX12 via windows-rs are both great options in Rust.
Yes. I think I'm beginning to see what's gone wrong with the Rust crates. It's an architectural problem. Vulcano and WGPU try to create a Rust safety perimeter at an API that's basically a wrapper around Vulkan. This may be the wrong boundary for that safety perimeter.
Moving buffer allocation inside the safety perimeter may eliminate a level of locking and checking. Bindless really brings this out, because somebody has to keep the descriptor table and buffer allocation in sync. The GPU depends on that. So that has safety implications.
If this problem is partitioned differently, the locking problems for concurrent GPU content updating may become simpler. Right now, both Vulcano and WGPU force more serialization than Vulkan itself requires. The rendering thread is too often stalled on a lock waiting for some content updating operation that should not interfere with rendering.
Too much detail for this forum. I'll continue this elsewhere. This has been useful.
Back in the day I did a similar error with wrapping C graphic libraries directly 1:1 with improved C++ bindings, until I realised it was more ergonomic to think in higher level C++ abstractions, and exposed those concepts instead, fully hiding the underlying unsafe C APIs.
I'm interested in reading more. Where will you continue this?
> implementing missing features so that they can ship WebGPU support in Firefox
Sounds like WGPU, the project, should be detached from Firefox?
To me the priority of shipping WGPU on FF is kind of mind-boggling, as I consider the browser irrelevant at this point in time.
Just to avoid potential confusion: WebGPU and WGPU are different things.
(a) WebGPU -> Specification or browser API
(b) WGPU, gfx-rs/wgpu, wgpu.rs -> Rust crate implementing WebGPU
(c) wgpu -> the prefix used by the C API for all WebGPU native implementations.
(d) 'wgpu' -> a cute shorthand used by everyone to describe either (a), (b), or (c) with confusion.
The irrelevant browser is the one paying developers to build wgpu though…
Outside of the browser the answer is middleware.
WGPU has to decide, either stay compatible with WebGPU, and thus be constrained by the design of a Web 3D API, or embrace native code and diverge from WebGPU.
This is the right answer^
But even more, the level at which WebGPU exists (not too high level, not too low level) necessitates that if a native API graphics abstraction sticks with the WebGPU's API design and only 'extends' it, you actually end up with three totally different ways to use the API:
* The one with your native 'extensions' -> your app will only run natively and never in the browser unless you implement two different WebGPU rendering backends. Also won't run on Chromebook-type devices that only have GLES-era hardware.
* The WebGPU browser API -> your app will run in the browser, but not on GLES-era hardware. Perish in the verbosity of not having bindless support.
* The new 'compatability' mode in WebGPU -> your app runs everywhere, but perish in the verbosity of not having bindless, suffer without reversed-z buffers because the underlying API doesn't support it.
And if you want your app to run in all three as best as possible, you need to write three different webgpu backends for your app, effectively, as if they are different APIs and shading languages.
> The WebGPU browser API -> your app will run in the browser, but not on GLES-era hardware. Perish in the verbosity of not having bindless support.
Note, regarding "GLES-era": WGPU does have a GLES/WebGL2 backend; missing WebGL1 is unfortunate, but at least it covers most recent browsers/hardware that happens to not have WebGPU supported yet.
(and there's necessarily some added overhead from having to adapt to GLES-style api; it's especially silly if you consider that the browser might then convert the api calls and shaders _again_ to D3D11 via ANGLE)
I am referring primarily to the fact that a restricted subset of WebGPU is needed ('compatibility mode') to support D3D11 / GLES era hardware[0]
[0] https://github.com/gpuweb/gpuweb/issues/4266
There's a *massive* difference in capabilities between GLES3.0 (e.g. WebGL2) and D3D11 though (GLES3.0 is more like 'late D3D9 era') ;)
And interestingly, WebGL2 in Chrome on Windows (which runs on top of D3D11) handily beats WebGPU in some of my tests (with setBindGroup being the bottleneck).
Is WGPU even a Mozilla project? I think he is just saying that those paid developers (paid by Mozilla) have that priority, and everyone else is volunteer. Not that WGPU is a Firefox project.
Thanks, I checked the WGPU project's roots and you're right - it's not Mozilla's project, per-se.
Yes, this.
There have been a bunch of significant improvements to WGPU's performance over the last few years.
* Before the major rework called "arcanization", `wgpu_core` used a locking design that caused huge amounts of contention in any multi-threaded program. It took write locks so often I doubt you could get much parallelism at all out of it. That's all been ripped out, and we've been evolving steadily towards a more limited and reasonable locking discipline.
* `wgpu_core` used to have a complex system of "suspected resources" and deferred cleanup, apparently to try to reduce the amount of work that needed to be done when a command buffer finished executing on the GPU. This turned out not to actually save any work at all: it did exactly the same amount of bookkeeping, just at a different time. We ripped out this complexity and got big speedups on some test cases.
* `wgpu_core` used to use Rust generics to generate, essentially, a separate copy of its entire code for each backend (Vulkan, Metal, D3D12) that it used. The idea was that the code generator would be able to see exactly what backend types and functions `wgpu_core` was using, inline stuff, optimize, etc. It also put our build times through the roof. So, to see if we could do something about the build times, Wumpf experimented with making the `wgpu_hal` API use dynamic dispatch instead. For reasons that are not clear to me, switching from generics to dynamic dispatch made WGPU faster --- substantially so on some benchmarks.
Animats posts frequently about performance problems they're running into, but when they do it's always this huge pile of unanalyzed data. It's almost as if, they run into a performance problem with their code, and then rather than figuring out what's going on themselves, they throw their whole app over the wall and ask WGPU to debug the problem. That is just not a service we offer.
He's reporting a 23% drop in performance and seems to have invested quite some time in pinning down what's causing it, plus he's provided a repro repository with benchmarks.
I honestly don't get your annoyed response; any OSS project wishes they had such detailed bug reports, and such a performance regression would concern me very much if it happened in a project I maintain.
This is in reference to [1].
[1] https://github.com/gfx-rs/wgpu/issues/6434
What? They even provided a benchmarking tool. You should be ecstatic at users providing such detailed reports. Most projects just attract reports that go like "its slow, fix it!!111"
> When it dropped 21% recently and I pointed that out, some people were very annoyed.[1]
Someone was seemingly "annoyed" by an impatient end-user asking for an status update ("It's now next week. Waiting.") and nothing more. They didn't seem to be annoyed about that you pointed out a performance issue, and instead explained that their current focus is elsewhere.
Tbh I was annoyed reading it too as an open source developer. The people you are talking to are volunteering their time, and you weren’t very considerate of that. Open source software isn’t the same support structure as paid software. You don’t file tickets and expect them to be promptly fixed, unless you do the legwork yourself.
Tbf, tons of games have been created and are still being created without bindless resource binding. While WebGPU does have some surprising performance bottlenecks around setBindGroup(), details like that hardly make or break a game (if the devs are somewhat competent they'll come up with ways to workaround 3D API limitations - that's how it's always been and always will be - the old batching tricks from the D3D9 era still sometimes make sense, I wonder if people simply forgot about those or don't know them in the first place because it was before their time).
Nobody forgot about batching. It's a foundational strategy in any efficient realtime renderer. The bar has simply moved and even the cheaper binding logic you get from Vulkan or D3D12 is getting too expensive for the object counts we're trying to push in modern games.
Bindless lets you reduce the amount of book keeping you have to do per-object on the CPU, but much more importantly opens the door for GPU driven rendering.
The problem with WebGPU is there's no bindless and the 'bindful' path is quite expensive to meet the safety requirements of a browser API. There's no way around the slow path, and the slow path is quite slow. In this case the workaround is cut features because the API simply imposes too much overhead.
BindGroups being a hard to fix design wart is true indeed (which I have been complaining about pretty much from the beginning, not because of the performance problems - which surprised me too - but because of their inflexibility compared to a traditional bindslot based model like in Metal1 or D3D11).
But I would prefer to first bring the peformance of the slot-based binding model to a point where it is similar to D3D11 or Metal instead of ignoring that part of the API and 'skipping ahead' to bindless (which will probably have to be behind an extension anyway). Otherwise WebGPU will become a cemetery of abandondend attempts like OpenGL.
As far as I know, Unity doesn't support bindless either. However thousands of Unity games are released on Steam every year. So it's safe to say performance isn't the main (or major) reason why Rust gamedev isn't getting much traction.
That limits Unity's scene size. See [1].
[1] https://discussions.unity.com/t/gpu-bindless-resources-suppo...
Yes, it introduces limits (duh), but doesn't change the fact that there are plenty of Unity3d games that not only sold well, but also perform well.
The lack of traction is mostly because Rust game development, with exception of Bevy efforts, it is still pretty much on the dark ages of everything is code.
The industry has moved beyond that, with teams where programmers only have a minor role (quite important nontheless), on the whole game design, with plenty of tooling for designers and other non-programmer folks to do their tasks.
Eventually with more graphical tooling, or scripting systems, it will start to gain more steam.
Note that TinyGlade also created most of their tooling in-house, they only partially depend on Bevy.
Another reason is that exploratory programming is hard by design in Rust. Rust is great if you already have a spec and know what needs to be done.
Most of the gamedev in my opinion is extremely exploratory and demands constant experimentation with design. C/C++ offer fluidity, a very good and mature debug toolchain, solid performance ceiling and support from other people.
It will be really hard to replace C++ in performance/simulation contexts. Security takes a backseat there.
Author of Renderling here. Thanks for the shout out Animats!
Bindless is a game changer - pun intended. It can’t happen soon enough.
Just curious, what are the three major projects that were cancelled?
I also want to mention that folks are shipping high performance games in Rust - the first title that comes to mind is “Tiny Glade” which is breathtakingly gorgeous, though it is a casual game. It does not run on wgpu though, to my knowledge. I may have a different definition of high performance, with lower expectations.
> What are the three major projects that were cancelled?
Here are some:
- LogLog Games [1]. Not happy with Bevy. Not too unhappy about performance, although it's mentioned.
- Moonlight Coffee [2]. Not a major project, but he got as far as loading glTF and displaying the results, then quit. That's a common place to give up.
- Hexops. [3] Found Rust "too hard", switched to Zig.
Tiny Glade is very well done. But, of course, it's a tiny glade. This avoids the scaling problems.
[1] https://news.ycombinator.com/item?id=40172033
[2] https://www.gamedev.net/blogs/entry/2294178-abandoning-the-r...
[3] https://devlog.hexops.com/2021/increasing-my-contribution-to...
It's crazy you've cited Hexops as an example:
1. It's a game studio not a project (CEO here :))
2. It's very much still alive and well today, not 'cancelled'
3. We never even used WebGPU in Rust, this was before WebGPU was really a thing.
It is true that we looked elsewhere for a better language for us with different tradeoffs, and have since fully embraced Zig. It's also true that we were big proponents of WebGPU earlier on, and have in recent years abandoned WebGPU in favor of something which is better for graphics outside the browser (that's its own worthwhile story)..
But we've never played /any/ role in the Rust gamedev ecosystem, really.
I think the future is getting rid of all the APIs and driver overhead, compile directly to GPU compute and write your own software renderers in a language targeting GPUs (Could be Zig)
A better way to think about the problem is to recognize that the APIs and drivers are providing various services that pretty much every user is going to need, and which you will now need to reimplement yourself.
Nobody needs all of Vulkan, but everyone needs quite a bit of it. Buffer allocation? Command encoding? Scheduling? Synchronization? Abstracting GPU architecture differences (and GPUs vary a lot)? Render pipeline fixed-function stages like primitive assembly, tiling, and blending? You're signing up to implement all of that - good luck!
In this view, your idea is the assertion, "I could do a better job at all that stuff than the driver developers." Maybe so! They're only human. Drivers do have bugs. But you're only human too.
I agree; however, engine developers are already dedicated to building massive behemoths of software that is the game engine and they constantly do collaborate with driver devs, essentially sharing much of the same skillset.
Also, the onus is actually on the GPU manufacturers (not game engine devs) to simplify the programmability of the GPUs to the level we have for CPUs (we also do not write microcode, however, the programmability is much much simpler with access to good compiler toolchains). This will massively help non game engine developers who need GPUs for other kinds of compute.
Check out https://renderling.xyz/
None of those are “major projects” by any definition of the word though. And none of the three has anything to do with wgpu's performance.
Rust for game engine has always been a highly risky endeavor since the ecosystem is much less mature than everything else, and even though things have improved a ton over the past few years, it's still light-years away from the mainstream tools.
Building a complete game ecosystem is very hard and it's not surprising to see that Rust is still struggling.
Tiny glade isn’t tiny on the rendering side. It does gorgeous, detailed landscapes.
Indeed, they also do most of the stuff custom.
I thought WGPU only supported WebGPU, and then there were translation libraries (akin to Proton) to run WebGPU over Vulkan.
Does it directly, internally, support Vulkan instead of on-the-fly translation from WebGPU to VK?
WGPU (https://wgpu.rs/) is one of currently three implementations of the WebGPU specification (the other two being Google's Dawn library used in Chrome, and the implementation in WebKit used in Safari).
The main purpose of WebGPU is to specify a 3D API over the common subset of Metal/D3D12/Vulkan features (e.g. doing an 'on-the-fly translation' of WebGPU API calls to Metal/D3D12/Vulkan API calls, very similar to how (a part of) Proton does an on-the-fly translation of the various D3D API versions to Vulkan.
You're describing the WebGPU spec and its different implementations.
OP claimed WGPU had native support for VK, DX and others. But as far as I know, WGPU just supports WebGPU being translated on the fly to those other backends, with the obvious performance hit. If I'm wrong, I'd be interested to know, as this would make WGPU a more interesting choice for many if, in reality, the code was native instead of translation.
Edit: https://docs.rs/wgpu/latest/wgpu/#backends it seems they indeed support native code in almost every backend?
I don't understand the question...
Those three WebGPU implementation libraries are compiled to native code (they are written in Rust or C/C++), and at least WGPU and Dawn are usable as native libraries outside the browser in regular native apps that want to use WebGPU as a cross-platform 3D API.
Yet still, those native libraries do a runtime translation of WebGPU API calls to DX/Vk/Metal API calls (and also a runtime translation of either WGSL or SPIRV to the respective 3D backend API shading languages) - in that sense, quite similar to what Proton does, just for a different 'frontend API'.
Then performance of WGPU will always be problematic, below that of the native APIs (DX, vk and Metal), and constrained within the limits of the WebGPU spec.
Within the constrains of the browser sandbox and 10 year old hardware, which is when its design started.
I think it's more about low-end mobile GPUs which WebGPU needs to support too (which is also the main reason why Vulkan is such a mess). The feature gap between the low- and high-end is bigger than ever before and will most likely continue to grow.
I am yet to see anyone deliver in WebGL something at the level of Infinity Blade that Apple used to demo OpenGL ES 3.0 capabilities of their 2011 iPhone model, a mobile phone GPU from almost 15 years ago.
Unless we are talking about cool shadertoy examples.
That's more a business problem than a technical problem. Web games are in a local maximum of minimal production cost (via 2D assets) versus maximized profits (via free-2-play), and as long as this works well there won't be an Infinity Blade because it's too expensive to produce.
Yeah, but then what do we want this technology for, besides visualisations and shadertoy demos?
Streaming solves the business case, with native APIs using server side rendering.
At least it breaks up a chicken-egg problem, and the most interesting use cases are the ones that nobody was expecting anyway.
> Streaming solves the business case, with native APIs using server side rendering.
And yet history is littered with the dead husks of game streaming services ;)
The chicken egg problem caused by killing Flash games, and that nowadays no one cares about the browser, because everyone doing Flash moved into mobile phones or Steam, with better APIs?
Game Pass, GeForce Now, are doing alright.
Stadia failed, because Google doesn't get games industry.
Tiny Glade? https://store.steampowered.com/app/2198150/Tiny_Glade/
Tiny Glade is Vulkan, not WebGPU. Not sure which library though
Where is the URL for the game on the browser?
Try this Unreal Engine 5 WebGPU demo: https://play.spacelancers.com/
Demo, not game.
Shadertoy is full of impressive demos.
The tone of the thread was perfectly fine until you made a passive aggressive comment
> The default texture limits without bindless are also way too small for serious applications
I'm not disagreeing that bindless is needed but it's a bit of hyperbole to claim the texture limits are too small for serious applications given the large list of serious graphics applications that shipped before bindless existed and the large number of serious graphics applications and games still shipping that don't use them.
It's partly because WebGPU has very conservative default texture limits so that they can support old mobile devices, and partly it's a problem for engines that may have a bunch of different bindings and have increasingly hacky workarounds to compile different variants with only the enabled features so that you don't blow past texture limits.
For an idea of bevy's default view and PBR material bindings, see:
* https://github.com/bevyengine/bevy/blob/main/crates/bevy_pbr...
* https://github.com/bevyengine/bevy/blob/main/crates/bevy_pbr...
They're talking about the 16 sampled texture binding limit which is the same as webgl2. If you look at eg. the list of devices that are stuck with that few texture bindings they don't even support basic GL with compute shaders or vulkan, so they can't even run webgpu in the first place.
Yes. If you're stuck with that limitation, you pack up related textures into a big texture atlas. When you enter a new area, the player sees "Loading..." while the next batch of content is loaded. That was the state of the art 15 years ago. It's kind of dated now.
You might be getting “sampled textures in a single call” with “total textures loaded” mixed up. Sampled texture limits affect complexity of your shader and have nothing to do with loading content from elsewhere.
Quick note: I looked at the bindless proposal linked from the blog post and their description of Metal is quite outdated. MTLArgumentEncoder has been deprecated for a while now, the layout is a transparent C struct that you populate at will with GPU addresses. There are still descriptors for textures and samplers, but these are hidden from the user (the API will maintain internal tables). It's a very convenient model and probably the simplest and most flexible of all current APIs. I'd love to see something similar for WebGPU.
The nice thing about WebGPU's "compat mode" is that it's designed so browsers don't have to implement it if they don't want to. Chrome is really excited about it; Safari has no plans to implement it, ever.
I agree that compat mode takes up more of the WebGPU standard committee's time than bindless. I'm not sure that's how I would prioritize things. (As a Mozilla engineer, we have more than enough implementation work to do already, so what the committee discusses is sort of beside the point for us...)
What would be really helpful is if, once the bindless proposal <https://hackmd.io/PCwnjLyVSqmLfTRSqH0viA?view> gets merged into the spec repo <https://github.com/gpuweb/gpuweb/tree/main/proposals>, a contributor could start adapting what WGPU has now to match the proposal. Implementation experience would be incredibly valuable feedback for the committee.
You don't have to settle for the default limits. Simply request more.
We do when there available, but I think the way browsers implement limit bucketing (to combat fingerprinting) means that some users ran into the limit.
I never personally ran into the issue, but I know it's a problem our users have had.
That makes sense. I bet the WebGPU WG would be interested in hearing about that experience. They might be able to make changes to the buckets.
Yeah I went down the rabbit hole of trying to rewrite all our shaders to work on webgpu’s crazy low limits. I’m embarrassed to say how long I worked that problem until I tried requesting higher limits, and it worked on every device we were targeting.
The default limits are like the lowest common denominator and typically way lower than what the device actually supports.
It only goes to show the limitations of browser 3D APIs, and the huge mistake some folks do for native games using it instead of a proper middleware engines, capable of exposing modern hardware.
I don't necessarily disagree. But I don't agree either. WebGPU has given us as many positives as it has negatives. A lot of our user base is not on modern hardware, as much as other users are.
Part of the challenge of making a general purpose engine is that we can't make choices that specialize to a use case like that. We need to support all the backends, all the rendering features, all the tradeoffs, so that our users don't have to. It's a hard challenge.
Basically the goal of any middleware engine, since the dawn of time in the games industry.
Any word on when it'll be supported on Linux without a flag?
I don't think Google cares. If it works on Chromebooks and most Android phones, their job is done. On to the next API, let's make WebWiFi or WebAI.
WebGPU demos never work for me, so I personally consider the tech dead until that gets fixed. WebGL is barely stable enough to use as well, so I guess I'll just have to keep doing GPU stuff outside of the browser.
When they see a business value on GNU/Linux Desktop WebGPU support for Chrome, note that other Linux kernel based systems from Google already support it.
My guess is when someone one who cares about Linux submits a pull request to support it.
So that's how it worked with MacOS and Windows? Color me surprised.
But bth, Google doesn't seem to care about Android either. Chrome supports it on Snapdragons and that's it. Do you have Xclipse GPU? Like, I don't know, Samsung's current flagship line Galaxy S24 does? Too bad, not good enough.
> So that's how it worked with MacOS and Windows? Color me surprised.
Lots of people use MacOS and Windows though, so Google has incentive to support these platforms.
Honest question: Can someone explain to me why people are excited about WebGPU and WASM and similar technologies?
To me, one of the greatest things about the web is that the DOM is malleable in that you can right click -> view source -> change things. This is dead in an era where the server just sends you a compiled WASM dll.
It seems to me that the inevitable result of things like WASM and WebGPU will be "rich media web 4.0 applications" that are just DRM, crypto miners, and spyware compiled so that they're more difficult to circumvent, and delivered via the browser. An excuse to write web apps with poor performance because "well the user just needs a stronger GPU". It seems like an express train back to the bad old days of every website being written in flash.
I honestly cannot see the upsides of these technologies. Is it gaming? Why would I want to play a 3D game in my fucking browser of all places? That's a strict downgrade in almost every way I can think of. Why would anyone want that? Is it "AI"? Why would I want to run an LLM in the browser, I could just run it natively for better performance?
All I can see and have seen over the last several years is a steady parade of new technologies that will make the internet (and in some cases the lives of every day people) objectively worse while enriching a handful of big tech douchebags.
Why are we going down this path? Who is asking for this stuff? Why the fuck would I want to expose my GPU to a website?
> Why would I want to play a 3D game in my fucking browser of all places?
To provide users a way to instantly play a game without having to download all assets at once. Give developers a potential way to avoid app store royalties of up to 30% on desktop or mobile. With wgpu in rust, you can also target WebGPU as a shared 3d runtime that will run across OS's natively rather than having to target Vulkan, Metal, and DirectX.
> Why would I want to run an LLM in the browser, I could just run it natively for better performance?
What about users who don't know how to download a model and run it locally? I would argue this is the vast majority of users in the world. Also, this specific use case is probably not going to be generalized with WebGPU yet due to model sizes, but rather other APIs like the Prompt API in Chrome which will use Gemini Nano embedded into the browser (assume it will eventually get standardized). https://developer.chrome.com/docs/ai/built-in-apis
I agree with you that WASM and WebGPU will be used for adware, targeting, and spyware - but if you don't want to use them, you should disable them in your browser settings - there's definitely value add for other users even if you can't see any benefits.
Browsers will never run games that aren't toys or use very simple assets in a way that doesn't completely suck. High quality assets need gigabytes of data. You either require users to download all the assets upfront (the thing we're trying to avoid) or streaming the assets dynamically.
You end up having to re-implement steam to keep a local copy of the assets on the client device yourself, expect browsers to do the same to manage caching the gigabytes of data transparently, or design your game around a very slow storage device or use tiny assets.
Flash games worked because they fit very nicely into the 'tiny assets' category.
PWA to cache everything locally?
Streaming assets seems reasonable.
>To provide users a way to instantly play a game without having to download all assets at once
There's a reason QuakeLive didn't catch on and it's because streaming resources to the player makes for awful UX.
>What about users who don't know how to download a model and run it locally?
Those users also don't know how to compile MS Word from source but they have been getting along just fine with installers.
The ability to paste a URL into a browser and have that be everything you need to do to play a game is pretty compelling for many kinds of games.
That’s what made flash games so big back in the day.
URLs can also be mapped into native applications, it is a matter of the right OS.
https://developer.android.com/training/app-links
That’s a different flow though.
Pasting URL into browser, then having access to game
Vs
Pasting url in browser Get link to install app Install app Navigate to the original url again.
Technical capabilities don’t always change user experience
Application streaming, no need for installation before using.
That needs a hell of a lot of sandboxing before I get anywhere near it. Which sounds like a good use for WASM and WebGPU.
> To provide users a way to instantly play a game without having to download all assets at once
No need for the web in that case, which is inefficient. You can do with like those 1MB installers and stream those assets.
> but if you don't want to use them, you should disable them in your browser settings
Which the majority won't. People don't even go in their phone settings, apart from connecting to WiFi and changing their wallpaper.
I don’t want to download a random executable from some unknown source. However, I trust the browser sandbox.
> I don’t want to download a random executable from some unknown source
Why would you do that?
---
There's few applications that warrant having direct access to the GPU and other devices. And for those, a native app would be a much efficient way (for the user).
yeah but users don't care about technical efficiency, they care about having seamless experiences that aren't interrupted by long downloads, app/context switching, and loading screens.
Which the web doesn't provide. Try opening Figma and Sketch at the same time or Mail.app and Gmail. Google Doc is closer to Wordpad than Libreoffice.
I however don't trust the browser sandbox when it is continuously expanded with bloat that normal websites don't need.
Application streaming sorts that out, with much better tooling for 3D development.
> Can someone explain to me why people are excited about WebGPU and WASM and similar technologies?
WebAssembly brings all languages to the browser. Why shouldn't I be able to use C#, Rust, Go, Dart, Python, or whatever else in browser?
WebAssembly brings better performance. That's what Webamp found: https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...
And what Amazon found: https://www.amazon.science/blog/how-prime-video-updates-its-...
And what Google found: https://web.dev/case-studies/google-sheets-wasmgc
Why make things perform worse when they can perform better?
Why shouldn't I be able to make an application that compiles to the Windows, macOS, and Linux desktops and also to the browser? This one does: https://bandysc.github.io/AvaloniaVisualBasic6/
> WebAssembly brings all languages to the browser. Why shouldn't I be able to use C#, Rust, Go, Dart, Python, or whatever else in browser?
This has zero end-user benefit. While having the end-user drawbacks gp mentioned (reduced ability to inspect and modify content).
> WebAssembly brings better performance.
Wirth's law says "hold my beer".
For that matter, why would you expose your CPU to a website? Or your monitor? It could show you anything! ;)
Maybe you are not be aware of the number of good web apps that use some WebGL under the hood? You might be using office applications in your browser already that use WebGL when it’s available, and the reason is it makes things faster, more responsive, more scalable, and more efficient. Same would go for WebGPU.
There’s no reason to imagine that the web will do bad things with your resources that you didn’t ask for and don’t have control over. There have been hiccups in the past, but they got fixed. Awareness is higher now, and if there are hiccups, they’ll get fixed.
>There’s no reason to imagine that the web will do bad things with your resources that you didn’t ask for and don’t have control over.
The web is like this right now. Why would things magically become a utopia?
> There’s no reason to imagine that the web will do bad things with your resources that you didn’t ask for and don’t have control over.
Read some security update news from browser vendors and vulnerability researcher posts. There's some weak signals about vendors acknowledging the difficulty of securing the enormous attack surface of browsers built on unsafe foundations, eg MS "enhanced security mode" and Apple "lockdown mode".
I don't mind the browser using the GPU to speed up graphical operations. But I do mind random sites and apps going further than that. Native apps have better access, but there's an higher selection criteria than just opening a URL.
It's interesting to me you don't like any WebGL websites. I remember first trying Minecraft Java in the browser and it was awesome.
Runescape! I grew up playing Runescape! How could anyone not want games like Runescape to exist?!?
Last time I checked Runescape switched to a native client, too. And even in the browser back in the day it used to run absolutely terribly, so I hope we're not trying to replicate that experience.
> How could anyone not want games like Runescape to exist?!?
I mean, I wouldn't say I don't want it to exist. But Runescape is one of the shittiest, most boring games I've ever played. It's not exactly a strong argument for why we should run stuff in the browser
I agree. Trying to shove everything into the browser is absolutely stupid. Native apps are better than doing things in the browser in almost all cases. But that's not trendy, so people don't chase after it.
> Native apps are better
Native operating systems are garbage at maintaining user privacy and become maintenance burdens when too many applications have been installed and even uninstalled on the machine.
While not perfect, a browser tab is a stronger sandbox than you can easily get in any other context.
We won't stop until the entire web has been enshittified.
Why do you think wasm is harder to circumvent? The only way to instantiate a wasm module in the browser is through (drum roll) javascript. Install noscript if you're worried. The days of view source -> edit are basically over anyway due to every site's 1MB+ minified JS blobs.
> Why would I want to run an LLM in the browser, I could just run it natively for better performance?
Why would you try out a new app in a sandboxed browser, when instead you could give it complete access to your entire computer?
If the app can run arbitrary code on my GPU it's not exactly sandboxed, is it?
Are you launching Chrome with --disable-gpu-sandbox? If not, it's sandboxed.
If websites can run compute shaders on my hardware, that's not a sandbox.
Sandboxing is about preventing code from accessing data it's not supposed to. Data like files or memory belonging to other tabs or other processes. Or data streams like your webcam or microphone. Data outside of its, well, sandbox.
So how are compute shaders accessing data they're not supposed to? How do you think they're escaping the sandbox?
It seems like you're just making up your own definitions now because you don't like the tech. What do think a sandbox is, exactly? And what do you think Chrome's GPU sandbox does, if it's not a sandbox?
do you have a proof of concept that uses webgpu shaders to extract sensitive data?
The search term you're looking for is "monero miner"
this exfiltrates data somehow? looking forward to the poc
If websites can run JavaScript on your hardware, is that not sandboxed?
You should try Chillin(https://chillin.online), browser-based video editor. Powered by WebGL, WASM, and WebCodecs, Chillin provides a full suite of video editing capabilities on the web. Trust me, Chillin is smoother than most native video editors, even on mobile. I believe Chillin can leverage WebGPU to bring even more powerful rendering features.
Yes, running LLMs on the web may not have significant advantages due to the speed limitations, but other models, such as those for bg removal, speech-to-subtitles, and translation, could become practical and efficient thanks to WebGPU.
Users wanted an app sandbox.
HTML documents were sort-of like an app sandbox.
Evolution is now adding an app sandbox to HTML.
There is little we can do to resist it. I don't like it either - I hate HTML.
Figma, my dude
[flagged]
Linux support please!
They say:
"This is the next step in the standardization process, and it comes with stronger guarantees of stability and intellectual property protection."
I understand stability, and in the general sense I see that people feel they need to protect their IP, but in this specific case what is meant by "intellectual property protection"?
W3C generally requires Working Group participants to provide IPR licensing commitments for the spec in question [0]. As far as I understand, higher level of specification maturity implies stronger level of obligations, though the specifics of what specifically changes when were never clear to me.
[0] https://www.w3.org/policies/patent-policy/#sec-Requirements
I think it means protection from intellectual property claims in the future.
I wish there were a good way to profile WebGPU code. I've seen this (very useful) article[1] on setting up PIX, but I'm ambitious. I want to see everything from draw call timings to flamegraphs of shader code.
Right now I feel like the only way to write efficient WebGPU code is to deeply understand specific GPU architectures. I hope some day there's a dev tools tab that shows me I'm spending too much time sampling a texture or there's a lot of contention on my atomic add.
[1]: https://toji.dev/webgpu-profiling/pix.html
Timestamp queries will give you essentially time spans you can use for profiling, but anything more than that and you really want to use a dedicated tool from your vendor like NSight, RGP, IGA, XCode, or PIX.
> Right now I feel like the only way to write efficient WebGPU code is to deeply understand specific GPU architectures. I hope some day there's a dev tools tab that shows me I'm spending too much time sampling a texture or there's a lot of contention on my atomic add.
It's kind of the nature of the beast. Something that's cheap on one GPU might be more expensive on another, or might be fine because you can hide the latency even if it's slow, or the CPU overhead negates any GPU wins, etc. The APIs that give you the data for what you're asking are also vendor-specific.
That's fine—same with CPUs, right? But if I do something that's slow on _my_ CPU, at least there's tooling that will show me!
I know that the reason is a lot of technical complexity (plus little standardization between vendors), but I think the end goal should be to make GPU programming more accessible.
I don't disagree, but good luck getting vendors to standardize on anything...
Can forget about it.
Developer tooling for debugging 3D Web APIs has been a continuous request since WebGL 1.0, from 2011.
Until now the only thing that ever came out of it was SpectorJS and it shows its age.
For a while Firefox did have a debugger, that they eventually removed from developer tools.
You are left with writing the application twice, so that can make use of modern native debugging tools for graphics programming.
I've used [0] to profile WebGPU code w/ Nvidia Nsight, but yes better tools built into Chrome would be very nice.
[0] https://frguthmann.github.io/posts/profiling_webgpu/
awesome, I'll give it a shot. I'd lost all hope of ever getting Nsight to hook into WebGPU
I'm curious why supporting ML algorithms is important inside browser ? Will my machine be improperly utilized by the sites I visit ?
It can absolutely be used for bad, and I know many sites do use it for bad. However, it does good as well, and I think it's important to develop but also it should come with similar permission requests that use of microphone or camera do.
I do research and develop ANN's for data analysis within chemistry. Making it possible for less tech literate people to visit a site, select a model, load their dataset, and get answers, is quite handy. The best part is because I can use their hardware to do it all, it all stays private, no one has to upload any sensitive research data etc. and I don't have to ship to various devices etc. I know if they have a mainstream updated browser they can likely use the tool. No endless requests for help, no mystery issues to solve, things just work.
> it should come with similar permission requests that use of microphone or camera do.
Such permissions requests have been associated I think exclusively with input and output, not computation.
Right, but I think it should change. I think consumers should have a say when a website wants to compute things that are out of scope for a normal page of text/information. I certainly dont want my laptop hot, slow, an poorly responsive because some news site's borderline malware is running several poorly built and implemented models that aim to track and predict my behaviour from mouse movement etc.
We've already seen Javascript cryptocurrency miners, so when WebGPU starts actually being used I suspect we'll see their use rise to new heights. It's a matter of time until some website starts offering WebGPU crypto mining as an alternative to their paywall.
Why offer it as an alternative when it can be done in addition to existing monetization.
Lot of downvote for my curiosity
What's the Firefox compatibility looking like now? Pretty annoying when websites that use it tell you to download and install google chrome.
I could use more 2-d line support for CAD applications as well as font drawing.
Font drawing is very much out of scope for a 3D API, that's something you (or a library) would implement on top of WebGPU. Likewise for line drawing, the API may expose some simple line primitives that the hardware supports natively, but if you want anything fancier then you're expected to do it yourself with shaders which is already possible in WebGPU.
The 3D API is just meant to be a minimal portable abstraction over common low-level hardware features, composing those features into higher level constructs is intentionally left as an exercise for the user.
The problem is now you have to have all sorts of additional libraries you need to load across a network.
Web APIs need more standardized functionality built in, including high-level ones, and not rely on additional libraries, because they have to download across a network.
It's like having to install an app every time you visit a site.
I mean, they are extending support for Canvas2D, which from what I believe would allow for easier text rendering.
There are libraries building on top of WebGPU for that, like:
https://github.com/linebender/vello
and (shameless plug):
https://github.com/Lichtso/contrast_renderer
Asking for lines is like asking for your CPU to support macros. The GPU is low-level, lines are high level. You build the high level on top of the low-level with libraries etc...
The Canvas2D interop feature should make it very easy to draw text to a 2D canvas and then pull that into WebGPU as a texture.
WebGPU does have line primitives of course, but only the type of lines that's supported in the underlying 3D APIs (e.g. 1-pixel wide). Since the whole purpose of WebGPU is to provide a thin API over the common feature set of D3D12, Metal and Vulkan that's totally expected though.
Same. I do a ton of 2D map stuff and it’s always quite uncomfortable to do in shaders or very slow in a Canvas context.
The last time I tried with pixi.js the problem was smoothly zooming polygons with a constant width border thicker than hairline. Doing that was basically just generating new textures on every frame.
Just out of curiosity, what is uncomfortable about writing shaders, in your opinion?
debugging
I agree completely.
Don't know for you but for me the next thing for WebGPU is uninstalling Google Chrome. Manifest v3 my ass.
My team (third party) has developed WebGPU support for Unreal Engine 5, along with an asset-streaming system that solves the large download, multi-gigabyte game in your webpage issue by only loading in what a player needs to see at any given moment. It's constantly loading and unloading data, which helps tremendously with memory management.
WebGPU is going to usher in a new era of web games, the biggest benefit being compute shaders which have never before been possible inside the browser.
DISCLAIMER - Will only work on a Windows device running Chrome or a Chromium browser. Mac and iOS isn't well supported yet.
Space demo - https://play.spacelancers.com/
Forest demo - https://play-dev.simplystream.com/?token=bd4ca6db-522a-4a73-...
This was cool (spacelancers didn't work in Arc but did in Chrome, forest demo 403's) - audio and fullscreen fail because they aren't initiated by a user gesture. Impressive how quick it is to get into a game with this level of fidelity, normally you'd need several minutes of downloading.
> DISCLAIMER - Will only work on a Windows device running Chrome or a Chromium browser.
It loaded, but "work" is a stretch. It was a multiple second lag to react to input. Very choppy.
Aw neither works on iOS 18.2
Nor Linux.
So basically Webgpu is just another graphics API for targeting Windows. Yay.
Linux isn't supported currently, doesn't mean it won't be in the future.
Well, until it is, I'm not wasting a minute of my time on it.
Yeah WebGPU isn't officially enabled by default on Safari yet, but that's actually not what's stopping these demos from working.
Once we mobile optimize, they should work well.
[dead]
Whom is WebGPU for, besides Unity?
Responding to your pre-edited comment.
> whom is WebGPU for? […] it’s a huge rigamarole.
Where is this comment coming from? WebGPU enables compute shaders, and there are applications in anything that uses a GPU, from ML to physics to audio to … you name it. What is making you think game engines would be the only users? I bet a lot of companies are looking forward to being able to use compute shaders in JS apps and web pages.
> Godot has had zero development for WebGPU support.
Why would Godot be an indicator? I love Godot and their efforts, but it’s less than 1% of game engine market share, and a much smaller less well funded team. Of course they’re not on the bleeding edge. Unity is closer to 30% market share and is actively engaging with WebGPU, so it seems like you’re downplaying and contradicting a strong indicator.
I edited my comment.
> WebGPU enables compute shaders, and there are applications in anything that uses a GPU, from ML to physics to audio to … you name it.
I know.
If you have to go through a giant product like Unity for example to use WebGPU because Apple will essentially have its own flavor of WebGPU just like it has its own flavor of everything, is it really cross platform?
Does Apple support Vulkan? No. It was invented for middlewares!
Apple has a flag to toggle on WebGPU on iOS today. I know dude. What does that really mean?
They have such a poor record of support for gamey things on Mobile Safari. No immersive WebXR, a long history of breaking WASM, a long history of poor WebGL 2 and texture compression support. Why is this going to be any different?
I’m still not sure what the point is. WebGPU is an API, is that that you mean by middleware? What’s the issue? Apple will do their own thing, and they might not allow WebGPU on Safari. What bearing does that have on what people using Linux, Windows, Firefox, and Chrome should do? And where exactly is this cross platform claim you’re referring to?
> Apple will do their own thing, and they might not allow WebGPU on Safari.
Safari has WebGPU support today, albeit behind a feature flag until it's fully baked. https://imgur.com/a/b3spVWd
Not sure if this is good, but animometer shows an Avg Frame time of ~25.5 ms on a Mac Studio M1 Max with Safari 18.2 (20620.1.16.11.6). https://webgpu.github.io/webgpu-samples/sample/animometer/
The demo is doing a setBindGroup per triangle, so not exactly surprising since this is a well known bottleneck (Chrome's implementation is better optimized but even there setBindGroup is a surprisingly slow call). But since both implementations run on top of Metal there's no reason why Safari couldn't get at least to the same performance as Chrome.
The issue is, it's likely that a company with $2 BILLION spent on product development and a very deep relationship with Apple, like Unity, will have success using WebGPU the way it is intended, and nobody else will. So then, in conclusion, WebGPU is designed for Unity, not you and me. Unity is designed for you and me. Are you getting it?
> The issue is, it's likely that a company with $2 BILLION spent on product development and a very deep relationship with Apple, like Unity, will have success using WebGPU the way it is intended, and nobody else will.
Not really. Bevy https://bevyengine.org uses WebGPU exclusively, and we have unfortunately little funding - definitely not $2 billion. A lot of the stuff proposed in the article (bindless, 64-bit atomics, etc) is stuff we (and others) proposed :)
If anything, WebGPU the spec could really use _more_ funding and developer time from experienced graphics developers.
I agree with you, Bevy is a worthy cause.
Why are people downvoting? The idea of Great High Performance Graphics Effortlessly on All Platforms is very appealing. It is fundamentally empathetic. It is an opium to game developers whose real antagonist is Apple and Nintendo, and who want a more organic journey in game development than Unity Learn. Is it a realizable goal? Time will tell.
Everyone should be advocating for more focused efforts, but then. Are you going to say, Bevy is better than Godot? It’s subjective right? Open source efforts are already spread so thin. An inability to rally behind one engine means achieving 2013’s Unity 5 level of functionality is years away.
Looking at it critically, in fact much effort in the open source ecosystem is even anti games. For example emulators used to pirate Nintendo Switch games have more mature multiplatform graphics engine implementations than Godot and Bevy do. It would be nice if that weren’t true, you might tell me in some sense that I am wrong, but c’mon. It’s crazy how much community effort goes into piracy compared to the stuff that would sincerely benefit game developers.
WebGPU is authored by giant media companies, and will have purposefully hobbled support by the most obnoxious of them all, Apple - the one platform where it is kind of impractical to pirate stuff, but also, where it is kind of impractical to deliver games through the browser. Precisely because of the empathetic, yet ultimately false, promises of WebGPU.
Why are you bringing up Godot again? Are you worried Godot will be left behind or unable to compete with Unity? Are you working on Godot? Why are you focused exclusively on games? What are the ‘false promises’ of WebGPU, and why do you think it won’t deliver compute shaders to every browser that supports it, like it says? I’m just curious, I get the sense there’s an underlying issue you feel strongly about and a set of assumptions that you’re not stating here. I don’t have a lot invested in whether WebGPU is adopted by everyone, and I’m trying to understand if and why you do. Seems like compute shaders in the browser will have a lot of interest considering the wild success of CUDA. Are you against people having access to compute shaders in the browser?
> What are the ‘false promises’ of WebGPU
That you can write a "compute shader" once, and it will run "anywhere." This isn't the case with any accelerated compute API, so why is WebGPU going to be different?
Reality will be Chrome Windows Desktop WebGPU, Chrome Android (newish) WebGPU, Mobile Safari iOS 18 WebGPU, iPad WebGPU, macOS Safari WebGPU, macOS Chrome WebGPU, iOS default in app browser WebGPU, Instagram and Facebook in app browser WebGPU...
This isn't complicated! If that's reality, I'd rather have:
Apple Compute Shaders for Browser. Windows Chrome Compute Shaders for Browser. Android Chrome Compute Shaders for Browser.
Because I'm going to go through a middleware like Unity to deal with both situations. But look at which is simpler. It's not complicated.
> I’m trying to understand if and why you do.
I make games. I like the status quo where we get amazing game engines for free.
I cannot force open source developers to do anything. They are welcome to waste their time on any effort. If Bevy has great WebGL 2 support, which runs almost without warts everywhere, even on iOS, for example, it makes no sense to worry about WebGPU at all, due to the nature of the games that use Bevy. Because "runs on WebGPU" is making-believe that you can avoid the hard multiplatform engine bits. Engines like Construct and LOVE and whatever - 2D games don't need compute shaders, they are not very performance sensitive, use the browser as the middleware, and the ones that are, they should just use a huge commercial game engine. People have choices.
> That you can write a "compute shader" once, and it will run "anywhere."
Can you post a link to that quote? What exactly are you quoting?
It seems like you’ve jumped to and are stuck on a conclusion that isn’t really supported, somewhat ignoring people from multiple companies in this thread who are actively using WebGPU, and it’s not clear what you want to have happen or why. Do you want WebGPU development to stop? Do you want Apple to support it? What outcome are you advocating for?
Unity spends the vast majority of its money on other things, and Unity isn’t the only company that will make use of WebGPU. Saying nobody will have success with it is like saying nobody will succeed at using CUDA. We’re just talking about compute shaders. What is making you think they’re too hard to use without Apple’s help?
You haven't substantiated why nobody else could make use of WebGPU. Are Google the only ones who can understand Beacons because they make $300B/year? GPU is hard, but it doesn't take billions to figure out.
There are already open source projects making use of WebGPU, e.g. wgpu.
[dead]
Apple submitted Metal as a web spec and they turned this into WebGPU and Apple got everything they asked for to avoid apple going rogue again. The fear that Apple of all companies is going to drop WebGPU support is really not based in reality.
> because Apple will essentially have its own flavor of WebGPU
Apple's WebGPU implementation in Safari is entirely spec compliant, and this time they've actually been faster than Firefox.
I wish Apple made a standalone Webgpu.framework spinning it off of WebKit so that apps can link to it directly instead of having to link to Dawn/wgpu.
Sounds like an interesting idea at first until the point where they will probably create a Swift/ObjC API around it instead of the standard webgpu.h C API, and at that point you can just as well use Metal - which is actually a bit less awkward than the WebGPU API in some areas.
Maybe it makes more sense as a community project. Not sure how difficult it'd be to extract it from Webkit...
The number 1 use of WebGL is Google Maps by several orders of magnitude over any other use. At some point they'll likely switch to WebGPU making it the number 1 use of Google Maps. Google went over what this enables when they shipped it. Lots of features including being able to highlight relevant roads that change depending on what you searched for.
https://www.youtube.com/watch?v=HrLyZ24UcRE
Apple maps and others also use it
Web video editor(https://chillin.online), we are eagerly looking forward to the WebGPU API maturing and being extended to all major browsers, enabling faster rendering, bringing more effects, and facilitating the rendering and editing of 3D assets.
Devs in the future? There was a long time between when WebGL2 released and when it finally worked "everywhere" too.
I'm new to GPU programming, and WebGPU and Rust's wgpu seem pretty nice to me (except the bindings!). The API is high-level enough that it's easy to learn. It hasn't grown deprecated parts or vendor-specific extensions yet.
Our browser based game engine Construct (https://www.construct.net) supports rendering with both WebGL and WebGPU.
When I visit a Construct 3 Ultra Pixel Survive on Mobile Safari on the latest production iOS with either WebGPU enabled and disabled, I only see black:
https://www.construct.net/en/free-online-games/ultra-pixel-s...
Which Construct 3 game should I try on Mobile Safari?
I know there are other game engines. Supporting Mobile Safari is very very hard. It has its own flavor of everything. I would never speak in absolutes about some web standard and how it will work on Mobile Safari.
Runs great on Android!
Then you agree that WebGPU isn't for Construct, it's for Unity.
No. How does that follow?
You realize that WebGPU has not shipped in Safari right? There's a reason it's still behind a developer flag. It's not finished.
Construct 3 doesn’t work with WebGPU disabled either. I’m sure it has official support for Mobile Safari, just not official enough to work when someone visits a Construct 3 experience.
I’m not dunking on the engine. It’s just to say, well this is what graphics programming in browser is: making shit work on mobile Safari.
Being spun off to a different company.