30s in and all I could think of was how much the video structure and script reminded me of NoBoilerplate videos. Pretty cool to see your comment, I'd guess that you're an inspiration for this channel.
Weird video. Talks vaguely about vulkan vs opengl vs webgl then suddenly it's shaders and programming. I mean, that's like giving a geography class like "here's your desk, here's the hallway, here's the bathroom,... out there, that's the Sun, and we're in the Milkay Way..." like bro you skipped all of the important stuff. Like for starters, where does WebGPU code even run? What are the options? Is it all in the browser? Can it be server-based? Can this be used for native mobile or desktop apps? Like really, you skipped literally all of the basics.
Hmmm. You're actually right. Since I'm a developer I have the answers to all of those questions in my head already but for the viewer, those are important details. In my next video I'll mention these things. Thanks for the precious feedback.
The cool thing about WebGPU is that it abstracts away the underlying API, be it Vulkan, DX12, Metal… so it gives you platform-independence for free, really nice
Oh, you mean like OpenGL did ? that is why OpenGL is criticized as slow on weak CPUs, because it abstracts the hardware (if the CPU is powerful then the overhead is little problem).
@@staubsauger2305 No, OpenGL is the graphics API that gets implemented by the driver but OpenGL assumes lots of things about memory and buffer layout, etc… New APIs like DX, Vulkan, Metal are more verbose but not cross platform (except Vulkan for Win/Linux)… That‘s why WebGPU is so cool, it brings all those APIs under one hat and uses the best API below, even OpenGL if necessary
@@maxkofler7831 the OpenGL model is that the driver implementer knows more about the hardware than the average developer. The hardware is abstracted and the application developer has a more limited ability to control execution so some optimizations are not available, except through the extension mechanism. In contrast, lower-level APIs give more ability for the appplication developer to optimize at the cost of greater development time, greater risk of bugs and the app developer has to do more work for performance on each architecture. It's a trade-off as everything is. WebGPU is a return to OpenGL in the sense that it is a higher level of abstraction than the underlying layers - which means many of the things moaned about in OpenGL must necessarily return - which is ok but folks have to be real about it instead if merely 'teh nu shiny'. That's all I'm saying. And platform-independence is a must, devices are becoming more heterogenous rather than less (eg. the 3. 3 billion devices running the Linux and Java flavors branded 'Android').
The biggest problem for us was absence of support for IOS. We wanted to make true web cross platform game, otherwise it is just much simpler to desktop applications
Wow, you managed to condense all the things I learned in many days of banging my head on the wgpu docs in just a few minutes. Thank you so much, I really loved the easy explanation - looking forward to new episodes!
0:38 even Vulkan isn't totally considered as a "replacement" to OpenGL , people still uses OpenGL in their old/new project (if it's not much graphic demanding) bcoz Vulkan being more low level is too verbose and kinda tougher compared to OpenGL
Great explanation! For me, anything that has to deal with the GPU for UI always ends up being super complex and oddly verbose, I wonder if I'll ever be able to learn that. I always felt like it could be simpler but I'm sure it's like this for a reason
I've been using threeJs and three fiber for the last 12 months building web stuff with my 3d projects out of cinema4d. Really cool to learn about webGPU. I'm really excited to see where 3d experiences on the future web end up. Thanks for this awesome intro / breakdown.
Thank you so much for covering something like this. It’s very hard to find beginner friendly tutorials especially when it comes to graphics. WebGPU is only going to make this field more accessible, so all the more important we have content like yours 😊
Oh, good. It's open source, of course, it goes without saying, right? Because you know, OPEN gl has OPEN in the name, and that's why it was much better than whatever this is. So weird that he literally does not even mention under what kind of licence it is. Or what corporations want to make this standard and why they really want it. It's M1cr0s0ft, Mozilla, Google and I don't remember the other one. Less under commercial licence crappy standardized crap, and more open source things and less standardized, please.
This is the first time I've heard a fragment shader called a pixel shader. If the goal is to teach without confusion iwould stick with defining and using conventional terms.
Nice vid. Just a quick tip; make sure you cut off all the low end of your voice recording, this will make your voice a lot clearer and not be super bassy for people who listen on headphones
The one drawback is that you start out saying that the viewer only needs to know JavaScript. Then the first piece of code we see is TypeScript. The two are not the same.
You are correct! However I didn't want to make the explanation complicated. you can use the drawIndexed function in your renderpass in WebGPU to make that happen.
Thanks for this. I've written a fair number of shaders in HLSL and had very little trouble following along to broaden my knowledge (at least, to begin doing so) into this new area.
Amazing that Flash back in 2016 was doing this already but 1000% better. The web is really slow today, ugly websites and there is not more innovations because there is an app for that. In 2023 and this is what we get?
In 2023 you're getting the foundation of the technology that's going to power AAA games in the future. ( This is just my opinion ) But I agree that flash was super cool back in the day and I also agree that there could be much more innovations in this space. My hope is that WebGPU is going to give us more power to make that happen.
Back in 2006 I did things with Flash that no HTML5 and webGPU is capable today or tomorrow, the problem is that innovations on the web died with flash, today ALL websites takes forever to load, ugly, videos don't have Alpha, it is true mess. Websites are a thing from the past, Apps is here to replace websites because they are just used for data or text re-source. People did not know that Flash was a platform that you could create super fast applications in minutes vs months and it works 100% every time if you knoew how to use and code right (Just look at Fox news and CNN website, what a horrible experience with Ads all over and videos/ui that does not work in both PC and Mobile. And today we have very fast internet and every site takes forever to load@@visionary_3_d
Better, more complex experiences on the web. WebGPU has a massive potential for increasing compute power. This means that you're gonna be able to do many things faster (most of these things are graphics related). If you're interested you can search for Applications Of Compute Shaders. ( On Google )
@@visionary_3_d can we write algorithmic functions and have them evaluated on the gpu using compute shaders ? If so it’s applications could extend beyond just graphics, provided there exists a performance benefit.
OpenGL (especially on latest versions) is good enough, but it still doesn't expose some specific modern GPU APIs. It's enough for 2d and basic 3d rendering, but when building a 3d game, you'd probably want to use various hardware acceleration APIs. Also, because OpenGL is considered legacy, modern GPUs are gradually dropping hardware implementations for some OpenGL-specific stuff, moving it to software driver implementations, using CPU to translate old OpenGL commands to a new format used by modern APIs
You learn by doing. Try to recreate the websites that you like. Start with easy ones. You'll learn javascript and every other thing you'll need along the way.
12:50 - "there we have a variable, that makes sense, because it changes" No it's not. In DirectX and HLSL it's called a constant buffer. In Metal API it's just declared as a "const & name". Uniform buffers are not meant to be "variables". It's mostly always a read-only data. Unless we talk about more generic cases of exposing direct GPU buffer addresses in shader and writing to them.
You're 100% right! Thanks for pointing this out. I think when I was describing this I meant: "it changes from the outside" and uniforms update frequently. But technically your description is correct.
Thank you sooo much, i came from Nik Lever glsl course but i cant understand if i dont visualize, it was really hard to find out without a good analogy in his videos, but you completely nail it. nice job!
I have looked at babylon and here's my recommendation. Babylon is fantastic for creating more complex projects compared to raw WebGPU. However learning WebGPU first provides huge advantages in the long run, since you understand what's happening under the hood. I don't think it's that much easier to learn Babylon first, since the layer of abstraction that Babylon provides is thin, IMO.
Vulkan is no replacement for OpenGL, because it competes in an another area; in the low level area. It's like saying that Assembly is a replacement for C++.
