Introducing WebGPU: Unlocking modern GPU access for JavaScript
Вставка
- Опубліковано 24 сер 2024
- WebGPU is a new Javascript API bringing more featureful access to the GPU while being more idiomatic to JavaScript. WebGPU is now being released in Chrome so websites can start relying on it. This session will describe WebGPU's history, show demos covering various aspects of how WebGPU improves compared to WebGL, the current alternative, and give a sneak peek at what's next in the future for WebGPU.
Resources:
WebGPU launching in Chrome 113 → goo.gle/3pe4AQp
Codelab - Your first WebGPU App→ goo.gle/3LLMKfq
WebGPU: Unlocking modern GPU access in the browser → goo.gle/42ehWel
Speakers: Corentin Wallez, Brandon Jones
Watch more:
Watch all the Technical Sessions from Google I/O 2023 → goo.gle/IO23_s...
Watch more Web Sessions → goo.gle/IO23_web
All Google I/O 2023 Sessions → goo.gle/IO23_all
Subscribe to Google Chrome Developers → goo.gle/Chrome...
#GoogleIO
Want to learn more about these announcements? 🤔 Ask the Chrome Dev team in the comments below. 👇👇🏻👇🏿👇🏽 👇🏾👇🏼
The technology sounds and looks awesome, but i'm affraid of one thing, we already suffer from a influx of deveolopers who build very heavy websites and always say the classical *It works on my macine* meanwhile their machine is ia 64core procesor with 64gb ram and nvidia4080, would this open the door to even more bloated web that will force people to upgrade their hardware so that *they get with the times* and create more and more e-waste on top of all planned obsolence that's already happening on windows and mac hardware?
When will google stop pushing pointless bloat into web standards?
@@zc8750 WebGPU is designed to work on a wide range of hardware, from mobile devices with relatively modest GPUs to high end desktops, and the API gives them the necessary information to scale their workloads appropriately. Furthermore, developers need to explicitly opt-in to using more advanced features and limits, which should help guide them away from creating content that exclusively works on high-end hardware by accident. Web developers are always free to choose their target devices, of course, but WebGPU offers the tools needed create GPU-enabled applications that work across the full spectrum of user devices.
@ChromeDevs, you are the best! I am glad you are interacting with us developers. As a developer, I think it would be awesome if we could develop plugins for UA-cam. Not as a Chrome plug-in though. UA-cam plugins would be awesome
The WebGL 2 vs WebGPU difference was insane. 500fps was already very good, but getting around 7000fps in nuts!
its is closely model after vulkan
@@iceteazen and vulkan is the least user friendly API I've ever seen, it feels like you are writing your driver for the gpu, you are mostly on your own.
@@utkua I know but I already tried WebGPU and WGPU(Rust binding) and it is more closely model after Vulkan. Like you have to create render pipelines. binding textures, shaders and other buffers to that pipeline. creating render pass. creating compute pass. WebGPU is just least complicated like you don't have to build a swapchain anymore like in Vulkan. WebGPU shading language WGSL is kinda different though designed after Rust which is kinda interesting design choice.
Keep in mind this was "virtual FPS". They were computing "highest possible FPS" based on how long the client takes so send commands. In reality, FPS is much lower because the GPU still needs to draw everything.
The important thing is the improve factor (x14) , nobody can see in 7000 fps
I've been playing around with it for a month now and I'm super impressed! Great work, team!
I am so excited about this technology and how it's going to change the web landscape in the coming years. I think this is a big deal.
Sounds like a huge enablement opportunity for Flutter-like frameworks to land more gracefully on the web
Imagine that this tech is released in the GPU mining era... One wrong click means you mine on your GPU... Everyone is a miner if they open a wrong webpage...
I have a similar concern...
They were already doing that by having people download fake extensions
That era isn’t over…
There is still massive mining
If that becomes a concern then there will be a market for antivirus to detect those.
I've been waiting for this to release for so long!
this is huge! this might mean platform agnostic games!
Damn, you're right!
Bottleneck is the game assets download size, if it downloads for a long time everyone would quit immediately.
@@SirusStarTV Fiber-optic connections can download hundreds of megabytes per second!
@@SirusStarTV All it needs is some optimization. Imagine a future where you can download and start playing a game (real AAA stuff) in your browser on any device with no overhead as easily as you can stream a movie or UA-cam video. Remember when Minecraft was a browser game? It worked as a Java applet before support for it went down the gutter. Flash also tried this, but it had its own problems. The difference here is that it’s embedded into the browser and works like its own API like Vulkan, OGL, or Metal.
@@Jianju69 cries in 50mb/s
I saw Google Earth in the list of WebGPU ports at 9:13, is there a publically available version to try out? Is it in the current web version of Google Earth?
Finally we've got this long awaited feature. Hopefully this will be shipped to other mainstream browsers ASAP
If they add TCP/UDP, Multithreading, and WebGPU, theoretically you can run an entire virtual machine in the browser.
I am no expert but I think you can achieve that with WASM alone.
I'm excited for when some UDP api comes out
Imagine client-side VPS
The web browser is a virtual machine. Websites (aka web apps) are the programs it executes.
I saw webgpu can run outside of the browser (at least I heard that advertised). Last time I tried it was really complicated and undocumented. This I think should be documented more in case someone wants to make an engine with no other backend than webgpu - which might be actually a not bad compromise on performance on desktop while still not fully being vulkan, neither the old gl style or old dx thing. Then of course in one shot that would make the stuff just run perfect in browser too.
One option is to develop in Rust with the wgpu library. You can compile to desktop or the web with but a command-line argument for the target.
@@Jianju69 I prefer not coding in rust but in C++. For there I look for libs.
YES PLEASE! Similar to what node did to V8.
I guess it would be not impossible to add WebGPU support to one of the none browser WASM runtimes to support this.
@ It totally is possible, like previous answer points to a solution that uses RUST. I also know there is C bindings but documentation is really sparse...
So yes you can use webgpu on native code / desktop, but my complaint is that very bad is the documentation and I think this is a really nice use case (like your engine can target webgpu both on desktop and web). It is somewhat documented for rust, but I do not want to use rust...
Thanks Chrome Team, was waiting for this feature from last year.
Hi! Are there WASM feature proposals that will enable WASM to WebGPU without JS? If so, which ones, and what is their ETA?
No idea if it's allowed to post a link here, but the video "WebAssembly: A new development paradigm for the web" on this channel talks about that. Starting at 11:50 in that video, the functionality of the ongoing WASM garbage collection proposal is introduced and starting at 15:22, it's explained how this allows direct access to web APIs (including WebGPU) via WASM.
@@feathecutie9942 I've seen that video. But as I understand, it will allow for much faster access to the web apis including WebGPU, because of passing by reference, but JS glue is still required to do the passing.
If that's right, I wonder what the remaining performance penalty will be for that remaining JS. And I'd like to see it gone even if it's small, hahah
I've watched a fair number of WebGL & WebGPU videos. This one actually has details I learned here (meaning new value to my brain). I'm on the edge of going from WebGL2 to WebGPU (for reference).
Love Brandon Ross 😁
webgpu will effect anonymity/privacy because webgpu can render a specific program that will make a kinda fingerprint like unique pattern on render because modern gpu are so complicated that each gpu render unique in micro level like two french fries are same but unique in micro level of detail.
there is no 100% identical fries in world.
they already do that
Exactly.
you could easily render fingerprints like that before even webgl... the tricky part is actually finding a useful fingerprint and having it stable enough to be useful for tracking. even then, it's just data like any other, this doesnt really enable anything new or really even change anything in that regard. still source executing in the browser, detectable, interceptable, and blockable like any previous iteration
This is exciting! Brandon's voice is somewhere between Mr Rogers and Brilliant Movie Villain, but the announcement is great news
can we now run Call of Duty at 60fps in Chrome?
WEBGPU LETS GOOOO
PTSD moment: 8:52
Web games are about to boom again
That is REALLY exciting
need to add UDP and looks like multiplayer games may move into the browser))
Exciting!
So RAM was not enough you want my GPU also.
This is nuts. We are going too fast, just wondering what is the end!
Yea so when Flutter will be having this on web so that we could have that fragment shader working 😁
Will implementing WebGPU in game engines like Unreal and Unity improve their performance? Or do they already have strong gpu rendering?
Depends where the bottleneck is, but webGPU allows more complicated graphics shaders, and "compute shaders" that can be useful for some highly parallel tasks.
How, do you think, would it improve their performance?
WebGPU, if used from the C/C++ bindings, is an abstraction layer on top of DX12/Vulkan/Metal. There's no inherent performance advantage compared to using them directly.
7:34 for people just want a quick comparison in performance numbers.
Where do i donwload chrome 113? ive looked everywhere but every download i find isnt from the official google website
I wonder if displaying a classic video stream on a browser and using WEBGPL like adding layers to add augmented reality would be efficient.
Now, you'd better start working with PWAs. Don't neglect the use of PWAs just because your Play Store might become obsolete if PWAs improve.
now every page i open will have background compute shader task either for crypto or ml calculation.
2:36 - that's very smaleless of you to compare Javascript running code vs shader running code. Shader code will run great even if it is in WebGL 2 environment.
yeaaaah boiiiii
Is there any latest update regarding support for non-ChromeOS Linux? (1:49)
Will Unity or Unreal add this to their platforms? Still been working with WebGL and would love a big upgrade like this.
what about ios support?
will WebGPU support threads? I hope so... I even saw someone from the Google Earth team ask about this
Yeah, I saw a talk where someone said that WebGPU had setup some part of the API spesifically because they where preparing for that the be implemented later. I could be misremembering though, or they could have changed their minds since then, but I dont think so. My impression atm is that threads is something they want to support
What would be the benefits of developing complex graphics and computing applications in Javascript over C++?
It's not a matter of Javascript vs C++. It's a matter of doing it from within the browser or not.
For one thing, if you know Javascript, you needn't learn C++. You can also target webGPU with C++ by way of WebAssembly (WASM). And yes, Hannes is right: targeting the browser affords the trust associated with that platform. C++, on the other hand, requires one to trust the developer.
It's more a question of how portable you want the software to be.
This is lower level abstraction than WebGL, but it's still an abstraction on top of Vulkan/Metal/DirectX/etc
Thanks google for building standards and not trying to enforce chrome!
-and thanks to Apple too for following this new standard as well!
I think it's established that this is the only viable way for web tech
Wonder how/if this will affect the Skia renderer specifically in the context of React Native Skia.
Amazing.. the foundations for the true Metaverse.
ok but can it run crysis
sir, it's mean perhaps in the couple of month there's is game multiplatform such a valorant on the browser, isn't it? sorry if make you guys laught if you read it
is there any chance to use python for web browsers in the close future????????? T.T
Compiling python to webassembly is a thing, and so is webgpu using python. As for both in combination, I have yet to see it done.
finally!
maybe firefox will follow with enabling it in stable?
wgpu's webgl backend is horrible...
Here we go, a lot of exploits can be used, the web will become a huge crypto mine
If you see that a shady webpage is using too much of your GPU, just close it. I don't see what's the big deal. I doubt it's still profitable to do such "scams" even.
@@MrTomyCJ as "exploits" I mean they can break the browser sandbox and find a way to your computer. This is still a problem but at least very rare. When they introduce WebGPU, this opens a huge hole for exploits. Is it really needed? Depends on person but probably most people will not ever need this feature. Closing a web page is not always the solution.
@Saik Fait Does disabling "hardware acceleration" on Chrome disable webgpu and make that not an issue? Or is there no way to get rid of webgpu?
One year later, still doesn't work
Skyrim in Google Chrome )
can we use it through webassembly ?
Unfortunately you still need js glue...
@@erithax For now.
@@erithax Libraries like web-sys handle it pretty well.
still wating for unreal to join the party...
WebGPU is cool and all, but WGSL is a massive step backwards. It's now much MUCH more verbose (anyone fancy writing everywhere without inference?) There is not even double precision (which is fine since GPUs are optimized for single-precision), and you cannot typealias them since vec{N} are reserved keywords. There's also no function overloading, no swizzling (by far the best feature of GLSL) and no assignment operators for your vecs and matrices and no preprocessing (it assumes that people write WGSL inside JS strings ???).
I hope WGSL sees improvements in the near future, because it has been a mess to work with and isn't actually easier to read (or write) than GLSL.
It sounds like you last used a relatively old version of WGSL. It's improved quite a bit in short time period! It now includes vec4f as an alias for vec4, vec4i as an alias for vec4, and so on for all vector and matrix types. It also has GLSL-style swizzling. There's also been a large number of other syntactic sugar improvements, such as the ability to declare vectors with the same value in each component with vec3f(1), etc.
Function overloading and preprocessor statements are still not supported, which can be a pain depending on your coding environment. But overall I'd encourage you to give WGSL it another look, as the language ergonomics have improved significantly.
Yeah, there's still a bit of work to do with the shader language, but they do have shorthand versions of variable declarations now, though it is still a bit verbose. They don't have ternary operators, either, but instead encourage a lengthy select() function, and they don't allow multi-channel swizzle-assignments, either. But I am still happy that I can do everything with it that I can with other shader languages, but with more performance behind it than WebGL. Just be patient, Daniel san.
@@BrandonJonesToji Thanks. Is there a place where I can see the changes to the language from version to version? I could only find the W3 draft archive which has too many drafts to go through one by one, and gpuweb repo and wiki.
I have to be fair I haven't used it in a while, so I'm glad to see some of the issues are being resolved.
My coding environment is often across platforms. I am usually doing my own preprocessing, but it still feels like 90s defines with the same footguns unfortunately since we can't extend the syntax easily.
As for function overloading, it's a bummer we don't have it yet or at least some variant of it.
@@dealloc Oh yeah, not having function overloading is a pain, especially since DevTools doesn't yet support syntax highlighting for WGSL, which means you can't collapse all of the copies of a function you'll inevitably have to make.
Google i want to learn swift and kotlin and stuff help bro pls
50 lines!?
Why are they "introducing" this? This has been in firefox since 2018
Are there any interesting use case for this tech? Like, something for which it will be actually useful, or something that only it can do? From what I understand, web-based games will now get better graphics, but someone who has a powerful GPU will obviously be playing normal games anyway.
At minimum, you get fancier webpages that do not lag at all (since your CPU is free).
One big advantage is that it's a portable, low-level graphics API that can easily run outside a browser environment. Might be relevant for indie developers/open source projects?
Web games is not really the main benefit of tech like this. It's mostly about fancy effects and maybe charts and other visual stuff. Like very performant node illustrations. Or data. Or fancy animations and effects. Three.js is a library ontop of the old WebGl and if you go to their homepage you will see a mountain of examples of how tech like this is used in practice, little to none of it is for actual full games.
I'm download chrome for android 10 and that's come with 2 part. 1 is chrome itself, and 2 is trichrome libraries
Everytime i update, the trichrome libraries is not delete the old one. Instead, that add one another with different version. I have total 20+ trichrome libraries. Each files size is 60mb. How i delete that?
tldr; chrome now has a simple and fast api for GPUs.
Wait, I need 30 lines of code just to draw a triangle?
reminds me of the time I thought learning Vulkan was a good idea for summer and couldn't get past the first gradient triangle tutorial lol
You should try printing a triangle to the screen in OpenGL.
Vulkan requires 500+ loc my guy this api is a dream.
Hey lets invent a new shader language based on rust so that all the investment made to existing shader language go to waste.
I'm glad he/him notified us of its pronouns.
we need a good framework to use gpu on web, like game engines. google should do more work than saying it just works.
I'm all for making the web faster, but Javascript is a joke of a language and it needs to go. Please take HTML and CSS with it.
Rust-Wasm is all you need when they get all the features
If only c++ or python had been used to script html animations.
Imagine what other world we would already be in...
imagine compiling on each html debug
imagine me injecting binaries and dll into your system instead just browser environment
@@epicmetod... in fact, it is the same to say : Imagine compiling Blender 3D everytime you start it... NO. You download compiled binaries, not the source code...
But every web languages is in a controlled environment. This is the main reason every languages is not available right now in your browser. Compiled ones, yes, is not the most safest. Today, you have VMs or anything else to prevent this.
But python maybe is a simplest alternative, because the web browser just need to implements theirs authorized libraries.
Python is already a big helper in the industry to manipulate most capable compiled binaries in a "few lines".
Sorry for my English. It's my first time. I write this without any kind of translator.
Let's Go Brandon!
@@Gwizz1027 what? i don't get it
Manusia penghinat
Someone stop JavaScript please
why javascript of all things...
Google literally recommended this video to me twice on the same homepage. I'm still not using Chrome.
EDIT: This is a joke, I thought it was funny since I am not on a chromium-based browser right now and I got the same video recommend to me twice right next to eachother which hasn't happened to me a lot.
The point is to spread knowledge of WebGPU. It's not an ad for Chrome
video says Firefox and other companies are planning to implement it in their browsers 9:44
Its not just for Chromium
Dear god no. Why is this a thing.
I hope this can be disabled. Do not want.
It would be nice if chrome developer can figure out a way to hog less RAM