Chrome ships WebGPU
developer.chrome.com
developer.chrome.com
WebGPU implementations are still pretty immature, but certainly enough to get started with. I've been implementing a Rust + WebGPU ML runtime for the past few months and have enjoyed writing WGSL.
I recently got a 250M parameter LLM running in the browser without much optimisation and it performs pretty well! (https://twitter.com/fleetwood___/status/1638469392794091520)
That said, matmuls are still pretty handicapped in the browser (especially considering the bounds checking enforced in the browser). From my benchmarking I've struggled to hit 50% of theoretical FLOPS, which is cut down to 30% when the bounds checking comes in. (Benchmarks here: https://github.com/FL33TW00D/wgpu-mm)
I look forward to accessing shader cores as they mentioned in the post.
I sent you an email a few weeks back - would be great to chat!
WONNX is a seriously impressive project. There is a few reason I didn't just contribute back to WONNX:
1. WONNX does not parse the ONNX model into an IR, which I think is essential to have the freedom to transform the model as required.
2. When I started, WONNX didn't seem focused on symbolic dimensions (but I've seen you shipping the shape inference recently!).
3. The code quality has to be much higher when it's open source! I wanted to hack on this without anyone to please but myself.
In my opinion, ONNX is more complex than necessary. Therefore, I opted to convert it to an intermediate representation (IR) first, which is then used to generate source code. A key advantage of this approach is the ease of merging nodes into corresponding operations, since ONNX and Burn don't share the same set of operators.
ONNX is 100% more complex than necessary. Another format of interest is NNEF: https://www.khronos.org/nnef
Questions exist around post-and-pre-processing code in folks' Python stacks, with e.g. NumPy and opencv. There's some NumPy to JS transpilers out there, but those aren't feature complete or fully integrated.
oh cool! will this be numpy-like or will it have autograd as well? We're looking around for a web backend for shumai[1] and the former is really all we need :)
I am one of the contributors for Burn (Rust Deep Learning Framework). We have a plan adding a WebGPU backend (https://github.com/burn-rs/burn/issues/243).
Here is more about the framework Burn: https://burn-rs.github.io/
use burn_tch::TchBackend;
I don't see "TchBackend" mentioned in the docs. Is Tch = torch and Burn can be used as a Torch (or tch-rs) wrapper? Or am I imagining too much from a miscellaneous three letter prefix?
I've been looking for a good way to do standard modern AI stuff in Rust, and was leaning towards tch-rs because it exists and seems reasonably frequently maintained, but if you have some sort of reason to use Burn instead then I'm curious to hear it.
The selling point of burn is that it offers the full level of deep learning framework with ability to swap backends. This is useful, for example, I can train with Torch backend on GPUs but if I want to deploy, lets say to embedded device, I can use NDArray backend, which supports pure rust code (also with various BLAS acceleration if needed). You can also use NDArray backend with Accelerate (iOS or MacOS blass). You can even compile for WASM because Burn supports inference with no_std (you can try this online demo https://burn-rs.github.io/demo).
The framework is well written and follows Rust's conventions and best practices. It's still evolving, however.
Give it a try. If you find problems, you can file a ticket or join discord chat.
> WebGL was getting really old by now. I do wonder whether WebGPU is a bit late too though (e.g. right now Vulkan decides that PSOs maybe are not a great idea lol)
> As in, WebGPU is very much a "modern graphics API design" as it was 8 years ago by now. Better late than never, but... What's "modern" now seems to be moving towards like: bindless everything (like 3rd iteration of what "bindless" means), mesh shaders, raytracing, flexible pipeline state. All of which are not in WebGPU.
I'm not that versed on details, but would interesting to hear what are the advantages of this modern bindless way of doing things.
[1]: https://mastodon.gamedev.place/@aras/110151390138920647
Most of those new and fancy techniques don't work on mobile GPUs, and probably won't for the foreseeable future (Vulkan should actually have been two APIs: one for desktop GPUs, and one for mobile GPUs - and those new extensions are doing exactly that - splitting Vulkan into two more or less separate APIs, one that sucks (for mobile GPUs) and one that's pretty decent (but only works on desktop GPUs).
WebGPU cannot afford such a split. It must work equally well on desktop and mobile from the same code base (with mobile being actually much more important than desktop).
Others seemingly argue that mobile should be ignored entirely, that WebGPU shouldn't work there, or that it should only work on bleeding-edge mobile hardware.
How so?
I always thought the more common use case for GPU acceleration on the web for mobile were 2D games (Candy crush etc). Even on low end devices these are already plenty fast with something like Pixi, no?
My Thinkpad P80 + docking station doesn't own anything to classical desktops.
We see this issue with kids of their generation entering the workforce with a lack of basic computer skills, or CS students in college who have to be explained the concept of a hierarchical file/directory structure.
Most schools around the world don't issue laptops to students.
How is that? And if so how am I typing this on an Intel i5 Chromebook with 16G RAM that is hosting a Linux VM? If upgradeability is the issue, Framework's Chromebook is completely upgradeable.
What APIs are supposed to be separate, why, and what side of the fence is the M1 supposed to land on?
- https://www.yosoygames.com.ar/wp/2023/04/vulkan-why-faq/
- https://www.gfxstrand.net/faith/blog/2022/08/descriptors-are...
In places where Vulkan feels unnecessarily restrictive, the reason is mostly some specific mobile GPU vendor which has some random restrictions baked into their hardware architecture.
AFAIK it's mostly not about tiled renderers but about resource binding and shader compilation (e.g. shader compilation may produce different outputs based on some render states, and the details differ between GPU vendors, or bound resources may have all sorts of restrictions, like alignment, max size or how shader code can access them).
Apple's mobile GPUs are pretty much top of the crop and mostly don't suffer from those restrictions (and any remaining restrictions are part of the Metal programming model anyway, but even on Metal there are quite a few differences between iOS and macOS, which even carried over to ARM Macs - although I don't know if these are just backward compatibility requirements to make code written for Intel Macs also work on ARM Macs).
It's mostly on Android where all the problems lurk though.
This is a real problem but I'm not sure splitting the API is a solution. If a cheap mobile GPU has broken functionality or misreports capabilities, I'm not sure the API can really protect you.
Uh, no ; it power and heat management so battery and fire risk that limits SFF -- It would be good for mobile devices to have external GPU/battery attachments via a universal connector... this will boost efficacy of devices... but you may not always need the boost provided by the umbilical - but when you do need it - just put it outside the machine, and connect it when needed...
In bindless (pointers) you say "at this GPU memory location I have a texture with this params".
In non-bindless you say "API create a texture with these params and give me a handle I will later use to access it".
Bindless gives you more flexibility, but it's also harder to use since it's now your responsability to make sure those pointers point at the right stuff.
Critically however, things like vertex buffers and fragment/vertex shaders are also device state in OpenGL, and bindless textures don't fix that. A fully bindless model would allow you to simply hand the driver a bundle of handles like 'please render vertices from these two vertex buffers, using this shader, and these uniforms+textures' - whether or not you have to allocate texture handles first or can provide the GPU raw texture data is a separate question.
If so, that'd be a non-starter for a web API. Web APIs have to be, first and foremost, secure and protect the user's anonymity.
Linux/Mac also support GPU virtualized memory, but I'm not sure if it's always enabled.
WebGPU 1.0 is a lowest common denominator product. As 'FL33TW00D points out, matrix multiplication performance is much lower than you'd hope from native. However, it is possible to run machine learning workloads, and getting that performance back is merely an engineering challenge. A few extensions are needed, in particular cooperative matrix multiply (also known as tensor cores, WMMA, or simd_matrix). That in turn depends on subgroups, which have some complex portability concerns[1].
Bindless is another thing everybody wants. The wgpu team is working on a native extension[2], which will inform web standardization as well. I am confident this will happen.
The future looks bright. If you are learning GPU, I now highly recommend WebGPU, as it lets you learn modern techniques (including compute), and those skills will transfer to native APIs including Vulkan, Metal, and D3D12.
Disclosure: I work at Google and have been involved in WebGPU development, but on a different team and as one who has been quite critical of aspects of WebGPU.
(*): If you're writing a serious, high quality textbook on compute with WebGPU, then I will collaborate on a chapter on prefix sums / scan.
[1]: https://github.com/gpuweb/gpuweb/issues/3950
[2]: https://docs.rs/wgpu/latest/wgpu/struct.Features.html#associ...*
If you're eager to learn WebGPU, consider checking out Mach[0] which lets you develop with it natively using Zig today very easily. We aim to be a competitor-in-spirit to Unity/Unreal/Godot, but extremely modular. As part of that we have Mach core which just provides Window+Input+WebGPU and some ~19 standalone WebGPU examples[1].
Currently we only support native desktop platforms; but we're working towards browser support. WebGPU is very nice because it lets us target desktop+wasm+mobile for truly-cross-platform games & native applications.
I plan to experiment with that after I get a better understanding of the WebGPU c API.
https://devlog.hexops.com/2021/i-write-code-100-hours-a-week...
What a maniac!
The 2.5 year initial duration (when I posted that article) was like working two full-time jobs, 100h/week, 80% writing code.
Past year has been more like 85h/week, my dayjob has required more time (48h -> ~60h), now with only 30% of that being /writing code/. ~25h/week going to my gamedev passion projects, of which a good chunk has also gone to helping others with their code/issues.
The -15h/week 'loss' has gone to caring for pets, and a gentle touch more travel/sleep/gardening.
But that calendar. That calendar is wild.
> WebGPU is a new API for the web, which exposes modern hardware capabilities and allows rendering and computation operations on a GPU, similar to Direct3D 12, Metal, and Vulkan. Unlike the WebGL family of APIs, WebGPU offers access to more advanced GPU features and provides first-class support for general computations on the GPU.
Or is this yet another information leak anti-feature that we need to disable?
The largest ad company in the world 80% of whose money comes from online advertising does not benefit from tracking...
The reasoning here seems to be something like "Google is evil; X is an evil reason for doing Y; therefore Google must have done Y because of X". It's not a great argument.
"The question is not whether individual sidewalk labs people have pure motives. I know some of them, just like I know plenty on the Chrome team. They’re great people. But focus on the behaviour of the organism as a whole. At the macro level, google/alphabet is very intentional."
[1] Thread: https://twitter.com/johnath/status/1116871231792455686
You are literally following the parody argument schema that I mentioned in my previous comment. You make some vague insinuations that Google is evil, then attribute everything it does to non-specific evil motivations. Even if Google is evil, this kind of reasoning is completely unconvincing.
I should've been more clear. In this case I was responding to this: "The reasoning here seems to be something like "Google is evil; X is an evil reason for doing Y; therefore Google must have done Y because of X". It's not a great argument."
> You are literally following the parody argument schema that I mentioned in my previous comment.
Because you have to look at the behaviour of the organism as a whole. If the shoe fits etc.
What is not acceptable is the use of opaque or hidden techniques that transfer data about individual users and allow them to be tracked in a covert manner, such as fingerprinting. We believe that any attempts to track people or obtain information that could identify them, without their knowledge and permission, should be blocked. We’ll continue to take a strong position against these practices. -- https://blog.google/products/ads-commerce/improving-user-pri...
Google Ads, 2021-03-03:
Today, we’re making explicit that once third-party cookies are phased out, we will not build alternate identifiers to track individuals as they browse across the web, nor will we use them in our products. -- https://blog.google/products/ads-commerce/a-more-privacy-fir...
(I used to work on ads at Google, speaking only for myself)
2. It's funny how you link to a Google propaganda piece on FLoC. Whereas Google's competitors (context: browsers) actually try to reduce fingerprinting, tracking, and thrid-party cookies, Google is trying to have the cake and eat it too with FLoC. Which was such a blatant attempt to keep fingerprinting and tracking alive that everyone immediately disabled it within months of Google's experiments with it.
Edit: Tracking and fingerprinting is Google's bread and butter, literally: 80% of its money comes from targeted advertising.
Your (1) and (2) are about tracking in general and not fingerprinting. On (1), I agree that Google is behind. This is explicitly a strategy to (a) protect ads monetization and (b) avoid a situation where you turn off third party cookies only to have advertisers move to something worse (see: being anti-fingerprinting):
After initial dialogue with the web community, we are confident that with continued iteration and feedback, privacy-preserving and open-standard mechanisms like the Privacy Sandbox can sustain a healthy, ad-supported web in a way that will render third-party cookies obsolete. Once these approaches have addressed the needs of users, publishers, and advertisers, and we have developed the tools to mitigate workarounds, we plan to phase out support for third-party cookies in Chrome. -- https://blog.chromium.org/2020/01/building-more-private-web-...
On (2), while FLoC abandoned the successor, Topics, is still moving forward: https://developer.chrome.com/docs/privacy-sandbox/topics/ Note that unlike FLoC it only observes pages where the page calls "document.browsingTopics()". I don't see how FLoC or Topics represent trying to "have the cake and eat it too" -- they're explicitly attempts to move user interest tracking from the server to the client, to address some of the privacy issues people have with server-side tracking.
On "literally: 80% of its money comes from targeted advertising" that's wrong? The vast majority of Google's income is from ads, yes, but it's mostly from search ads, which aren't targeted.
(I used to work in this area at Google; speaking only for myself)
It's sickening to see how often web pages still profile you, but the setting seems to work.
Similarly, on Android there's a Chromium fork called Bromite that shows JIT, WebRTC, and WebGL as separate permissions, denied by default. I only use it for when broken websites don't work right on Firefox, but websites seem to function fine without all those permissions being enabled by default.
Competent websites will tell you the necessary settings ("WebGL is not available") so making the websites work isn't much trouble. I'd much rather see those error messages than getting a "turn on canvas fingerprinting for a better experience" popup from my browser every time I try to visit blogs or news websites.
Just one example: A script which runs many different types of computations. Each computation will take a certain amount of time depending on your hardware and software. So you will get a fingerprint like this:
computation 1: **
computation 2: ****
computation 3: **********
computation 4: **
computation 5: **************
computation 6: ************
computation 7: *********
etc
You can time any computation. So they all have that side effect.
Also, from Javascript you can execute tons of C++ code (e.g. via DOM manipulation). There's no way all of that native code can be guaranteed to run with consistent timing across platforms.
Computations that call into native APIs can be put in the "has observable side effects" category (but in more fine grained treatment, some could have more specific handling).
function computation() { ... }
before = performance.now();
computation();
t = performance.now() - before;
The horse bolted long ago; there's little sense in trying to prevent future web platform features from enabling fingerprinting, because the existing surface that enables it is way too big to do anything meaningful about it.
Here are a couple of more constructive things to do:
- Campaign to make fingerprinting illegal in as many jurisdictions as possible. This addresses the big "legitimate" companies.
- Use some combination of allow-listing, deny-listing, and "grey-listing" to lock down what untrusted websites can do with your browser. I'm sure I've seen extensions and Pi-hole type products for this. You could even stop your browser from sending anything to untrusted sites except simple GET requests to pages that show up on Google. (I.e. make it harder for them to smuggle information back to the server.)
- Support projects like the Internet Archive that enable viewing large parts of the web without ever making a request to the original server.
I’m sympathetic to the privacy concerns but this isn’t a solution worth considering.
If the data can't be exfiltrated, who cares if they can fingerprint?
Letting JS communicate with servers without the user's explicit consent was the original sin of web dev, that ruined everything. Turned it from a user-controlled experience to one giant spyware service.
Also, WebGPU seems to conceptually support software rendering ("fallback adapter"), where fixed time rendering would seem to be possible even without getting cooperation from HW drivers. Being slower than WebGL might still be an acceptable tradeoff at least if the alternative WebGL API avenue of fingerprinting could be plugged.
I'm not aware of a single fingerprinting tool that primarily use this king of timing attack rather than more traditional fingerprinting methods.
We would have to make examples of what Computation1 is and what Computation2 is to make a prediction if certain types of workloads will impact the ratio of their performance.
Example:
s=performance.now();
r=0;
for (i=0; i<1000000; i++) r+=1;
t1=performance.now()-s;
s=performance.now();
r=0;
for (i=0; i<1000000; i++) r+="bladibla".match(/bla/)[0].length;
t2=performance.now()-s;
console.log("Ratio: " + t2/t1);
Your example is unlikely to get you far.
Edit: in a quick test, I got a range between 8 and 49 in Chrome, and between 1.27 and 51 (!) on Firefox, on the same computer, the results are very noisy.
To distinguish between users between of a larger set, you do more such tests and add them all together. Each test adding a few bits of information.
To make the above code more reliable, you can measure the ratio multiple times:
https://jsfiddle.net/dov1zqtL/
I get 9-10 in Firefox and 3-4 in Chrome very reliably when measuring it 10 times.
But it's also the most pathological example one can think of, yet the results are extremely noisy (while being very costly, which means you won't be able to make a big number of such test without dramatically affecting the user's ability to just browse your website).
In practice, no-one who answers a web permissions dialog truly knows if they have made the correct answer.
Asking the user a question they realistically can't answer correctly is not a solution. It's giving up on the problem.
Maybe "it can be used to display 3D graphics and to track you", but I expect that most people will shrug and go on.
"Fingerprinting" is a better approach to the messaging, but is also going to be confusing since if you take that approach, almost all modern permissions are fingerprinting permissions, so now you have the problem of "okay, this website requires fingerprinting class A but not fingerprinting class B" and we expect an ordinary user to understand that somehow?
Counterpoint: if webpage with latest news (for example) immediately asks me to allow notification, access to webcamera and location I definitely know what is correct answer to these dialogs.
Permission prompts are a HUGE user education issue and also a fatigue issue. Rendering is widely used on websites so if users get the prompt constantly they're going to tune it out.
> Especially because they would still have access to canvas and WebGL.
Those should also be behind a (or the same) permission prompt.
Many APIs should be gated behind being a web application. This itself could be a permission dialog already, with a big warning that this enables tracking and "no reputable web site will ask for it unless it is clear why this permission is needed - in doubt, choose no".
Collect opt-in telemetry. Web sites that claim to be a web application but keep getting denied can then be reclassified as hostile web sites, at which point they not only lose the ability to annoy users with web app permission prompts, but also other privileges that web sites don't need.
Because defining what is a web site and what's an app, strikes me as particularly impractical idea. You correctly point out that yes, there are a number of powerful APIs that should be behind permissions. But there are a number of permissions already, so we need to start bundling them and also figure out how to present all this to the regular user.
Frankly, I wouldn't know where to begin with all this.
Distinguishing between site and app, e.g. via an installation process, is equivalent to a permissions dialog, except that you're now advocating for one giant permission dialog instead of fine-grained ones, which seems like a step backwards.
The new permission dialog wouldn't grant all of the finer-grained permissions - it would be a prerequisite to requesting them in the first place.
Curating known good would equate to some sort of app store. There are probably initiatives to make one for web apps, but it kind of makes me sad to think of applying that to the web, which is supposed to be a free and open commons (although I suppose Google already de facto controls enough of it to be considered a bit of a gatekeeper).
Making the user the arbiter of "known good", ie reliance on permissions dialogs, is not perfect but it's what we have. Yet I fail to see how your proposal of "just add ANOTHER dialog" improves the situation.
Think about it this way: Which is more tedious: going into the settings and enabling and disabling webGPU every time you need it or a popup? Which way would see you keeping it enabled?
Its tyranny of the default with an extra twist :)
But more frankly, fingerprinting is a whack a mole issue and if it were a real security problem, it would slow feature advancements.
And fingerprinting is too unreliable for any real world use.
Just put WebUSB behind permission and the problem is solved.
Just put WebHID behind permission and the problem is solved.
Just put WebMIDI behind permission and the problem is solved.
Just put Filesystem Access behind permission and the problem is solved.
Just put Sensors behind permission and the problem is solved.
Just put Location behind permission and the problem is solved.
Just put Camera behind permission and the problem is solved.
Just put ...
I don't understand why highly paid Google and Firefox developers cannot understand such a simple idea.
Users already expect browsers to change screen contents. That's why WebGPU / WebGL aren't behind a permission block (any moreso than "show images" should be... Hey, remember back in the day when that was a thing?).
The page implies it no longer requires permissions, but I just tested and you definitely get a permissions popup, just a different one.
WebHID, WebUSB and Filesystem Access are IIRC, "considered harmful" so they won't get implemented. And Sensor support was removed after sites started abusing battery APIs.
I'm not. It's a bit of a sarcasm (?) listing a subset of APIs that browsers implement (or push forward against objections like hardware APIs) and that all require some sort of permission.
> but this is exactly the path Firefox was advocating
Originally? Perhaps. Since then Firefox's stance is very much "we can't just pile on more and more permissions for every API because we can't properly explain to the user what the hell is going on, and permission fatigue is a thing"
"Completely co-incidentally", it's in Google's best interest to be able to fingerprint everyone.
So, changing it to actually be privacy friendly while they have the lion's share of the market doesn't seem like it's going to happen without some major external intervention. :/
Are you saying that because you reckon everyone using a Chromium based browser logs into a Google account?
For example, toolbar could look like:
Enable: [ location ] [ camera ] [ fingerprinting via canvas ] ...
HN Guidelines
But then you could also just omit features that have no reason to exist in the first place.
I want this so badly. A compiler flag perhaps, that enables running the same program with the exact output bit for bit on any platform, perhaps by doing the same thing as a reference platform (any will do), even if it has a performance penalty.
I see there's some increase in confidence perhaps, although the result can still be deterministically wrong...
And it can waste a horrendous amount of time if something is non-bit-identical only on a customer machine and not when you try to reproduce it ...
There’s absolutely no guarantee that a computation will be bit-identical even if the hardware primitives are, unless you use exactly the same instructions in exactly the same order. Order of operations matters, therefore valid code optimizations can change your results. Plus you’ll rule out hardware that can produce more accurate results than other hardware if we demand everything be bit-identical always, it will hold us back or even regress. Hardware with FMA units are an example that produce different results than using MUL and ADD instructions, and the FMA is preferred, but hardware without FMA cannot match it. There are more options for similar kinds of hardware improvements in the future.
This is exactly why optimizations that change the order of operations of floating points aren't valid! And many other optimizations, like (I learned this just recently) transforming x + 0.0 into x: those are not the same thing when x is -0.0. In other news, -ffast-math produces broken code.
Current programming languages enable writing 100% deterministic floating point code just fine (even with compiler optimizations, as long as they are not buggy). The trouble is writing cross-platform deterministic floating point code, that works the same in every machine, but with great care it still can be done, as in https://rapier.rs/docs/user_guides/rust/determinism/ (well this project does this for every platform that supports IEEE 754-2008)
You say “aren’t valid” and “broken code” as though it’s somehow factual, when in reality you’re making opinionated assumptions about your choice of tradeoff. Those opinions are only true if you assume that only bit-matched results are “valid”. This hyperbolic wording breaks down a little once we start talking about the accuracy of floating point calculations and how bit-matching FP calculations on two different machines is just making two wrong values agree, and there’s nothing “exact” about it.
It is 100% absolutely fine to have bit-matching determinism as a goal, and I’m in favor of compilers supporting it. I’m not suggesting anyone shouldn’t, but I hope you recognize your language is implicitly demanding that everyone must care about floating point determinism just because you do. Some people have serious floating point calculations where they want cross-platform determinism, but -ffast-math exists precisely because many people do not need it, or because they simply prioritize performance over bit-matching, or because they engineered with epsilons instead of unrealistic expectations. There are good reasons why Rapier’s cross platform determinism is not the default, right?
Generally speaking, even the people who have strong reasons to want bit-matching results on different hardware, because they understand the nature of floating point and the reality of the hardware landscape, do not depend on it to be true, they still write their tests using tolerances.
Asserting == with floating point numbers is basically a kind of rounding anyway.
[1] https://web3dsurvey.com/webgl/extensions/WEBGL_debug_rendere...
At this point there's probably no excuse for continuing to expose that info though, since everyone* just uses ANGLE or intentionally offers a bad experience anyway.
I am sure there will be browsers that will not support this or keep it off so at worst you need to give up on Chrome and use a privacy friendly browser.
Meanwhile there is a large audience who will benefit from WebGPU features e.g. gamers and this audience is in the numbers of hundreds of millions.
You have to block floating point calculations as well if that is your intent.
I'm not sure if lots of hashing algos are gpu-ready or optimized either.
I predict that WebGL/WebGPU will be mainly used for the same purposes. Nobody needs new fancy features, what people really need is more reliable fingerprinting (this is proven by number of uses of WebRTC for fingerprinting vs number of uses for communication).
Maybe that's why it fell to the wayside: scripts are no longer allowed to get the local IP address (taking with it the most useful aspect of WebRTC, true serverless p2p without internet[1]).
[1] I'm not saying that I disagree with the decision, but still sad that we can't have nice things :(
No idea how to solve this though.
So you will get the Android case where flashlight apps where asking for everything, including location data and contact access, and people were giving it to them
some people are just gonna agree to everything, and you can't stop it. don't ruin apps for everybody just because some guy who couldn't care less shared some data with an app you think they shouldn't have.
It's not an either-or thing. There are multiple levels to security, and just shoving everything into one big prompt, and letting users deal with it ain't it.
Would you mind elaborating? In any case WebRTC always needed some kind of third party server to connect the peers together (sure, such a server can be on your local network), and then they replaced the local IP in ICE candidate with mDNS addresses which serve the same purpose and allow for direct P2P communication between the two peers without going through the internet.
Last I knew, the Chrome team was made out of people. If the people working on a new technology are excited about that technology, it probably means that they are excited about that technology. It doesn't say much about how excited the ad people may or may not be about it, other than indirectly by knowing that the technology people are allowed to spend time on it.
That is the link I believe you're referring to, but my guess is that it's going to be fairly tenuous. The set of things that the technology people get to work on probably has more to do with the set of things that they try to persuade the powers that be are important, and that set is more likely to be driven by their own interests and visions of what could and should be done on the web, than it is to be driven by what will make their paymasters happiest.
Sorry, I'm sure there is a much more brief way to say that.
(nb: I work for Mozilla)
It's never too late to delete all this code and pretend it never happened though. I want to see a parallel reality where Flash became an open standard, with open-source plugins and all that. It is an open standard and there is at least one project of an open source Flash player (Ruffle), but it's too late. I still hope Flash makes a comeback though.
> there is at least one project of an open source Flash player (Ruffle)
Just so you know, Ruffle supports (optionally) autoplay without clicking (this has some restrictions, like no sound until it gets a user interaction) _and_ we do plan to try running on webgpu very soon - so unfortunately we rely on this one way or another :(
(also there are other projects, Ruffle just happened to get the best word-of-mouth PR)
> except WebGL, which is abandoned.
So it can be abandoned
I suspect WebGL was different, since it was based on the old OpenGL/DX9 way of doing things, so a clean break was desireable. But I honestly am not that knowledgeable in neither graphics programming nor WebGL history, so take that with several grains of salt.
Google refused to support WebGL compute based on OpenGL ES 3.0 compute shaders, citing WebGPU alternative, and there are still quite a few capabilites from OpenGL ES 3.2 missing from WebGL.
Some of which still not available in WebGPU 1.0.
It's not a nice API, but it is common and vendor neutral all the same. A lot moreso than WebGPU is, even, since Khronos has a much more diverse set of inputs than the web does. See eg all the complaints about Chrome dominating the web discussion, and even beyond that you only really need 3 companies on board. Khronos has significantly more at the table than that.
Instead we have a third graphics standard (after canvas and WebGL) fully incompatible with the previous two that does exactly that: abstracts the OS graphics stack in a new layer
It's not perfect mind you (e.g. baked BindGroups may be a bit too 'rigid'), but it's still a massive improvement over WebGL in terms of reduced CPU overhead.
WebGPU outside of the browser not only suffers the pain of being yet another incompatible shading language, it is also offers the additional possibility of having code incompatible with browsers WebGPU support, due to the use of extensions not available on the browsers.
First of all, if one depends on SPIR being present, then a SPIR to WGSL compiler needs to be present when deploying to the Web part of WebGPU.
Secondly, it will be yet another extension spaghetti that plagues any API that Khronos has some relation to.
Or flipped around, it creates an incentive problem where none of the vendors see much benefit in doing R&D anymore, because browsers aren't content to merely abstract irrelevant differences, they also refuse to support vendor extensions except for their own. No point in adding a cool new feature to the GPU if Chrome/Safari insists on blocking it until your competitors all have it too.
Luckily the GPU industry is driven by video games and nowadays AI, industries that don't write code using the web stack. So they'll be alright. Still, that same incentives problem exists in other areas of computing that sit underneath the browser (CPUs, hardware extensions, operating systems, filesystems, etc). Abstractions don't have to erase all the differences in what they abstract, but people who create them often do so anyway.
However, I think what GPU programming needs at the moment is better ergonomics, and code portability is a step in the right direction, at least. Currently it's quite a bit more annoying than CPU programming.
(But of course like you say this doesn't detract from the native code apps that are content being nonportable, or want to debug, support, bug-workaround, perf-specialcase their app on N operating systems x M GPU hardware archs x Z GPU APIs, x Y historical generations thereof)
Why can't a common graphics API evolve through well researched and heavily scrutinized proposals? The amount of societal loss of efficiency in having competing specs that do the same thing in slightly different ways, but require immense effort to bridge between is truly vast.
The incentive to innovate comes from limitations with the current spec. That doesn't change just because there's consensus on a common base spec
Stifled innovation in what context? I wouldn't describe the web stack as an industry consensus given the rejection of it (for apps) by mobile devs, mobile users, video game devs, VR devs and so on. If you mean within the web stack, then, well, there have been plenty of proposals that died in the crib because they couldn't get consensus for rather obscure reasons that are hard to understand from the outside. Certainly, there were innovations in the earlier days of the web when it was more open that have never been replicated, for example, Flash's timeline based animation designer died and nothing really replaced it.
Fundamentally we can't really know what cool things might have existed in a different world where our tech stack is more open to extensions and forking.
Why can't a common graphics API evolve through well researched and heavily scrutinized proposals?
Why can't everything be done that way? It's been tried and results are a tragedy of the commons. These ideas don't originate in the web world. The incentive to develop the tech isn't actually limits in web specs, that's a decade+ after the innovation happens. What we see is that the web stuff is derivative and downstream from the big players. WebGPU traces its history through Vulkan to Metal/D3D12 and from there to AMD's Mantle, where it all started (afaik). So this stuff really starts as you'd expect, with some risk taking by a GPU designer looking for competitive advantage, then the proprietary OS design teams pick it up and start to abstract the GPU vendors, and then Khronos/Linux/Android realizes that OpenGL is going to become obsolete so they'd better have an answer to it, and then finally the HTML5 people decide the same for WebGL and start work on making a sandboxed version of Vulkan (sorta).
N.B. what made Mantle possible is that Windows is a relatively open and stable environment for driver developers. Ditto for CUDA. They can expose new hardware caps via vendor-specific APIs and Microsoft don't care/encourage it. That means there's value in coming up with a radical new way to accelerate driver performance. In contrast, Apple write their own drivers / APIs, Linux doesn't want proprietary drivers, ChromeOS doesn't even have any notion of an installable vendor driver model at all.
the best way to code cross-platform graphics outside the browser.
Meanwhile on the GPU front you don't have much in the way of large, good middlewares to abstract away the underlying API. OpenGL used to be OK at this, but now neither platforms nor Khronos wants to touch it. Vulkan is "portable" but it's like writing assembly by hand, it's ludicrously complicated. WebGPU fills the role of essentially just being GLES 4.0. It won't be fast, it won't be powerful, but it doesn't actually need to for the long tail of things that just want to leverage a GPU for some small workloads.
Not yet available on Linux, perhaps because the Vulkan backend can't be enabled yet: https://bugs.chromium.org/p/dawn/issues/detail?id=1593
It is modelled after the long defunct webglstats website.
Just think how many JS kBs and CPU cycles would be saved globally if browsers could do data binding and mutate the dom (eg: morhpdom, vdom, etc) natively. And the emissions that come with it.
Edit:
For example, just consider how many billions of users are downloading and executing JS implementations of a VDOM every single day.
Accessing the GPU in this way is something that can't be done without browser-level API support. You're describing a problem already solved in JS. Different category entirely.
Honestly no idea, but any native implementation would be more useful than a userland JS implementation.
> Accessing the GPU in this way is something that can't be done without browser-level API support.
That's true and it will open the door to many use cases. But still, mutating the DOM as efficiently as possible without a userland JS implementation is orders of magnitude more common and relevant to the web as it is today.
Browsers are solving these real-world problems. With modern JS engines, frameworks are nearly as efficient as a native implementation would be.
And with web components, shadow DOM and template literals, all you need is a very thin convenience layer like Lit/lit-html[1] to build clean and modern web applications without VDOM or other legacy technology.
[1]: https://lit.dev
I have a very hard believing that a C++ implementation of eg a VDOM would not be significantly more efficient than a JS one. I'm just doing some benchmarks and even the fastest solutions like Inferno get seriously bottlenecked after trying to mutate about 2000 DOM elements per frame.
And even if the performance was similar, what about the downloaded kBs? How many billions of users download React, Angular, Vue, etc, every single day? Probably multiple times.
This is no longer the case and a tiny web component framework like Lit significantly outperforms[1] React relying entirely on the browser DOM and template literals for re-rendering... so what you're asking for, has already happened :-)
But even the big frameworks are really fast thanks to modern JIT JS engines.
[1]: https://www.thisdot.co/blog/showcase-react-vs-lit-element-re...
I'm not talking about one JS implementation vs another or if JS solutions are fast enough from the end user perspective.
The fastest JS solution (VDOM, Svelte, Lit, whatever) will still be bottlenecked by the browser. If JS could send a single function call to mutate/morph a chunk of the DOM, and that was solved natively, we'd see massive efficiency wins. When you consider the massive scale of the web with billions of users, this surely will have an impact in the emissions of the electricity needed to run all that JS.
And (again) even if there were no perf improvements possible, you're avoiding the JS size argument. Lit still can be improved. Svelte generally produces smaller bundles than Lit. Eg see:
https://krausest.github.io/js-framework-benchmark/current.ht...
But, again, if all the DOM mutation was solved natively there would be huge savings in the amount of JS shipped globally.
This is not without precedent, look up how your brain hemispheres and the regions within are connected.
The folks hustling on crypto are now in the AI space.
https://gpuweb.github.io/gpuweb/#security-abuse-of-capabilit...
I read an unqualified "shipped" as "shipped to stable", but maybe that's just me.
What is the reason we don't have at early-2010s quality AAA game experiences running in the browser?
We still don't have any debugger quality like Renderdoc, Instruments, PIX, and there is nothing with the quality of Infinity Blade, the game Unreal and Apple used to demo iPhone's GL ES 3.0 capabilties.
Streaming like XBox Cloud seems to be the only path for "AAA game experiences running in the browser".
https://wasm.continuation-labs.com/d3demo/
Released in 2004, but still quite impressive
> Performance is decent with around 30-40 FPS on a modern desktop system (ranges from 20 FPS in Edge, 40 FPS in Firefox, to 50 FPS in Chrome)
Achieving 2004 levels of performance & quality with nearly 20 years of hardware improvements is hardly impressive. It's really rather pathetic if anything, although I also got better performance in the opening area than the project page claims but I didn't play very long to find out if it drops later on.
But also note that it's not actually Doom 3 proper, but includes changes from other ports as well as a completely different renderer. There's sadly no side-by-side original vs. port screenshots to compare what the differences are.
You don't want to wait minutes or even hours to download all assets before the game can start (and then again next time because the browser can't cache so much data).
TL;DR: the web platform is different enough from native platforms that ports of bleeding edge games (even from 10 years ago) are not feasible. You'd have to design the entire game around the web platform limitations, which are mainly asset streaming limitations.
But that doesn't happen because there's no working monetisation strategy for 'high profile games' on the web platform, the whole business side is just way too risky (outside some niches which mainly focus on casual F2P games).
The 3D API is only a very small part of the entire problem space (and by far not the most important).
In the end it's mostly about the missing 'business opportunity'. If there would be money in (non-trivial) web games, the games would come.
AAA is by definition games that aim at the top end of what can be done in performance and graphical quality. Browsers prioritize other things. Put another way you can't be both AAA and in the browser, because if you tried, other people would come along and simply do better than you outside and you wouldn't be AAA anymore.
Specifically, browsers insist on very strong levels of sandboxing at the cost of high overhead, and they don't want you to run native code either, so you lose both performance and compatibility with most existing game libraries/engines. They also insist on everything being standardized and run through the design-by-committee meat grinder. Whilst Microsoft are polishing up the latest version of Direct3D browser makers are still trying to standardize the version from five years ago.
Browsers are optimized for lots of tiny files, but game toolchains tend to produce a small number of big files. For example browsers aren't good at resuming interrupted downloads or pinning data into the disk cache.
PC gamers have unified around Steam, which offers various advantages that raw web doesn't. Steam is intended for native apps.
Many games need to be portable to consoles because that's where the revenue is (bigger audience, less piracy). Consoles don't run web apps.
Browsers not only don't make it easy to implement anti-cheat but actively make it as difficult as possible.
Debugging tools for native code in the browser aren't as good as outside.
And so on and so on. That's not a full list, it's just off the top of my head. Other types of apps the web ignores: CLI apps, servers, anything to do with new hardware, OS extensions ... the list goes on. Really, we must ask why we'd ever think it'd make sense to ship AAA games as web pages. If you want the benefits the web brings for without the problems then you'd want a new platform that tries to learn from all of this and be a bit more generalized. I wrote up a design doc a month ago that tries to do that, see what you think:
https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI...
* Deploying large software (i.e. games with all their textures and sounds and models) to the browser is a pain in the ass. Your content will get dumped out of the cache, the user's connection may be spotty, and the browser tab might use up too much RAM and get killed. Console and PC game distribution has an install stage because you need one and that simply is not possible in the web model [1]
* Browsers provide bad latency and stability characteristics. They will drop frames frequently due to garbage collection or activity in other tabs. The amount of multiprocess communication, buffering, etc involved in running a webapp also adds input and rendering latency. This makes games just feel sluggish and janky. If your only option for releasing your game is the web, you'll pick the web, but if players could get a smoother experience on Steam or PlayStation instead, you'd be a fool not to release there. The worst scenario is mobile, where in some cases the input delay on touches is upwards of 100ms.
* Browsers have subpar support for user input, especially on phones. For native games users can pick up an input device of their choice and begin playing immediately (unless it's an ancient PC game that doesn't support hotplug - this is more common on Linux for reasons that aren't obvious to me). In the browser, gamepad input doesn't report until you press a button - moving the analog stick to move a menu cursor isn't good enough - which is a weird and jarring experience. Fullscreen is required for certain types of input as well, which means people who prefer to game in a window on their desktop are out of luck. Apple gets bonus points for just intentionally making all of this stuff worse on iOS to force you into the App Store for that sweet 30% cut.
* AAA game experiences are expensive and more importantly time-consuming to develop. There are studios that started building AAA web game experiences a long time ago, and over the course of years most or all of them flamed out. Game development is hard so these failures aren't exclusively the fault of the web platform, but the web platform certainly didn't help. See https://www.gamedeveloper.com/business/rts-studio-artillery-... for one example - they started out building an AAA web game, then pivoted to native because they couldn't get around all the problems with web games, and then eventually shut down.
* Browsers have limited access to resources. I gestured at this in the first bullet point, but if you run in a browser tab you have less address space, less compute throughput, less VRAM, and less bandwidth at your disposal than you would in a native game. For "AAA" experiences this is a big problem, but for simpler games this is not really an issue. For large scale titles this can be the difference between 30fps and 60fps, or "all the textures are blurry" and "it looks crisp".
[1]: There are some newer APIs that alleviate some of the issues I listed, but not all of them
I think a main technical factor is that the devs and middleware authors interested in the platform have been constantly kept waiting for the next platform features just around the corner, and making big games is a long, 5-10 year process.
But then there's the business side. There's a longish history of web games and there are game genres that don't need 3D acceleration, but there still aren't many (any?) profitable web games.
What scares me is browsers getting bloated with all kinds of features while webapps getting bigger and bigger in size for no reason.
Note, I am all for this feature getting widely adopted.
It might take multiple years for something like WebGPU to start paying off, and even longer for the deprecation of older APIs for 3D rendering, video compression and compute.
- less hassle dealing with installer bloat
- ability to just “close” a webpage instead of having to remove many files in obscure locations if you want to uninstall something
- easier syncing of state across multiple devices with browser session sync
- granular permissions per “app” such as file access, camera access, etc. - lower barrier to enter for developers wanting to ship cross-platform software without having to bundle electron / tauri / whatever
Not to say there aren’t downsides.
- no longer “owning” your software (although debatable if this were ever the case)
- potentially being tied into vendor-specific browser implementations
The good news is that the level of trust in the code to run app natively is very high, and in the age of highly connected computers, if not done in the browser, it would have been needed at OS level anyway.
So maybe browser looks like a sad future as an OS replacement, but at least, it collected issues and solutions to mitigate arbitrary code loaded from the networks.
Whatever happens after, this history will be kept. (it has already started on current OSes with sandboxed software and on demand permissions).
WebGL 2.0 is basically a PS3 / XBox 360 kind of graphics, and WebGPU would be PS4, and that is about it.
All the other cool things, Mesh Shaders, Ray Tracing, Nanite... forget about it, with luck in the next 10 years, if it follows WebGL 2.0 improvements rate.
I could imagine people loading a webpage to take part in a massive open source training exercise by donating their Gpu time.
It wouldn't even be so terrible, if it didn't tie us down to a crappy language (JS).
What really happened was that developers figured out that the deployment story via web was massively simpler and less burdensome. Producing good installers was hard, people in offices often couldn't install anything, and then you had to deal with DLL Hell... whereas the browser was always there already. So a series of unfortunate events was set in motion that ended up with what we have today.
Also I don't hate typescript and there's always wasm.
It's not made to make visualizations that weren't possible before, this explains that.
Not sure if it works anymore (I made it 3 years ago), but will be interesting to see if there will be similar products for LLMs and so now.
Now hoping Safari won’t take another decade to ship proper support…because until then there is only very limited use cases :(
At least with WebGL you had C.
Without SPIR-V support this spec is just another tire on the fire that is the modern web.
But is that language actually bad, or is it just not your favourite language?
What don't you like about it?
C++ is a safer, more expressive superset of C89.
Also those dialects aren't C++, they are based in C++, which isn't the same.
AFAIK: It's a mostly-but-not-100% textual equivalent of SPIR-V that, syntax-wise, is a weird hodgepodge of all the other shader languages. At the same time, it's rare it'll be actually written by hand by humans - it'll mostly be generated from another language at application build time, and then it'll have to be compiled back into bytecode by the browser, which feels like really redundant work.
Further, it's often said that the main reason the language exists in the first place is because Apple veto'd SPIR-V due to their legal disputes with Khronos. I'm assuming that's why the comment above called it "ad-hoc".
Huh? WebGL uses two (incompatible to each other) versions of GLSL, not C.
The topic of the WebGPU shading language has been discussed to death already, with no new insights brought to the discussion for a very long time.
If you have a SPIRV based shader pipeline, you can simply translate SPIRV to WGSL in an offline compilation step (and to get to SPIRV in the first place, you need an offline compilation step anyway).
If you use one of the native WebGPU libraries outside the browser, you can load SPIRV directly.
WebGL's shading language was not C.
http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
WebGPU would most likely have to create its own subset of SPIRV anyway to fulfill the additional safety and validation requirements of the web platform.
Wasn't Apple the originators of the propsal? https://webkit.org/blog/7380/next-generation-3d-graphics-on-... https://webkit.org/wp-content/uploads/webgpu-api-proposal.ht...
Also the original 3D API proposal from Apple was essentially a 1:1 Javascript shim for Metal, which looked quite different from WebGPU.
Apple also originally proposed a custom shading language which looked like - but wasn't quite - HLSL. Compared to that, WGSL is the saner solution (because translation from and to SPIRV is relatively straightforward).
[1] https://tfjs-benchmarks.web.app/local-benchmark/
[2] https://digest.browsertech.com/archive/browsertech-digest-wh...
Of course, that would require there being Quest drivers and software to get any traction...
Otherwise it does nothing for "smooth animations on the web"
Same capabilities as native APIs.
> , and why isn't it coming to fruition, do you think?
Politics and lack of tooling.
Why the negativity?
Consider that after 10 years, there is no Web game that can match AAA releases for Android and iOS written in OpenGL ES 2.0 (already lowering the bar here to WebGL 1.0).
And SpectorJS is the best GPU debugger we ever got.
Meanwhile in 2010,
Competing implementations are a cornerstone of standards. Indeed in many domains it's a requirement for a spec to have multiple compliant implementations to be considered complete at all.
We need an iOS like pace of updating for browsers!
How do you mean? Browsers often update every 6 weeks. IOS releases with new behavior are annual.
And of course this will do nothing to the app store. Much like WebGL did nothing.
Next up for browsers should be NPUs such as Apple's neural engine.
Current is 112, WebGPU is 113.
Seriously google, can't you just wait until you actually ship the stuff before you say you shipped it...
I guess Linux support will come right after they ship Google Drive client.