51 ms·

Chrome ships WebGPU

936 points by itsuka 4y ago

AbuAssar 4y ago
can this be used in fingerprinting?
- NiekvdMaas 4y ago
  Short answer: yes https://gpuweb.github.io/gpuweb/#privacy-considerations https://gpuweb.github.io/gpuweb/#privacy-considerations
- Scarjit 4y ago
  Yes, checkout the "Privacy considerations" part of the spec: https://www.w3.org/TR/webgpu/#privacy-considerations https://www.w3.org/TR/webgpu/#privacy-considerations
- codedokode 4y ago
  This probably will be the main use of the technology.
- switch007 4y ago
  The wouldn’t have merged it if not
teruakohatu 4y ago
In case you confused this with webgl as I did: > 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.
- mike_hock 4y ago
  And to prevent device fingerprinting, all the operations are specified to deterministically produce the same bit-exact results on all hardware, and the feature set is fixed without any support for extensions, right? Or is this yet another information leak anti-feature that we need to disable?
  - Timja 4y ago
    There is no way to escape fingerprinting. 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 There is no way to avoid this. You can make the fingerprint more noisy by doing random waits. But thats all.
    - fulafel 4y ago
      It's possible to have the runtime execute the computations in fixed time across platforms.
      - foldr 4y ago
        Could you explain what techniques would make this possible? I can see how it's possible in principle, if you, say, compile JS down to bytecode and then have the interpreter time the execution of every instruction. I don't immediately see a way to do it that's compatible with any kind of efficient execution model.
        fulafel 4y ago
        The rest would be optimization while keeping the timing sidechannel constraint in mind, hard to say what the performance possibilities are. For example not all computations have externally observable side effects, so those parts could be executed conventionally if the runtime could guarantee it. Or the program-visible clock APIs might be keeping virtual time that makes it seem from timing POV that operations are slower than they are, combined with network API checkpoints that halt execution until virtual time catches up with real time. Etc. Seems like a interesting research area.
        foldr 4y ago
        >not all computations have externally observable side effects 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.
- marktangotango 4y ago
  So someone can put javascript in a page to compute equihash, autolykos, cuckoo cycle, etc? Is there a way to limit this?
  - dagmx 4y ago
    They could already do that though?
    - marktangotango 4y ago
      But not using the client side gpu!
      - JayStavis 4y ago
        I believe webGL "cryptojacking" as it's called, indeed is a thing. Not sure on prevalence though or to what extent this introduction makes it more viable for malicious actors. I'm not sure if lots of hashing algos are gpu-ready or optimized either.
- hinell 4y ago
  Sadly all of this comes at cost of necessaty to lear new webgl and new API whic isn't good. I would expect to have something similar to a Vulkan one. This is not good.
BulgarianIdiot 4y ago
Now I want to see someone figure out a way to performantly distribute a trillion parameter model on a million smartphones looking at a web page.
- sebzim4500 4y ago
  The bandwidth would end up costing way more than the compute would.
  - BulgarianIdiot 4y ago
    Depends how you do it. LLM are huge, but their input and output is miniscule bits of text. If you find a way to put "narrow paths" in the hidden layers, basically to subdivide a model into smaller interconnected models, then the bandwidth will be similarly massively reduced. This is not without precedent, look up how your brain hemispheres and the regions within are connected.
TheAceOfHearts 4y ago
Can this be used to mine cryptocoins by malicious actors?
- echelon 4y ago
  I doubt there's as much effort being put into crypto these days. The folks hustling on crypto are now in the AI space.
  - nwienert 4y ago
    > storyteller.ai
    - echelon 4y ago
      If anything I'd argue my vantage point gives me a better perspective on this.
  - sebzim4500 4y ago
    Crypto prices are still quite high, I don't see why the incentives to steal gpu cycles to mine crypto are any less now than they were during the blockchain summer.
    - kevingadd 4y ago
      The prices don't matter if the quantity of coins you can mine is a tiny fraction, which is the problem
- frankjr 4y ago
  The spec touches on this, but the short answer is "yes". https://gpuweb.github.io/gpuweb/#security-abuse-of-capabilities https://gpuweb.github.io/gpuweb/#security-abuse-of-capabilit...
  - codedokode 4y ago
    If developers were a bit smarter and put this behind a permission then the answer would be no, and WebGPU couldn't be used for fingerprinting as well.
puttycat 4y ago
So, making it easier to directly harvest unsuspecting GPUs for mining?
tormeh 4y ago
This is HUGE news. Webgpu solves the incentives problem where all actors tries to lock you in to their graphics/compute ecosystem by abstracting over them. It's already the best way to code cross-platform graphics outside the browser. This release in Chrome ought to bring lots more developer mindshare to it, which is an awesome thing.
- gostsamo 4y ago
  or it will be yet another standard
  - pl90087 4y ago
    [flagged]
  - tormeh 4y ago
    Not really. I don't see how any of the vendors could break it without being extremely overt about it. And it has no direct competition. Nothing else runs on any OS and any GPU, except WebGL, which is abandoned.
    - illiarian 4y ago
      > I don't see how any of the vendors could break it without being extremely overt about it. > except WebGL, which is abandoned. So it can be abandoned
      - tormeh 4y ago
        It becoming a stale standard is maybe the biggest threat, yes. It has the issue all standards have since several actors have to play along, except this time it isn't Nvidia, Apple, and AMD, but Wgpu/Mozilla and Google. Their incentives are hopefully better aligned with users than those of the hardware vendors. 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.
senttoschool 4y ago
It's good to know that Apple, MS, Firefox, and Google are all onboard. It's great that browsers are finally taking advantage of the underlying hardware. Next up for browsers should be NPUs such as Apple's neural engine.
- pzo 4y ago
  There is already spec in the making: WebNN [1]. Will be interesting to see if Apple will be on board or not. [1] https://webmachinelearning.github.io/webnn-intro/ https://webmachinelearning.github.io/webnn-intro/
hexhowells 4y ago
The MDN docs can also be found here: https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API
erk__ 4y ago
I think Firefox aims to have this in Firefox 113, WebGPU was just enabled by default in nightly last week. https://bugzilla.mozilla.org/show_bug.cgi?id=1746245 https://bugzilla.mozilla.org/show_bug.cgi?id=1746245
- rockdoe 4y ago
  "Firefox's implementation is based on the wgpu Rust crate, which is developed on GitHub and widely used outside Firefox."
  - tormeh 4y ago
    Wgpu is the foundation for the Bevy game engine (on native, web is still WebGL), and is also used by some games and UI frameworks.
- throwaway12245 4y ago
  Any firefox nightly webgpu demos?
  - timokoesters 4y ago
    https://wgpu.rs/examples-gpu/?example=hello-triangle https://wgpu.rs/examples-gpu/?example=hello-triangle
j-pb 4y ago
I lost all hope for WebGPU after they decided to roll their own ad-hoc shader language that kinda looks like, but is totally not rust. 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.
- sirwhinesalot 4y ago
  Ugh... why... (And I say this despite rust being my favorite language ATM)
- hutzlibu 4y ago
  "ad-hoc shader language that kinda looks like, but is totally not rust." But is that language actually bad, or is it just not your favourite language? What don't you like about it?
  - illiarian 4y ago
    No idea what the comment about Rust means, but we already have several shader languages. There was literally no reason to invent another incompatible one
    - xchkr1337 4y ago
      Most current shader languages are very close to C in terms of syntax and behavior and these are some of the worst aspects of C as a language. I guess they could have went with SPIR-V but generally a compilation step shouldn't be required in web standards.
      - pjmlp 4y ago
        MSL, HLSL and PSSL are C++ dialects.
        xchkr1337 4y ago
        Literally all of these are owned by big corporations (Apple, Microsoft, Sony) and made specifically for their proprietary gpu APIs. C++ is just a superset of C which doesn't fix syntax problems. Making an open source standard with a modern syntax is a better idea than picking a favorite corporation.
HeckFeck 4y ago
The browser truly is the new OS, for better or for worse.
- toyg 4y ago
  They couldn't secure our OSes to run untrusted code safely, so they built a OS on top of a OS (yo-dawg meme here). It wouldn't even be so terrible, if it didn't tie us down to a crappy language (JS).
  - mike_hearn 4y ago
    I guess you're being downvoted because of the swipe at JS, but that's pretty much what's happened yes. Desktop OS vendors dropped the ball on sandboxing and internet distribution of software so badly that we ended up evolving a document format to do it instead. The advantage being that because it never claimed to be an app platform features could be added almost arbitrarily slowly to ensure they were locked down really tight, and because of a pre-existing social expectation that documents (magazines, newspapers) contain adverts but apps don't. So ad money can fund sandboxing efforts and if it lags five years behind the unsandboxed versions, well, it's not like Microsoft or Apple are doing the work.
  - pid-1 4y ago
    I think the real reason the web was built was because Google, etc... Decided they need a distribution platform that could not be locked by OS vendors, as that would be a theat to their business.
    - toyg 4y ago
      That's a cynical take. DHTML predates Google. Demand was already there before the giants appeared. 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.
amrb 4y ago
Seriously I'm looking forward to running ML inference on the web!
- fulafel 4y ago
  People have been doing it for long with WebGL, see eg https://github.com/tensorflow/tfjs https://github.com/tensorflow/tfjs and https://cloudblogs.microsoft.com/opensource/2021/09/02/onnx-runtime-web-running-your-machine-learning-model-in-browser/ https://cloudblogs.microsoft.com/opensource/2021/09/02/onnx-...
  - paulgb 4y ago
    It will be interesting to see the performance differential. Tensorflow.js provides a benchmark tool[1]. When I ran them[2] on an M1 MacBook Pro, WebGPU (in Chrome Canary) was usually 2x as fast as WebGL on large models, sometimes 3x. [1] https://tfjs-benchmarks.web.app/local-benchmark/ https://tfjs-benchmarks.web.app/local-benchmark/ [2] https://digest.browsertech.com/archive/browsertech-digest-what-webgpu-means-for-games/ https://digest.browsertech.com/archive/browsertech-digest-wh...
d--b 4y ago
Chrome _will_ ship WebGPU in the next update... 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...
- selectnull 4y ago
  Even worse: "This initial release of WebGPU is available on ChromeOS, macOS, and Windows. Support for other platforms is coming later this year." I guess Linux support will come right after they ship Google Drive client.
  - pjmlp 4y ago
    Not even Google cares about "The Year of Desktop Linux", despite their heavy use of it.
- xbmcuser 4y ago
  They count the beta channel as the release channel so if it is in beta channel it is released from here if no bugs are found would be pushed to stable.
  - rado 4y ago
    Doesn't seem to be in beta, which is still 112.
grishka 4y ago
Can this be disabled when it is released?
- jeroenhd 4y ago
  Firefox has dom.webgpu.enabled for browser control. Chrome has flags for it right now, but those often disappear once a feature is introduced. You can probably disable hardware acceleration to get rid of webgpu though.
Alifatisk 4y ago
Soon, there will be no need to install softwares to the computer. A modern browser will cover it all. 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.
- codewiz 4y ago
  Adding broadly useful features to the web platform is a net gain if it removes bloat from N web apps that most users run. 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.
- EthicalSimilar 4y ago
  For the general population, is this a bad thing? - less friction for users - 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
- tuyiown 4y ago
  The real problem is more that bad and malicious code get more and more easier to deploy, the browser getting more complex to mitigate this. 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).
- 4y ago
codewiz 4y ago
"This initial release of WebGPU is available on ChromeOS, macOS, and Windows." 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 https://bugs.chromium.org/p/dawn/issues/detail?id=1593
- hinell 4y ago
  [dead]
ianpurton 4y ago
Is it practical to run machine learning algorithms in parallel with this? I could imagine people loading a webpage to take part in a massive open source training exercise by donating their Gpu time.
- bhouston 4y ago
  Google’s main tensor flow library for the browser runs fastest with its webgl2 backend as compared to cpu so I suspect running it on webgpu is possible and maybe preferred. That said there is a WebNN api that should eventually expose neural network accelerator chips which should be faster and more efficient than GPU at some point.
- why_only_15 4y ago
  Looks like no -- there appears to be no tensor core or similar support and this SGEMM (fp32 matrix multiply) benchmark gets awful results (my laptop gets 330 gflops on this when it should be capable of 13000 gflops fp32 and probably 100000 gflops fp16). https://github.com/milhidaka/webgpu-blas https://github.com/milhidaka/webgpu-blas
bhouston 4y ago
And just 2 weeks ago I launched this WebGPU features and limits tracking website: https://web3dsurvey.com https://web3dsurvey.com It is modelled after the long defunct webglstats website.
- Kelteseth 4y ago
  Nice! I have linked your site to the Godot WebGPU support proposal issue: https://github.com/godotengine/godot-proposals/issues/6646 https://github.com/godotengine/godot-proposals/issues/6646
- mourner 4y ago
  I've been looking for a replacement to WebGL Stats for a long time — thank you so much for making it! This is indispensable.
pjmlp 4y ago
Get ready to rewrite all your shaders in WGSL.
- KrugerDunnings 4y ago
  With Naga and SPIRV it is possible to "import" routes written in GLSL from WGSL
- bschwindHN 4y ago
  You're in almost every thread about WGPU, with negative opinions about it. What would your ideal graphics API be, and why isn't it coming to fruition, do you think?
  - pjmlp 4y ago
    > What would your ideal graphics API be 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, https://www.youtube.com/watch?v=UQiUP2Hd60Y https://www.youtube.com/watch?v=UQiUP2Hd60Y
  - kevingadd 4y ago
    Not the person you're replying to, but a start would be to use an existing proven shader format like SPIRV or DXIL instead of making up an entirely new shader ecosystem in order to satisfy the whims of a single browser vendor and waste everyone's time.
deleted 4y ago
[deleted]
iamsanteri 4y ago
Wow, this could be huge for enabling more efficient rendering of also more basic animations and effects on the web making it a smooth experience.
- illiarian 4y ago
  If your entire site/app is in WebGPU then yes I guess? Otherwise it does nothing for "smooth animations on the web"
- kevingadd 4y ago
  Not really. If you want smooth and efficient rendering of basic animations/effects, you should be using CSS, because then the browser will natively rasterize, scroll and composite everything in parallel using hardware acceleration. It's far more efficient than rendering basic elements with WebGL and will probably be better than WebGPU in most cases.
- jug 4y ago
  Dear god no, use CSS for that. It's already hardware accelerated in the regular browsers. You're talking of website presentation and that's the purpose of CSS.
0xDEF 4y ago
Chrome and Firefox have supported WebGL since 2011 and WebAssembly since 2017. What is the reason we don't have at early-2010s quality AAA game experiences running in the browser?
- pjmlp 4y ago
  That is always my example why WebGL is only usefull for ecommerce stores, shader toy and little else. 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".
- yread 4y ago
  There is Doom 3 https://wasm.continuation-labs.com/d3demo/ https://wasm.continuation-labs.com/d3demo/ Released in 2004, but still quite impressive
  - kllrnohj 4y ago
    From the project page: > 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.
- flohofwoe 4y ago
  One technical reason is that AAA games would require a complete rethinking of their asset loading strategy, since they'd basically have to use the internet as a very slow and very unreliable hard disc to stream their assets from (which basically means you can't stream the kind of high resolution assets expected of AAA games at all, so you'll have to find a simplified graphics style that looks explicitely 'non-AAA'). 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.
tormeh 4y ago
Anyone know the reason Google created Dawn instead of going with Wgpu? Attachment to C++, or NIH syndrome?
- pjmlp 4y ago
  Dawn was there first?
  - tormeh 4y ago
    Can't fault that logic.
- kllrnohj 4y ago
  What does Mozilla use Spidermonkey instead of V8? Why did Apple create B3 JIT instead of just using Turbofan? 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.
  - tormeh 4y ago
    The older I get the more I disagree with this POV. All other things equal, a single open source implementation is superior to several ones. Several implementations lead to duplication of effort, both for those developing them, and more importantly for those developing for those implementations. Software has to be tested separately for each implementation, often with vendor-specific hacks.
Ciantic 4y ago
This is a comment from Aras Pranckevičius [1]: > 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 https://mastodon.gamedev.place/@aras/110151390138920647
- flohofwoe 4y ago
  Aras is right, but the elephant in the room is still shitty mobile GPUs. 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).
  - miohtama 4y ago
    I think it unrealistic management of expectations that desktop and mobile must or should be equal. There is plenty of web applications use cases one would like to run on a desktop, but they are irrelevant for mobile, for many other reasons as well. E.g. think editing spreadsheets.
    - slimsag 4y ago
      WebGPU says the baseline should be what is supported on both desktop+mobile, and that extensions (in the future) should enable the desktop-only use cases. 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.
Mindwipe 4y ago
I wonder if you could utilise WebVR and this to build a reasonably performant VR application on a Mac. Of course, that would require there being Quest drivers and software to get any traction...
Ellie_Palms 4y ago
[flagged]
ReptileMan 4y ago
If apple put it in safari - this is app store killer
- jckahn 4y ago
  How so? The App Store’s value proposition is discoverability. A web API can’t do much to compete with that.
- illiarian 4y ago
  Apple is literally one of the originators of this API. And of course this will do nothing to the app store. Much like WebGL did nothing.
- kevingadd 4y ago
  Games in iOS safari are still at a big disadvantage even if they have access to WebGPU, because Apple intentionally undermines input and fullscreen APIs there to keep games in the app store.
amrb 4y ago
https://webgpu.github.io/webgpu-samples/samples/gameOfLife https://webgpu.github.io/webgpu-samples/samples/gameOfLife
FL33TW00D 4y ago
This is very exciting! (I had suspected it would slip to 114) 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 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 https://github.com/FL33TW00D/wgpu-mm) I look forward to accessing shader cores as they mentioned in the post.
- tehsauce 4y ago
  It’s better to compare against an ML framework than to maximum theoretical flops because sometimes it’s not possible to reach. These models are often limited by memory bandwidth rather than flop capability.
  - pklausler 4y ago
    Something more than 30 years ago, I had the privilege of working as a young compiler writer for [a supercomputer designer]'s penultimate start-up. I once naively asked him why the machine he was working on couldn't have more memory bandwidth, since the floating-point functional units were sometimes starved for operand data and it was hard to hit the peak Flop/sec figures. And his response has stuck with me ever since; basically, it makes better sense for the memory to be fully utilized, not the floating-point units, because the memory paths were way more expensive than the floating-point units. And this was something you could actually physically see through the transparent top of the system's case. I guess the lesson would be: Don't let a constraint that would be fairly cheap to overdesign be the limiting factor in a system's performance.
- singularity2001 4y ago
  How would WebGL matmul fare in comparison?
codedokode 4y ago
I remember when WebRTC was introduced, it was found that it became very popular and was used by almost every page. But closer inspection showed that its use was to get user's IP address for better fingerprinting. 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).
- 7to2 4y ago
  > But closer inspection showed that its use was to get user's IP address for better fingerprinting. 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 :(
  - codedokode 4y ago
    Yes instead of IP address the API now provides Apple DNS hostname. But a proper solution would be to put this unnecessary API behind a permission.
    - illiarian 4y ago
      There are too many APIs that need to put behind permissions for permissions to be useful. No idea how to solve this though.
      - notatoad 4y ago
        i want the chrome apps model to come back - put your permission requests in a manifest, and when the user clicks and install button the app gets its permissions. so "web apps" that the user cares enough about to install get useful features, but pages that you just visit briefly don't.
slimsag 4y ago
This is very welcome and a long time coming! 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. [0] https://github.com/hexops/mach https://github.com/hexops/mach [1] https://github.com/hexops/mach-examples/tree/main/core https://github.com/hexops/mach-examples/tree/main/core
- bobajeff 4y ago
  I'm actually keeping a close eye on mach after seeing your talk about gkurve. That has made GPU accelerated 2D graphics look much more approachable to me. I plan to experiment with that after I get a better understanding of the WebGPU c API.
- ArtWomb 4y ago
  Zig is the "language I'm learning next" ;)
- johnfn 4y ago
  The Mach project led me to this, uhm, _interesting_ article: https://devlog.hexops.com/2021/i-write-code-100-hours-a-week/ https://devlog.hexops.com/2021/i-write-code-100-hours-a-week... What a maniac!
  - lightbendover 4y ago
    2 years isn’t long enough to really experience burnout. As soon as rewards slow down, it will seep in if nothing else changes.
    - slimsag 4y ago
      Closer to 3.5 years now, maybe I'll do an update at 4 years. 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.
misterdata 4y ago
This makes running larger machine learning models in the browser feasible - see e.g. https://github.com/webonnx/wonnx https://github.com/webonnx/wonnx (I believe Microsoft's ONNXRuntime.js will also soon gain a WebGPU back-end).
Jhsto 4y ago
For anyone figuring out how to run webgpu on a remote computer (over webrtc) , see this: https://github.com/periferia-labs/laskin.live https://github.com/periferia-labs/laskin.live 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.
vrglvrglvrgl 4y ago
[dead]
2OEH8eoCRo0 4y ago
I'm very curious about isolation. Nvidia doesn't allow virtual GPUs on their consumer card drivers so this isolation feels like it can easily be abused. Will there be more support for vGPUs in the future? I hope Nvidia and others are pushed to include better isolation and vGPU support so that WebGPU doesn't need to do all this security isolation themselves. Your browser could theoretically request a vGPU instance to work on.
- kevingadd 4y ago
  In general it would be great if browser GPU processes could operate on a vGPU, so the web as a whole would be isolated from the rest of your system. Right now that's not the case, so you're relying on drivers for that browser vs apps isolation, and relying on the browser to isolate tabs from each other as well. Both have failed in the past.
blurbleblurble 4y ago
Still waiting on Linux support! I'd love to start working with this but gave up after a dozen+ tries to get it consistently running on Linux.
infrawhispers 4y ago
this is really nice. I may need to change the onnx backends in my demo here[1] from wasm to webgpu. [1] https://anansi.pages.dev/ https://anansi.pages.dev/
pier25 4y ago
Don't get me wrong, this is supremely cool... but I wish the W3C and browsers solved more real world problems. 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.
- shadowgovt 4y ago
  What would that mean? And what version of "mutate the DOM via databinding" would win, because there are at least three different approaches used in various JS libraries? 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.
  - pier25 4y ago
    > What would that mean? 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.
- lima 4y ago
  > 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. 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 https://lit.dev
  - 4y ago
osigurdson 4y ago
Suppose you have a massive 3D model stored in the cloud, which weighs in at 100GB and requires most of the computation to be handled on the server side. In this scenario, would utilizing something like WebGPU be beneficial, given its primary responsibility for the final 2D projection?
- debacle 4y ago
  You'd probably implement something that does culling server-side, and then pass the culled model to the client.
  - osigurdson 4y ago
    Would that work with vtk?
- mschuetz 4y ago
  You'd use level of detail structures, like google earth does.
topaz0 4y ago
I'd rather not have websites soak up my compute resources, thanks. They are already doing that many times too much for my taste.
- mschuetz 4y ago
  You're free to disable features you don't like. For others, this is good news.
  - topaz0 4y ago
    Incredible insight, but I fear it won't work out well: when the option is there and ubiquitous, websites will rely on it, so disabling features is basically choosing to save some of my resources in exchange for a broken web experience.
    - mschuetz 4y ago
      Since I'm doing 3D graphics in Web Browsers, I consider not having 3D graphics APIs in Web Browsers a broken web experience. The browser is the easiest and safest way to distribute applications with virtually no entry barrier to users. I don't trust downloading just any binary and therefore I won't execute them unless they are from a trusted source. But with 3D in browsers, I can trust any web site not do damage my system and try a large amount of experiences that others create and upload.
      - topaz0 4y ago
        There are applications where the point is 3d graphics. I don't object to letting them use my gpu if they ask nicely. There are other applications -- really the vast majority of them -- where 3d graphics is completely beside the point, and has nothing to do with the reason I'm on your website. That is my concern: that that second class, being the vast majority, will say, "hey, I have access to all this compute power, why don't I just throw some of it at this needless animation that I think looks cool, or at this neural network, or at this cryptominer". Past experience suggests that this is a reasonable concern.
victor96 4y ago
This is super exciting for us as we develop interactive browser UIs. I hope future versions of WebGPU will be backwards compatible to all those with Chrome 113. We need an iOS like pace of updating for browsers!
- paulryanrogers 4y ago
  > 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.
  - victor96 4y ago
    The difficulty is the number of people still running old versions, as soon as new iOS versions come out a super high percentage of people switch. And with browsers you have to account for the update cycles of every browser on the market.
raphlinus 4y ago
This is a huge milestone. It's also part of a much larger journey. In my work on developing Vello, an advanced 2D renderer, I have come to believe WebGPU is a game changer. We're going to have reasonably modern infrastructure that runs everywhere: web, Windows, mac, Linux, ChromeOS, iOS, and Android. You're going to see textbooks(*), tutorials, benchmark suites, tons of sample code and projects to learn from. 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 https://github.com/gpuweb/gpuweb/issues/3950 [2]: https://docs.rs/wgpu/latest/wgpu/struct.Features.html#associatedconstant.TEXTURE_BINDING_ARRAY https://docs.rs/wgpu/latest/wgpu/struct.Features.html#associ...*
- eachro 4y ago
  Suppose you're a ML practictioner. Would you still recommend learning WebGPU, over say spending more time on CUDA?
  - raphlinus 4y ago
    This depends entirely on your goals. If you're researching the actual machine learning algorithms, then use a framework like TensorFlow or Torch, which provides all the tensor operations and abstracts away the hardware. If you're trying to get maximum performance on hardware today, stick with Nvidia and use CUDA. If you're interested in deploying across a range of hardware, or want to get your hands dirty with the actual implementation of algorithms (such as wonnx), then WebGPU is the way to go.
neoyagami 4y ago
I hope this is disable by default, the amount of fingerprinting it will generate kinda scares me.
notorandit 4y ago
For Linux too?
notorandit 4y ago
For Linux too? Not now!
waynecochran 4y ago
Is the camera capture support on mobile devices (perhaps loads video frames into texture map)? I assume this is what webxr is doing somehow?
switch007 4y ago
How does this help web fingerprinting / Google’s revenue?
markdog12 4y ago
Note that this has not shipped to stable, it's currently in beta. I read an unqualified "shipped" as "shipped to stable", but maybe that's just me.
yagiznizipli 4y ago
I think it’s time to support WebGPU on Node.js too. Happy that it is finally on a stable version of Chromium.
rock_hard 4y ago
This is an exciting day! I have been dreaming about WebGPU to ship in Chrome/Edge for as long as I can remember. Now hoping Safari won’t take another decade to ship proper support…because until then there is only very limited use cases :(
bitL 4y ago
Is there a PyTorch port running on WebGPU somewhere? So that I could add local processing for ML pipelines into a webapp, bypassing cloud.
waldrews 4y ago
How much easier does this make it for every ad and background animation to heat up my device and eat up battery time?
phendrenad2 4y ago
Maybe I'm dumb but what does WebGPU get you in reality that WebGL doesn't currently get you? I don't think we're going to see browser games any time soon (because it's trivial to just install a game and run it, and also the browser audio API sucks). And most visualizations on the web would be perfectly fine with plain old WebGL.
- simlevesque 4y ago
  > And most visualizations on the web would be perfectly fine with plain old WebGL. It's not made to make visualizations that weren't possible before, this explains that.
- mattdesl 4y ago
  Basically, an improved API that targets a more modern graphics pipeline and has better support outside of browsers. You can write a graphics engine or custom renderer in Rust and have it ship across desktop and web. See Vello for example: https://github.com/linebender/vello https://github.com/linebender/vello
bart3r 4y ago
Does model-viewer support WebGPU?
bart3r 4y ago
Does model-viewer support WebGPU ?
Alifatisk 4y ago
How will this compare to Gpu.js? https://gpu.rocks/ https://gpu.rocks/
hinell 4y ago
LINUX IS NOT SUPPORTED, WHAT A DISGRACE

Chrome ships WebGPU

936 points by itsuka 4y ago

AbuAssar 4y ago

can this be used in fingerprinting?

NiekvdMaas 4y ago
Short answer: yes https://gpuweb.github.io/gpuweb/#privacy-considerations https://gpuweb.github.io/gpuweb/#privacy-considerations
Scarjit 4y ago
Yes, checkout the "Privacy considerations" part of the spec: https://www.w3.org/TR/webgpu/#privacy-considerations https://www.w3.org/TR/webgpu/#privacy-considerations
codedokode 4y ago
This probably will be the main use of the technology.
switch007 4y ago
The wouldn’t have merged it if not

teruakohatu 4y ago

In case you confused this with webgl as I did: > 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.

mike_hock 4y ago
And to prevent device fingerprinting, all the operations are specified to deterministically produce the same bit-exact results on all hardware, and the feature set is fixed without any support for extensions, right? Or is this yet another information leak anti-feature that we need to disable?
- Timja 4y ago
  There is no way to escape fingerprinting. 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 There is no way to avoid this. You can make the fingerprint more noisy by doing random waits. But thats all.
  - fulafel 4y ago
    It's possible to have the runtime execute the computations in fixed time across platforms.
    - foldr 4y ago
      Could you explain what techniques would make this possible? I can see how it's possible in principle, if you, say, compile JS down to bytecode and then have the interpreter time the execution of every instruction. I don't immediately see a way to do it that's compatible with any kind of efficient execution model.
      - fulafel 4y ago
        The rest would be optimization while keeping the timing sidechannel constraint in mind, hard to say what the performance possibilities are. For example not all computations have externally observable side effects, so those parts could be executed conventionally if the runtime could guarantee it. Or the program-visible clock APIs might be keeping virtual time that makes it seem from timing POV that operations are slower than they are, combined with network API checkpoints that halt execution until virtual time catches up with real time. Etc. Seems like a interesting research area.
        foldr 4y ago
        >not all computations have externally observable side effects 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.
marktangotango 4y ago
So someone can put javascript in a page to compute equihash, autolykos, cuckoo cycle, etc? Is there a way to limit this?
- dagmx 4y ago
  They could already do that though?
  - marktangotango 4y ago
    But not using the client side gpu!
    - JayStavis 4y ago
      I believe webGL "cryptojacking" as it's called, indeed is a thing. Not sure on prevalence though or to what extent this introduction makes it more viable for malicious actors. I'm not sure if lots of hashing algos are gpu-ready or optimized either.
hinell 4y ago
Sadly all of this comes at cost of necessaty to lear new webgl and new API whic isn't good. I would expect to have something similar to a Vulkan one. This is not good.

BulgarianIdiot 4y ago

Now I want to see someone figure out a way to performantly distribute a trillion parameter model on a million smartphones looking at a web page.

sebzim4500 4y ago
The bandwidth would end up costing way more than the compute would.
- BulgarianIdiot 4y ago
  Depends how you do it. LLM are huge, but their input and output is miniscule bits of text. If you find a way to put "narrow paths" in the hidden layers, basically to subdivide a model into smaller interconnected models, then the bandwidth will be similarly massively reduced. This is not without precedent, look up how your brain hemispheres and the regions within are connected.

TheAceOfHearts 4y ago

Can this be used to mine cryptocoins by malicious actors?

echelon 4y ago
I doubt there's as much effort being put into crypto these days. The folks hustling on crypto are now in the AI space.
- nwienert 4y ago
  > storyteller.ai
  - echelon 4y ago
    If anything I'd argue my vantage point gives me a better perspective on this.
- sebzim4500 4y ago
  Crypto prices are still quite high, I don't see why the incentives to steal gpu cycles to mine crypto are any less now than they were during the blockchain summer.
  - kevingadd 4y ago
    The prices don't matter if the quantity of coins you can mine is a tiny fraction, which is the problem
frankjr 4y ago
The spec touches on this, but the short answer is "yes". https://gpuweb.github.io/gpuweb/#security-abuse-of-capabilities https://gpuweb.github.io/gpuweb/#security-abuse-of-capabilit...
- codedokode 4y ago
  If developers were a bit smarter and put this behind a permission then the answer would be no, and WebGPU couldn't be used for fingerprinting as well.

puttycat 4y ago

So, making it easier to directly harvest unsuspecting GPUs for mining?

tormeh 4y ago

This is HUGE news. Webgpu solves the incentives problem where all actors tries to lock you in to their graphics/compute ecosystem by abstracting over them. It's already the best way to code cross-platform graphics outside the browser. This release in Chrome ought to bring lots more developer mindshare to it, which is an awesome thing.

gostsamo 4y ago
or it will be yet another standard
- pl90087 4y ago
  [flagged]
- tormeh 4y ago
  Not really. I don't see how any of the vendors could break it without being extremely overt about it. And it has no direct competition. Nothing else runs on any OS and any GPU, except WebGL, which is abandoned.
  - illiarian 4y ago
    > I don't see how any of the vendors could break it without being extremely overt about it. > except WebGL, which is abandoned. So it can be abandoned
    - tormeh 4y ago
      It becoming a stale standard is maybe the biggest threat, yes. It has the issue all standards have since several actors have to play along, except this time it isn't Nvidia, Apple, and AMD, but Wgpu/Mozilla and Google. Their incentives are hopefully better aligned with users than those of the hardware vendors. 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.

senttoschool 4y ago

It's good to know that Apple, MS, Firefox, and Google are all onboard. It's great that browsers are finally taking advantage of the underlying hardware. Next up for browsers should be NPUs such as Apple's neural engine.

pzo 4y ago
There is already spec in the making: WebNN [1]. Will be interesting to see if Apple will be on board or not. [1] https://webmachinelearning.github.io/webnn-intro/ https://webmachinelearning.github.io/webnn-intro/

hexhowells 4y ago

The MDN docs can also be found here: https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API

erk__ 4y ago

I think Firefox aims to have this in Firefox 113, WebGPU was just enabled by default in nightly last week. https://bugzilla.mozilla.org/show_bug.cgi?id=1746245 https://bugzilla.mozilla.org/show_bug.cgi?id=1746245

rockdoe 4y ago
"Firefox's implementation is based on the wgpu Rust crate, which is developed on GitHub and widely used outside Firefox."
- tormeh 4y ago
  Wgpu is the foundation for the Bevy game engine (on native, web is still WebGL), and is also used by some games and UI frameworks.
throwaway12245 4y ago
Any firefox nightly webgpu demos?
- timokoesters 4y ago
  https://wgpu.rs/examples-gpu/?example=hello-triangle https://wgpu.rs/examples-gpu/?example=hello-triangle

j-pb 4y ago

I lost all hope for WebGPU after they decided to roll their own ad-hoc shader language that kinda looks like, but is totally not rust. 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.

sirwhinesalot 4y ago
Ugh... why... (And I say this despite rust being my favorite language ATM)
hutzlibu 4y ago
"ad-hoc shader language that kinda looks like, but is totally not rust." But is that language actually bad, or is it just not your favourite language? What don't you like about it?
- illiarian 4y ago
  No idea what the comment about Rust means, but we already have several shader languages. There was literally no reason to invent another incompatible one
  - xchkr1337 4y ago
    Most current shader languages are very close to C in terms of syntax and behavior and these are some of the worst aspects of C as a language. I guess they could have went with SPIR-V but generally a compilation step shouldn't be required in web standards.
    - pjmlp 4y ago
      MSL, HLSL and PSSL are C++ dialects.
      - xchkr1337 4y ago
        Literally all of these are owned by big corporations (Apple, Microsoft, Sony) and made specifically for their proprietary gpu APIs. C++ is just a superset of C which doesn't fix syntax problems. Making an open source standard with a modern syntax is a better idea than picking a favorite corporation.

HeckFeck 4y ago

The browser truly is the new OS, for better or for worse.

toyg 4y ago
They couldn't secure our OSes to run untrusted code safely, so they built a OS on top of a OS (yo-dawg meme here). It wouldn't even be so terrible, if it didn't tie us down to a crappy language (JS).
- mike_hearn 4y ago
  I guess you're being downvoted because of the swipe at JS, but that's pretty much what's happened yes. Desktop OS vendors dropped the ball on sandboxing and internet distribution of software so badly that we ended up evolving a document format to do it instead. The advantage being that because it never claimed to be an app platform features could be added almost arbitrarily slowly to ensure they were locked down really tight, and because of a pre-existing social expectation that documents (magazines, newspapers) contain adverts but apps don't. So ad money can fund sandboxing efforts and if it lags five years behind the unsandboxed versions, well, it's not like Microsoft or Apple are doing the work.
- pid-1 4y ago
  I think the real reason the web was built was because Google, etc... Decided they need a distribution platform that could not be locked by OS vendors, as that would be a theat to their business.
  - toyg 4y ago
    That's a cynical take. DHTML predates Google. Demand was already there before the giants appeared. 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.

amrb 4y ago

Seriously I'm looking forward to running ML inference on the web!

fulafel 4y ago
People have been doing it for long with WebGL, see eg https://github.com/tensorflow/tfjs https://github.com/tensorflow/tfjs and https://cloudblogs.microsoft.com/opensource/2021/09/02/onnx-runtime-web-running-your-machine-learning-model-in-browser/ https://cloudblogs.microsoft.com/opensource/2021/09/02/onnx-...
- paulgb 4y ago
  It will be interesting to see the performance differential. Tensorflow.js provides a benchmark tool[1]. When I ran them[2] on an M1 MacBook Pro, WebGPU (in Chrome Canary) was usually 2x as fast as WebGL on large models, sometimes 3x. [1] https://tfjs-benchmarks.web.app/local-benchmark/ https://tfjs-benchmarks.web.app/local-benchmark/ [2] https://digest.browsertech.com/archive/browsertech-digest-what-webgpu-means-for-games/ https://digest.browsertech.com/archive/browsertech-digest-wh...

d--b 4y ago

Chrome _will_ ship WebGPU in the next update... 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...

selectnull 4y ago
Even worse: "This initial release of WebGPU is available on ChromeOS, macOS, and Windows. Support for other platforms is coming later this year." I guess Linux support will come right after they ship Google Drive client.
- pjmlp 4y ago
  Not even Google cares about "The Year of Desktop Linux", despite their heavy use of it.
xbmcuser 4y ago
They count the beta channel as the release channel so if it is in beta channel it is released from here if no bugs are found would be pushed to stable.
- rado 4y ago
  Doesn't seem to be in beta, which is still 112.

grishka 4y ago

Can this be disabled when it is released?

jeroenhd 4y ago
Firefox has dom.webgpu.enabled for browser control. Chrome has flags for it right now, but those often disappear once a feature is introduced. You can probably disable hardware acceleration to get rid of webgpu though.

Alifatisk 4y ago

Soon, there will be no need to install softwares to the computer. A modern browser will cover it all. 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.

codewiz 4y ago
Adding broadly useful features to the web platform is a net gain if it removes bloat from N web apps that most users run. 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.
EthicalSimilar 4y ago
For the general population, is this a bad thing? - less friction for users - 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
tuyiown 4y ago
The real problem is more that bad and malicious code get more and more easier to deploy, the browser getting more complex to mitigate this. 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).
4y ago

codewiz 4y ago

"This initial release of WebGPU is available on ChromeOS, macOS, and Windows." 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 https://bugs.chromium.org/p/dawn/issues/detail?id=1593

hinell 4y ago
[dead]

ianpurton 4y ago

Is it practical to run machine learning algorithms in parallel with this? I could imagine people loading a webpage to take part in a massive open source training exercise by donating their Gpu time.

bhouston 4y ago
Google’s main tensor flow library for the browser runs fastest with its webgl2 backend as compared to cpu so I suspect running it on webgpu is possible and maybe preferred. That said there is a WebNN api that should eventually expose neural network accelerator chips which should be faster and more efficient than GPU at some point.
why_only_15 4y ago
Looks like no -- there appears to be no tensor core or similar support and this SGEMM (fp32 matrix multiply) benchmark gets awful results (my laptop gets 330 gflops on this when it should be capable of 13000 gflops fp32 and probably 100000 gflops fp16). https://github.com/milhidaka/webgpu-blas https://github.com/milhidaka/webgpu-blas

bhouston 4y ago

And just 2 weeks ago I launched this WebGPU features and limits tracking website: https://web3dsurvey.com https://web3dsurvey.com It is modelled after the long defunct webglstats website.

Kelteseth 4y ago
Nice! I have linked your site to the Godot WebGPU support proposal issue: https://github.com/godotengine/godot-proposals/issues/6646 https://github.com/godotengine/godot-proposals/issues/6646
mourner 4y ago
I've been looking for a replacement to WebGL Stats for a long time — thank you so much for making it! This is indispensable.

pjmlp 4y ago

Get ready to rewrite all your shaders in WGSL.

KrugerDunnings 4y ago
With Naga and SPIRV it is possible to "import" routes written in GLSL from WGSL
bschwindHN 4y ago
You're in almost every thread about WGPU, with negative opinions about it. What would your ideal graphics API be, and why isn't it coming to fruition, do you think?
- pjmlp 4y ago
  > What would your ideal graphics API be 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, https://www.youtube.com/watch?v=UQiUP2Hd60Y https://www.youtube.com/watch?v=UQiUP2Hd60Y
- kevingadd 4y ago
  Not the person you're replying to, but a start would be to use an existing proven shader format like SPIRV or DXIL instead of making up an entirely new shader ecosystem in order to satisfy the whims of a single browser vendor and waste everyone's time.

deleted 4y ago

[deleted]

iamsanteri 4y ago

Wow, this could be huge for enabling more efficient rendering of also more basic animations and effects on the web making it a smooth experience.

illiarian 4y ago
If your entire site/app is in WebGPU then yes I guess? Otherwise it does nothing for "smooth animations on the web"
kevingadd 4y ago
Not really. If you want smooth and efficient rendering of basic animations/effects, you should be using CSS, because then the browser will natively rasterize, scroll and composite everything in parallel using hardware acceleration. It's far more efficient than rendering basic elements with WebGL and will probably be better than WebGPU in most cases.
jug 4y ago
Dear god no, use CSS for that. It's already hardware accelerated in the regular browsers. You're talking of website presentation and that's the purpose of CSS.

0xDEF 4y ago

Chrome and Firefox have supported WebGL since 2011 and WebAssembly since 2017. What is the reason we don't have at early-2010s quality AAA game experiences running in the browser?

pjmlp 4y ago
That is always my example why WebGL is only usefull for ecommerce stores, shader toy and little else. 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".
yread 4y ago
There is Doom 3 https://wasm.continuation-labs.com/d3demo/ https://wasm.continuation-labs.com/d3demo/ Released in 2004, but still quite impressive
- kllrnohj 4y ago
  From the project page: > 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.
flohofwoe 4y ago
One technical reason is that AAA games would require a complete rethinking of their asset loading strategy, since they'd basically have to use the internet as a very slow and very unreliable hard disc to stream their assets from (which basically means you can't stream the kind of high resolution assets expected of AAA games at all, so you'll have to find a simplified graphics style that looks explicitely 'non-AAA'). 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.

tormeh 4y ago

Anyone know the reason Google created Dawn instead of going with Wgpu? Attachment to C++, or NIH syndrome?

pjmlp 4y ago
Dawn was there first?
- tormeh 4y ago
  Can't fault that logic.
kllrnohj 4y ago
What does Mozilla use Spidermonkey instead of V8? Why did Apple create B3 JIT instead of just using Turbofan? 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.
- tormeh 4y ago
  The older I get the more I disagree with this POV. All other things equal, a single open source implementation is superior to several ones. Several implementations lead to duplication of effort, both for those developing them, and more importantly for those developing for those implementations. Software has to be tested separately for each implementation, often with vendor-specific hacks.

Ciantic 4y ago

This is a comment from Aras Pranckevičius [1]: > 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 https://mastodon.gamedev.place/@aras/110151390138920647

flohofwoe 4y ago
Aras is right, but the elephant in the room is still shitty mobile GPUs. 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).
- miohtama 4y ago
  I think it unrealistic management of expectations that desktop and mobile must or should be equal. There is plenty of web applications use cases one would like to run on a desktop, but they are irrelevant for mobile, for many other reasons as well. E.g. think editing spreadsheets.
  - slimsag 4y ago
    WebGPU says the baseline should be what is supported on both desktop+mobile, and that extensions (in the future) should enable the desktop-only use cases. 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.

Mindwipe 4y ago

I wonder if you could utilise WebVR and this to build a reasonably performant VR application on a Mac. Of course, that would require there being Quest drivers and software to get any traction...

Ellie_Palms 4y ago

[flagged]

ReptileMan 4y ago

If apple put it in safari - this is app store killer

jckahn 4y ago
How so? The App Store’s value proposition is discoverability. A web API can’t do much to compete with that.
illiarian 4y ago
Apple is literally one of the originators of this API. And of course this will do nothing to the app store. Much like WebGL did nothing.
kevingadd 4y ago
Games in iOS safari are still at a big disadvantage even if they have access to WebGPU, because Apple intentionally undermines input and fullscreen APIs there to keep games in the app store.

amrb 4y ago

https://webgpu.github.io/webgpu-samples/samples/gameOfLife https://webgpu.github.io/webgpu-samples/samples/gameOfLife

FL33TW00D 4y ago

This is very exciting! (I had suspected it would slip to 114) 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 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 https://github.com/FL33TW00D/wgpu-mm) I look forward to accessing shader cores as they mentioned in the post.

tehsauce 4y ago
It’s better to compare against an ML framework than to maximum theoretical flops because sometimes it’s not possible to reach. These models are often limited by memory bandwidth rather than flop capability.
- pklausler 4y ago
  Something more than 30 years ago, I had the privilege of working as a young compiler writer for [a supercomputer designer]'s penultimate start-up. I once naively asked him why the machine he was working on couldn't have more memory bandwidth, since the floating-point functional units were sometimes starved for operand data and it was hard to hit the peak Flop/sec figures. And his response has stuck with me ever since; basically, it makes better sense for the memory to be fully utilized, not the floating-point units, because the memory paths were way more expensive than the floating-point units. And this was something you could actually physically see through the transparent top of the system's case. I guess the lesson would be: Don't let a constraint that would be fairly cheap to overdesign be the limiting factor in a system's performance.
singularity2001 4y ago
How would WebGL matmul fare in comparison?

codedokode 4y ago

I remember when WebRTC was introduced, it was found that it became very popular and was used by almost every page. But closer inspection showed that its use was to get user's IP address for better fingerprinting. 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).

7to2 4y ago
> But closer inspection showed that its use was to get user's IP address for better fingerprinting. 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 :(
- codedokode 4y ago
  Yes instead of IP address the API now provides Apple DNS hostname. But a proper solution would be to put this unnecessary API behind a permission.
  - illiarian 4y ago
    There are too many APIs that need to put behind permissions for permissions to be useful. No idea how to solve this though.
    - notatoad 4y ago
      i want the chrome apps model to come back - put your permission requests in a manifest, and when the user clicks and install button the app gets its permissions. so "web apps" that the user cares enough about to install get useful features, but pages that you just visit briefly don't.

slimsag 4y ago

This is very welcome and a long time coming! 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. [0] https://github.com/hexops/mach https://github.com/hexops/mach [1] https://github.com/hexops/mach-examples/tree/main/core https://github.com/hexops/mach-examples/tree/main/core

bobajeff 4y ago
I'm actually keeping a close eye on mach after seeing your talk about gkurve. That has made GPU accelerated 2D graphics look much more approachable to me. I plan to experiment with that after I get a better understanding of the WebGPU c API.
ArtWomb 4y ago
Zig is the "language I'm learning next" ;)
johnfn 4y ago
The Mach project led me to this, uhm, _interesting_ article: https://devlog.hexops.com/2021/i-write-code-100-hours-a-week/ https://devlog.hexops.com/2021/i-write-code-100-hours-a-week... What a maniac!
- lightbendover 4y ago
  2 years isn’t long enough to really experience burnout. As soon as rewards slow down, it will seep in if nothing else changes.
  - slimsag 4y ago
    Closer to 3.5 years now, maybe I'll do an update at 4 years. 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.

misterdata 4y ago

This makes running larger machine learning models in the browser feasible - see e.g. https://github.com/webonnx/wonnx https://github.com/webonnx/wonnx (I believe Microsoft's ONNXRuntime.js will also soon gain a WebGPU back-end).

Jhsto 4y ago

For anyone figuring out how to run webgpu on a remote computer (over webrtc) , see this: https://github.com/periferia-labs/laskin.live https://github.com/periferia-labs/laskin.live 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.

vrglvrglvrgl 4y ago

[dead]

2OEH8eoCRo0 4y ago

I'm very curious about isolation. Nvidia doesn't allow virtual GPUs on their consumer card drivers so this isolation feels like it can easily be abused. Will there be more support for vGPUs in the future? I hope Nvidia and others are pushed to include better isolation and vGPU support so that WebGPU doesn't need to do all this security isolation themselves. Your browser could theoretically request a vGPU instance to work on.

kevingadd 4y ago
In general it would be great if browser GPU processes could operate on a vGPU, so the web as a whole would be isolated from the rest of your system. Right now that's not the case, so you're relying on drivers for that browser vs apps isolation, and relying on the browser to isolate tabs from each other as well. Both have failed in the past.

blurbleblurble 4y ago

Still waiting on Linux support! I'd love to start working with this but gave up after a dozen+ tries to get it consistently running on Linux.

infrawhispers 4y ago

this is really nice. I may need to change the onnx backends in my demo here[1] from wasm to webgpu. [1] https://anansi.pages.dev/ https://anansi.pages.dev/

pier25 4y ago

Don't get me wrong, this is supremely cool... but I wish the W3C and browsers solved more real world problems. 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.

shadowgovt 4y ago
What would that mean? And what version of "mutate the DOM via databinding" would win, because there are at least three different approaches used in various JS libraries? 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.
- pier25 4y ago
  > What would that mean? 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.
lima 4y ago
> 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. 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 https://lit.dev
- 4y ago

osigurdson 4y ago

Suppose you have a massive 3D model stored in the cloud, which weighs in at 100GB and requires most of the computation to be handled on the server side. In this scenario, would utilizing something like WebGPU be beneficial, given its primary responsibility for the final 2D projection?

debacle 4y ago
You'd probably implement something that does culling server-side, and then pass the culled model to the client.
- osigurdson 4y ago
  Would that work with vtk?
mschuetz 4y ago
You'd use level of detail structures, like google earth does.

topaz0 4y ago

I'd rather not have websites soak up my compute resources, thanks. They are already doing that many times too much for my taste.

mschuetz 4y ago
You're free to disable features you don't like. For others, this is good news.
- topaz0 4y ago
  Incredible insight, but I fear it won't work out well: when the option is there and ubiquitous, websites will rely on it, so disabling features is basically choosing to save some of my resources in exchange for a broken web experience.
  - mschuetz 4y ago
    Since I'm doing 3D graphics in Web Browsers, I consider not having 3D graphics APIs in Web Browsers a broken web experience. The browser is the easiest and safest way to distribute applications with virtually no entry barrier to users. I don't trust downloading just any binary and therefore I won't execute them unless they are from a trusted source. But with 3D in browsers, I can trust any web site not do damage my system and try a large amount of experiences that others create and upload.
    - topaz0 4y ago
      There are applications where the point is 3d graphics. I don't object to letting them use my gpu if they ask nicely. There are other applications -- really the vast majority of them -- where 3d graphics is completely beside the point, and has nothing to do with the reason I'm on your website. That is my concern: that that second class, being the vast majority, will say, "hey, I have access to all this compute power, why don't I just throw some of it at this needless animation that I think looks cool, or at this neural network, or at this cryptominer". Past experience suggests that this is a reasonable concern.

victor96 4y ago

This is super exciting for us as we develop interactive browser UIs. I hope future versions of WebGPU will be backwards compatible to all those with Chrome 113. We need an iOS like pace of updating for browsers!

paulryanrogers 4y ago
> 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.
- victor96 4y ago
  The difficulty is the number of people still running old versions, as soon as new iOS versions come out a super high percentage of people switch. And with browsers you have to account for the update cycles of every browser on the market.

raphlinus 4y ago

This is a huge milestone. It's also part of a much larger journey. In my work on developing Vello, an advanced 2D renderer, I have come to believe WebGPU is a game changer. We're going to have reasonably modern infrastructure that runs everywhere: web, Windows, mac, Linux, ChromeOS, iOS, and Android. You're going to see textbooks(*), tutorials, benchmark suites, tons of sample code and projects to learn from. 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 https://github.com/gpuweb/gpuweb/issues/3950 [2]: https://docs.rs/wgpu/latest/wgpu/struct.Features.html#associatedconstant.TEXTURE_BINDING_ARRAY https://docs.rs/wgpu/latest/wgpu/struct.Features.html#associ...*

eachro 4y ago
Suppose you're a ML practictioner. Would you still recommend learning WebGPU, over say spending more time on CUDA?
- raphlinus 4y ago
  This depends entirely on your goals. If you're researching the actual machine learning algorithms, then use a framework like TensorFlow or Torch, which provides all the tensor operations and abstracts away the hardware. If you're trying to get maximum performance on hardware today, stick with Nvidia and use CUDA. If you're interested in deploying across a range of hardware, or want to get your hands dirty with the actual implementation of algorithms (such as wonnx), then WebGPU is the way to go.

neoyagami 4y ago

I hope this is disable by default, the amount of fingerprinting it will generate kinda scares me.

notorandit 4y ago

For Linux too?

notorandit 4y ago

For Linux too? Not now!

waynecochran 4y ago

Is the camera capture support on mobile devices (perhaps loads video frames into texture map)? I assume this is what webxr is doing somehow?

switch007 4y ago

How does this help web fingerprinting / Google’s revenue?

markdog12 4y ago

Note that this has not shipped to stable, it's currently in beta. I read an unqualified "shipped" as "shipped to stable", but maybe that's just me.

yagiznizipli 4y ago

I think it’s time to support WebGPU on Node.js too. Happy that it is finally on a stable version of Chromium.

rock_hard 4y ago

This is an exciting day! I have been dreaming about WebGPU to ship in Chrome/Edge for as long as I can remember. Now hoping Safari won’t take another decade to ship proper support…because until then there is only very limited use cases :(

bitL 4y ago

Is there a PyTorch port running on WebGPU somewhere? So that I could add local processing for ML pipelines into a webapp, bypassing cloud.

waldrews 4y ago

How much easier does this make it for every ad and background animation to heat up my device and eat up battery time?

phendrenad2 4y ago

Maybe I'm dumb but what does WebGPU get you in reality that WebGL doesn't currently get you? I don't think we're going to see browser games any time soon (because it's trivial to just install a game and run it, and also the browser audio API sucks). And most visualizations on the web would be perfectly fine with plain old WebGL.

simlevesque 4y ago
> And most visualizations on the web would be perfectly fine with plain old WebGL. It's not made to make visualizations that weren't possible before, this explains that.
mattdesl 4y ago
Basically, an improved API that targets a more modern graphics pipeline and has better support outside of browsers. You can write a graphics engine or custom renderer in Rust and have it ship across desktop and web. See Vello for example: https://github.com/linebender/vello https://github.com/linebender/vello

bart3r 4y ago

Does model-viewer support WebGPU?

bart3r 4y ago

Does model-viewer support WebGPU ?

Alifatisk 4y ago

How will this compare to Gpu.js? https://gpu.rocks/ https://gpu.rocks/

hinell 4y ago

LINUX IS NOT SUPPORTED, WHAT A DISGRACE