A proper look at WebGPU for native games
ฝัง
- เผยแพร่เมื่อ 6 มิ.ย. 2024
- In this video we take a proper look at the new WebGPU graphics API, support for which was recently added to the Basis engine. How did it go? For more information, check out the development blog at www.madrigalgames.com/
Porting my renderer to Vulkan: • Porting my renderer to...
"I want to talk about WebGPU": cohost.org/mcc/post/1406157-i...
The WebGPU C++ guide: eliemichel.github.io/LearnWeb...
Dawn: dawn.googlesource.com/dawn
wgpu-native: github.com/gfx-rs/wgpu-native
Naga: github.com/gfx-rs/naga
00:00 Intro
00:38 Background
03:22 What is WebGPU?
09:52 Shader transformations
17:40 Some good articles/resources
20:05 A look at the API
22:42 How did it go?
25:49 The current state of WebGPU?
28:02 Things I like :)
29:33 Things I don't like :(
30:25 Things I meh...
31:38 Outro - เกม
The colors and movement give me the feeling of halo 3 in your demo, it looks fantastic.
I use wgpu in rust, and for the most part it is a very pleasant experience. The docs are fantastic, and it's incredibly stable. Performance wise, there is a little bit of overhead over raw vulkan or other native APIs, but with the automatic synchronization, resource transitions, and memory management, I find that my first-pass at just about anything I'm trying to do in wgpu is usually more performant than in a native API. For context, I'm mostly coming from metal and D3D11 here.
Another wonderful aspect of webgpu is that while it is simpler than vulkan/metal/d3d12, most of the concepts map very well to them since they have the same general structure and methodology (as opposed to opengl, for example), so if you start with webgpu, the learning curve of the native APIs is much less steep.
@@rytif Of course nobody likes rust - they LOVE It! How else will you go 🔥blazingly fast🔥?
@@rytiflol i don't know about that! i'd take rust traits over c++20 ranges any day!!
@@rytifskill issue
@@rytif "Real game devs" don't use it because the ecosystem just isn't there yet, simple as that
I like this trend of new web technologies actually making themselves useful on the native side. WebGPU for universal graphics, WebAssembly as a universal compile target and sandbox.
This has been incredibly informative! Amazing video
Thank you for taking the time to explain all these different aspects with such clarity!
Even though i'm not a programmer, i find myself looking forward to your videos! They're quite informative. Thanks for your hard work!
More content like this, please! Great stuff!
Thank you so much for making this video! I've been waiting for something like WebGPU my entire graphics programming career - lower level than depending on a complete game engine, but also write once, run anywhere. I put off learning shaders for many years. This video is well-explained and confirms my hunch that I might as well skip all the other stuff and jump right into WebGPU.
You're very welcome!
Great video. First one I have seen from your channel. I will definitely keep an eye out for it.
Thanks for the resources! I recently discovered WebGPU, I do want to do web apps but I've been struggling with ThreeJS, basically because of documentation. Nice work!
Good video! Amazing work!
Cheers!
That looks so interesting! I had no idea, that this can run locally.
woot, I've been looking for a vulkan wrapper and this was some great info!!!
Glad to hear it!
Great video!! Thanks for making it!! I appreciate it!!
Good video, thank you for sharing 🙂
Great recording. thanks a lot
Cool video! Would be nice if you used a bigger font though, it's impossible to view on a phone
I am working on a python library to run webgl shaders. And I somehow chose to do so with wgpu-py, which are python bindings for wgpu-native and it's quite the learning experience
Really interesting video ;-)! FYI, I'm also trying to build a 3D engine based on native WebGPU myself. Pretty far from where you are at, but I'm learning and working my way ;-)
Hey, thanks! Good looking stuff on your channel, keep going! 💪
For Zig, there's sysgpu from the Mach engine. It's still experimental tho.
From what I've heard, the reason we have WGSL instead of just using SPIRV I think has to do with Apple? There wouldn't be any legal issue with just using SPIRV, I think, but Apple didn't want to have to support something that has to do with Vulkan, I think, and they wanted to have a textual representation for the shader language, rather than bytecode.
Yeah, fuck Apple. We were so close to have WASM for the GPU, so that anyone could just use whatever language they wanted, instead Apple decided that it had to break the standards to retain a sliver more power in the market.
I heard WGSL is also similar to Metal shading language
That's a ground-up engine that you wrote or did you fork something open source, cause if it's completely written by one person, that's amazing.
Thanks! And yes, the engine is self-made. I started working on what would become the Basis engine in 2010. It's a large project. Of course, I use a few libraries to drive the thing, eg. PhysX for physics.
I use Threejs
subscribed !
Recognized a fellow Finn well under 10 seconds. Our accent, while kinda ugly, is very easily understood (I think).
Voi veljet!
The game reminds me HardTruck Apocalipse, old game from my childhood.
where is this gamedev repo? do You have any pre-alpha to share/play??
Current wgsl looks great to me. Used to be really annoying using the rust-style type decorators. Maybe eventually you just write wgsl.
If I wanted to make a backend, what are the basic functions that make up the common ground here? This has been a thorn in my side that I do not know what exactly I need to be able to externally call to make a full renderer
Looky here: eliemichel.github.io/LearnWebGPU/introduction.html
Good video. I like the graphics of the game, it looks good. I wish I would be able to achieve such graphics with my project : )
Can you tell me the name of the code theme of your visual studio please?
Thanks, that's nice of you to say! The color theme is just the default VS dark theme + Enhanced Syntax Coloring provided by Visual Assist X.
Pretty cool :) I wander if you plan to completely switch to the WebGPU someday?
I don't think so, at least not for a while, and not until the API is stable. I also have the luxury (if you want to call it that) that I have a common API on top of the graphics APIs, the point of which is that I can change the underlying API without having to redo the core engine or game code. So there is really nothing to "switch" in the code. I just load the backend as a plugin. I can of course stop loading other backends than WebGPU if it becomes the "best" one, but currently it is not. D3D11 is still faster in Basis and has a bunch of features not available in WebGPU.
@@MadrigalGames The ability to develop for both native and web at the same time is too good to pass up for me.
Is this run on a webbrowser or a stand-alone app like Roblox?
It might be interesting for you to try some of the other backends to see how compatible things are. Do the D3D11 backends actually work well? Can you really transparently move between Vulkan, Metal, and D3D12? Can you get things running on iOS and Android? Are there certain memory patterns etc. that don’t exist in webgpu due to its web roots that can limit performance or capabilities long term? If webgpu supports directx11 well, then there’s no reason for you to support any other backend in your game engine. You might as well stop development of your directx11 backend. And if webgpu supports mobile well, then webgpu should be good for any cross-platform game development except maybe for consoles.
I am not going to drop my raw D3D11 backend, at least for a while, for a number of reasons. First of all, WebGPU doesn't support all features such as HW clip planes yet. WebGPU also only supports vertex, fragment and compute shaders, while my level editor uses tesselation shaders for terrain editing. That stuff could probably be rewritten using compute shaders but I haven't done that yet. Finally, having a plain D3D11 backend without any other dependencies is going to be really nice to have around, at least as long as D3D11 is relevant as an API target. Building WebGPU is a "whole thing" right now (see WebGPU C++ guide for more info) while D3D11 is "right there" when you are on windows.
I did briefly try running on D3D12 through WebGPU after publishing the video. Not all of my shaders successfully pass through Tint's D3D12 backend right now so I wasn't able to get into the game. The menus render completely correctly though, so it's a matter of time I guess. I should look at that more carefully at some point, but I haven't had the time...
Have you implemented vehicle physics yourself?
Nah, it's PhysX.
Did you work on Halo?
Web-GPU will also be supported on Android
How does WebGPU compare to something like Diligent Engine?
I am actually interested in this myself, so if anyone has experience with both, please let us know! That said, if the main thing you want to accomplish is abstracting away platform/API-specific differences behind a common API, you probably wont go wrong with either one. Again, strictly talking about non-web use of WebGPU here. When we get into the browser world there are many more differences between the two.
What did you make your game with
with just webgpu?
Hello sirs, how to send my 500gb unity game in the browser to users? I converted to webgpu why is it so slow, it says loading in 5hours when refrehs website
You just need to upgrade your hardware of course
Have you thought about making video tutorial how to get started with WebGPU for Desktop? I think most of tutorials only covers how to use WebGPU with JavaScript, not C++.
Nah, I am not really the tutorial-making sort. However, if you want to get started with WebGPU, the The WebGPU C++ guide is awesome! Link in the description.
@@MadrigalGames Understandable 😌Yeah I have been reading that, there is just lot of to take in 😅 I was wondering whether I could make DLL with C++, which I would use to access WebGPU compute shader?
I don't know exactly what you are trying to do, but yeah that can be done. In fact, all of my WebGPU code sits in a dll which is loaded by the core engine. And yes, graphics APIs overall tend to be a lot to take in :)
@@MadrigalGames Nice to know 😁
I just like to fool around with game engine called GameMaker, and I have circumvent lack of compute shaders by misusing GLSLES fragment shaders. In a year though, GM is going to have large update, where it will also adopt WebGPU. Meanwhile, I want to learn using WebGPU, so I will be prepared, but also learn API, as in general I think it might be useful.
I like the aspect of WebGPU being able to run in browsers and natively. I just don't see it being all that useful right now. It seems like the API is nicely supported in Rust but documentation is lacking in other aspects. Could be wrong though.
Using it from C/C++ through Dawn is a mostly pleasant experience. I don't know about Rust but I expect wgpu-native to be the way to go there. The docs are definitely lacking, which is why I am mentioning the WebGPU C++ guide.
nice pfp
Not useful? Getting the ability to choose what underlying graphics API is being used is super useful for cross-platform development. Also having common shading language that works with all APIs is dream come true for developers who are mainly interested in compatibility between OSes and hardware instead of making use of hardware or API exclusive tweaks. Writing and maintaining draw calls and shaders happens through single abstraction layer once only.
@@meanmole3212 maybe I should have rephrased it as 'not quite ready for the masses in its current state'
It's going to be incredibly useful for lots of non-graphics applications. For example, running ML models through WebGL requires the models to behave like shaders and, as such, tensor data needs to be passed as textures which is a slow process to pack and unpack textures. With WebGPU you can skip all that and work directly with the GPU without needing to hack a graphics API.
I wonder if this will essentially do what flash did back in the day. Basically be a powerful thing people can write browser games in.
Just note, I'm talking about the positives flash did, not the insecure buggy mess it is remembered as.
I am very confused about WGSL too. It's so unclear! My experience is only disadvantage. It only look like wheel reinvented. Yes, it's wheel, but it's MY wheel!
WGSL was needed for apple support. There was no way around it. For Linux and Win and likely even consoles SPIRV would have been ok, but apple was closed doors company for vulkan related stuff.
That being said having their own shading langauge is not only bad - it also has some benefits. Previously they were pushing spirv, but on apple you had to supply other language shaders which was worse...
Well, MoltenVK also gets the job done to run SpirV shaders on macOS. So technically this was always possible. Apple is just annoying when it comes to figuring out cross-compatibility.
wgpu?
yeah, it has a strong affiliation with mozzilla, it's literally their implementation of webgpu for Firefox WebRender.
also, wgpu allows using glsl and spirv directly, backed by the naga shader transpiler.
i can hear the finnish accent trying to escape🤭
This is a nice videobut code is a bit small. Hard to read on small screen
But what are the advantages over a native app?
Not sure what you mean. This is a native app.
where can i download the game?
The game is not out yet.
@@MadrigalGames okey! Thanks!
I'm a web dev, so I'm not very knowledgeable about gaming dev, but I want to know why a game dev would use Vulkan, OpenGL, webGpu...rather than just using a complete game engine like Unreal, Unity... ?
Check out the channel Q&A video, in which I answer this question, among others! th-cam.com/video/NXaPmWoEqlg/w-d-xo.html
Not requiring people to download something is incredibly powerful. Runescape's initial success was the fact that it could run in a browser. Minecraft was mostly in-browser to begin with, too.
While that is true, the Basis engine currently doesn't run in the browser, so it doesn't help me there.
The aim is to be used by game engine and GUI SDK famework , but no body will prevent you from using them directly to make a game 😎😎😎
One reason is because some just like the freedom of being able to build their games and/game engines from scratch. Doing so, you will have to build your own renderers.
Another reason would be if the game engine you're using doesn't have the functionaility you're looking for, and so you might want to tweak what it does have or build the feature you're looking for from scratch (adding to the ready-made renderer instead of building the whole renderer itself).
The music drowns out your voice. I don't know whether you want to be heard on only a moderate sound systems but it seems like you had interesting stuff to say.
If AI can help with the coding.. it will be easy. Exporting into WebGPU within Unity and Unreal would be even easier. You can already export WebGL in Unity with ease.
Not stable tho
whe the web? browser eats a lot of CPU and RAM. Forget the web.
Because web technology has to be cross platform by design. Hence the sphere of technology that is branded "web technology" produces a lot of products and protocols that just work everywhere.
And in today's world where dev time is your most expensive resource. The web is an appealing target due to how quickly developers can build for it compared to a more native solution.
Going beyond that, computing power is no longer as expensive as it was in the past.
No, just no.
You make very wrong assumptions here about how the topology of the technologies you are using looks like.
I suggest you read the 0. Introduction of the WGPU handbook.
1. WebGPU cannot be compared to other graphics APIs, it isn't comparable, BCS it's inherently smth different and solves a very different problem than a normal GraphicsAPI, it infact relies on graphics APIs to actually function, it's only an abstraction ONTOP of those APIs, making it possible to write code once, deploy anywhere, and to implement future APIs jst like that, without having to rewrite your game's at all.
2. WebGPU as the name suggest, is for the Web, and only for the WEB!!!, its part of the whole, lets get rid of javascript and WebAssembly train. That's the entire reason you have Dawn, and WGPU native, that re-implement it to make it usable OUTSIDE of a browser... but that's causing more problems than you wished for it solves, imo.
Also:
HLSL - Is DirectX's shading language
GLSL - Is OpenGLs shading language
*stop here, those are the OGs*
SPIR-V - Is Vulkan's shading language
MSL - Is Metal's shading language.
Now, How tf else are you supposed to program a shader that supports all GraphicsAPIs? - If not by making an abstract shading language like WSL - Web(gpu) Shading Language
Otherwise you need to write your shading in, HLSL if you want to support DirectX, rewrite it in GLSL if you want to support OpenGL, then having to rewrite them into SPIR-V if you want to support Vulkan, I hope you get the idea.
WebGPU as a technology is an intermediate "API", you use instead of (not together or "for") other vendor specific APIs. (Vendor here OS vendors, but obv Hardware vendors *also* have to support whatever API you want in the drivers.)
(the term API is so overused it doesn't say anything here, its better to distinguish between WebGPU being a software abstraction layer or "Render Hardware Interface" short RHI waht they say..., and DirectX, Vulkan etc, so being Hardware graphics APIs which hardware vendors and OS has to implement.)
Which makes developing anything hard af, bcs you need to do double work if you want to support two APIs, on two different systems, or triple the work if you need 3 platforms to run on, and so on and so forth.
"The code you need to write between you and the API" - ? what? what do you even mean by saying that. Like, using the API? wtf is going on?
"There are some differences between dawn and WGPU native," - again, wth? - Yes obviously, bcs they are RE-Implementations of WEB GPU to be used WITHOUT the need of a Browser...
like, you can't even read the first paragraph of their README?
"you update when you want to update" - no, that's only the case with those re-implementations, if you use it in the browser you're bound to the version the browser it's running in supports.... that's only an "artifact" of you stuffing it in as a C library for native compiled code. (And then what do you compile it to, an exe? (only runs on windows, my guy, making it completely pointless to be using WebGPU anyway.... if your not just using it for the added ergonomics, I also rather use WebGPU instead of Vulkan directly, its a pain, i know, I feel you)
"Why they used WSL instead of SPIR-V... is a little unclear" - you forgot to say, TO YOU! - BCS if you use SPIR-V aka VULKANS SHADING LANGUAGE IT ONLY RUNS IN VULKAN!!!!
Yes, they could've built in transpilers that transpile your shading code of whatever you wrote, HLSL, GLSL, and cross-compile to what ever hardware and OS specific API it needs to use... but you don't see the massively increased complexity here?
You would need each a transpiler and then for n graphics APIs webgpu supports, n times a transpires:
HSLS to GLSL - HSLS to SPIR-V, HLSL to MSL, then
GLSL to HLSL - GLSL to SPIR-V, GLSL to MSL,
SPIR-V to HLSL, SPIR-V to GLSL, SPIR-V to MSL,
MSL to HLSL, MSL to GLSL, MSL to SPIR-V
Then when a new API hits the scene webGPU want to support, they need to add, n transpilers for n graphics APIs that they support. I hope you see how unreasonable this is, and they rather write one transpiler, just 1 for each shading language they want to support, and you write your stuff in an intermediate language, that will also tell you which things are 1-1 available in all shading languages, and other benefits.
And yes, it's trivial to transcompile them.... you literally proceed to show how, later on. BUT!, and that's a big BUT for a reason... if you write HLSL, you can never be certain if the features you are using are 1-1 available in the other shading languages you need to transpile to in order to run them.
Having one unified Shading Language, that is "intermediate" (bcs it litterly doesn't execute) is great, bcs you can be certain, whatever you write there, has equivalences in ALL GraphicsAPIs, WebGPU supports..... that's the whole reason of WebGPU in the first place. To write code only once, and run on multiple OS vendors, any hardware, using whatever "underlying" API it needs to in order to well run on that particular devide... the good old, IT just works™
So we don't have to implement DirectX, then rewrite everything if we want to support Vulkan, and then "Oh no, Vulkan doesn't have feature x or y, that we rely heavily on in our DirectX implementation."
Or, "oh well, we did everything in DirectX, get fed Linux and MacOS users..."
And the perfect symbiosis is if you write your entire program intermediately to be compiled into byte code for each target hardware its running on, only when it runs, so you only have to compile once too.... and how, where to "pre-install those transpilers without the user having to install them?
YES, THE FUCKING BROWSR, like javascript, your browser already ships the whole runtime compiler and standard library of javascript which is MASSIVE! btw, so it doesn't need to transfer those 400mb of the network each time a website needs to run javascript,
so any derpy grug brain developer like us can simply write code once, and it runs everywhere, even your grandmas phone without needlessly saturate networks, or having games to ship everything it needs to run... No, just ship the game code, and only the game code....
That's where WebAssembly enters chat.....
It's great, if you know where you're actually are in the world of the code, and what the topology of the technology stack you are using actually looks like, otherwise you will ask yourself silly sounding questions, like, why not use a api specific shading language to define shaders for arbitrary graphic apis.....
Until we meet again.....
Otherwise, If you made it so far, kudos to you, and it wasn't to shit on you, (kinda was at what you're telling other not-so-knowledgable people here, which could get a wrong impression)
It was still a great video, and I enjoy seeing other peoples journeys through this mess of things and stringing together libraries to actually make sh* happen.
I only know stuff, too much maybe, therefore hat's off to you.
This is incorrect. With SPIRV they would also only need one transpiler per backend.
In fact they would need fewer because they could skip Vulkan, which already supports SPIRV. And Khronos group already has a tool to transpile SPIRV to the other API specific shader languages, so a custom solution wouldn't be necessary. Developers would use any of the existing compilers to compile a shader language of their choice to SPIRV, so WebGPU would only handle converting the compiled SPIRV to the necessary shader language used by the target API. Mozilla's WGPU supports SPIRV.
The creators of WebGPU had reasons to use WGSL instead, but they are not any of the ones you listed.
Allright, well there are so many incorrect statements and weird claims in this comment I felt it best to properly discuss this. @MrSofazocker Looky here for your very own reply video: th-cam.com/video/7RxPIE6gNDI/w-d-xo.html
@MrSofazocker SPIR-V is for Vulkan, but also for OpenGL. But with SPIRV-Cross, SPIR-V can also be compiled as GLSL, GLSL ES, HLSL, and MLS. This means that Vulkan can be written with SPIR-V, but compiled into MLS, allowing it to run natively on Apple (iOS/OSX), etc. It has been tested and is functional on Windows, Linux, iOS/OSX, and Android.
It's truly the best cross-platform API, despite Apple's rotten attitude toward and war against it.
You have no idea what you're talking about.
Why are you speaking if you don't want us to listen ?