A triangle has 3 sides. Each one takes 13,000 lines of code to draw. The amount of code to draw stuff always seems daunting regardless of the tech stack chosen. Excellent vid!
Thanks! Helper libraries are useful for this, and presumably some already exist out there for webgpu.h (though I haven't gone looking much). I also plan to have easy mode apis just for taca to make direct coding much shorter and more fun and for smaller wasm binaries.
It doesnt take 13 000 × 2 lines of code to render 2 triangles, but somewhere in 13002 - 13006 range. 100 triangles - 13 010-13 100 lines of code, NOT 1 300 000.
i think it’s totally fine to inline the GLSL source code directly in the binary! seems to be a game dev tradition at this point. i really like the simplicity of it - shaders are (usually) simple and it makes ad-hoc metaprogramming of shaders easy, which imo is appropriate for shader code
This looks fun! If you ever get to making a launcher and customizable installer for this (think gog galaxy) I would totally throw my hat in the ring to make a gimicky arcade game for this platform
Webgpu is intended for more 3d intensive games we already have webgl and flash is so completely different that every flash game has to be rebuilt from scratch
On Newgrounds they have wasm converters so Flash still works, but everyone pretty much moved to javascript and webGL or ports of their games in WASM. There's actually more choices for games than ever on the browser thanks to Flash emulation through wasm.
I've always aimed at 100 - 200 SLOC per file... so I find describing 1400 lines as "relatively large" kinda funny. When playing the game of "our codebase is worse than your codebase" with colleagues, I often quote our 1000+ SLOC files as one of the "awful" things I have to contend with. :)
@@contextfree I havent looked over the header file's personaly but cant imagine it would be too hard. you could probably write wit bindings and generate them to some degree, as things get more complex.
Looked a little closer at this, you are going to have a slightly issue where grain doesnt let you export the function table but with a single line compiler change that can be fixed. the rest seems pretty straight forward the hard part is interoping between the higher level grain types and the lower level wasm types but its pretty easy. I might play arround with it a bit more later and see if i can get anything useable.
Thanks for looking closer! And yeah, the function table export is pretty vital here. I was surprised how hard it was for me to find the right compiler switch to enable that in Zig. (Though the switch is fairly well named, it turns out.)
hey, just wanted to say that imo size doesnt really matter, like at all, for wasm, even if its web focused. Consider that, for desktops with fast network nothing matters its going to be fast af anyway and for slow mobile devices the consideration (compared to javascript) is parsing time not dl time - and wasm parsing is super fast. also, size optimized wasm usually runs slower, sometimes way slower, especially some of the rust tooling really deoptimizes your code. so, i'd suggest looking at other metrics than just code size. thanks for all the great content, hoping to maybe save you some frustration and time with the above info.
0:40, Tomb Raider 2023, running straight from your web browser! 3:25, you don't need to attribute all values, since enum does it for you, increasing by 1 each of them. I just use the 1st value, since I don't trust this default (it already changed in the past), and some value which runs away from the sequence, like your bits mask.
Yeah, I felt like being explicit here, even though it increments by default. And I'm not sure I like the "Force32" thing. I was copying that idea from webgpu.h just to see how I felt about it.
In the demo I notice that the rotation seems to be janking a little bit here and there. Can't tell if that's from the way it's captured or if it's also happening live. Any idea what's causing it?
I'm afraid some of it is from the original, as it takes careful observation, but I'm afraid some of it might be. If so, I'm not sure what's causing it. I think the rendering calls I've borrowed from the tutorial are supposed to avoid that kind of thing. I'll have to do closer analysis sometime.
I checked, and I'm supposedly on auto vsync. I had some extra manual delays happening that might have been trouble. I removed that now, and it still seems occasionally a touch janky but maybe improved? Using 6% CPU, so that should be ok, at least.
4:06 - D has nice C interop but you can't just include C header files, you have to first compile the C code, then link it and write bindings for the functions you need. It's easier than it sounds but it still requires you to use a C compiler in your build process
There's the relatively new ImportC feature, which is still a work in progress. I'm not sure of the current state. Have you tried it out? I haven't, so I can't speak well to it. forum.dlang.org/thread/u2el6n$1tee$1@digitalmars.com
@@contextfreeI had never used importC until you mentioned. That said importC only works with `.c` and `.i` files. That said you can easily make a wrapper c file like somelib.c that only contains: `# include ` Then you run it with `dmd somelib.c` and at least on my testing (trying a small sdl + OpenGL application) it works fine. That being said the documentation still lacks a lot of important details and on my tests it fails on complex C projects that use the pre-processor a lot (in DMD). But if you use the `gdc` compiler everything seems to work perfectly. I tested it with all the C projects in my computer (I do a lot of OpenGL stuff) and it all worked perfectly with the gdc compiler 👍
I've no idea what i just saw but this is very interesting. I am also intrigued by webgpu and it's capabilities. But don't know much about system programming languages or sharder programming or gpu programming. And I am still amazed by how you have inter op the Rust and Zig+C code. How is does that work? And also how can start doing cool shit like this? Where should I start can you give me a roadmap?
WebAssembly or Wasm is a binary format designed originally to run in browsers. You can compile various languages to it. But various Wasm engines exist outside browsers as well, like the one I'm using here. If you just want Rust calling Zig, you don't need it. You could compile either to a C-like library and use it from the other. Are you most interested in running code in a Wasm engine or most interested in just learning a systems language or most interested in interop?
0:50 WGPU is made by Mozilla? I thought it was created when rust gamedevs used gfx-rs as a graphics library, which wasn't low level enough, so they created gfx-hal, but then they created wgpu instead and not sure if gfx-hal still exists.
Digging in docs and contributors, Firefox uses it, but they still officially call it "independent", so formally, I think you're correct. The top contributor, Dzmitry Malyshau, used to work for Mozilla but seems to have left 1 1/2 years ago. 2nd has no Mozilla affiliation. 3rd/4th (depending on how you count) works for Mozilla. So, while Mozilla has/had some influence, I think you're right that I overstated this in the video.
Dzmitry also seems to have stopped working on the project, though I didn't compare dates carefully. The other two I mentioned seem to be the top contributors today.
Cool, I am also starting a web gpu project now. I just didn't understand why did you choose to run it outside of the browser. Isn't that the whole point of webgpu? From what I understood, with your approach you could write a single code that would work both on the browser and outside of it?
My idea is not to need the browser, yeah. Because browsers are big and bulky. This should have a lot lower overhead (and currently does if you notice the ram usage numbers in the video). But I hope to create an implementation for browser as well at some point. And the same wasm app file should just load in the client either way once that is done.
@@SimonMeskens So true, I'm at a company that maintains a desktop app using DirectX, but a third-party vendor provides their libraries in OpenGL. Having the two interface is a big pain. The third-party is now moving to WebGPU to help reduce the pain.
The C in here is just used as an interface-Dawn and wgpu are written in C++ and Rust, but each expose a C api, so that applications written in other languages can use them. Some languages make it easier to use that C api than others, tho.
It includes a wasm engine that compiles to native. Plus all the GPU stuff. But I think I tried some additional options including LTO (link time optimization), and it got several MB smaller. LTO is super slow, though, so not fun for dev time, just for releases.
I hope this doesn't make it out of draft; the last thing I need is a 3d site with million lines of code (rendering my old laptop useless) when I request a simple recipe site!
That is the thing i want the most. I want to see that recipe ray-traced on my screen. I want more from the future than pngs; the web we have now can not be the end of the line.
A triangle has 3 sides. Each one takes 13,000 lines of code to draw. The amount of code to draw stuff always seems daunting regardless of the tech stack chosen. Excellent vid!
Thanks! Helper libraries are useful for this, and presumably some already exist out there for webgpu.h (though I haven't gone looking much). I also plan to have easy mode apis just for taca to make direct coding much shorter and more fun and for smaller wasm binaries.
It doesnt take 13 000 × 2 lines of code to render 2 triangles, but somewhere in 13002 - 13006 range.
100 triangles - 13 010-13 100 lines of code, NOT 1 300 000.
99.9% of that is just setup, a little bit of abstraction goes a long way
The absolute state of modern native software development
🎉 nice stuff. Fascinating how you were able to glue that all together
i think it’s totally fine to inline the GLSL source code directly in the binary! seems to be a game dev tradition at this point. i really like the simplicity of it - shaders are (usually) simple and it makes ad-hoc metaprogramming of shaders easy, which imo is appropriate for shader code
This looks fun! If you ever get to making a launcher and customizable installer for this (think gog galaxy) I would totally throw my hat in the ring to make a gimicky arcade game for this platform
can't wait for flash games to comeback as webgpu games. Hopefully they get the API dead simple for people to make the applications they want
Webgpu is intended for more 3d intensive games we already have webgl and flash is so completely different that every flash game has to be rebuilt from scratch
Yeah I’ve read somewhere that the api won’t be simpler simply because it’s not intended to be used by “us” but I may be mixing things up with webgl
There is something like that
On Newgrounds they have wasm converters so Flash still works, but everyone pretty much moved to javascript and webGL or ports of their games in WASM. There's actually more choices for games than ever on the browser thanks to Flash emulation through wasm.
I've always aimed at 100 - 200 SLOC per file... so I find describing 1400 lines as "relatively large" kinda funny.
When playing the game of "our codebase is worse than your codebase" with colleagues, I often quote our 1000+ SLOC files as one of the "awful" things I have to contend with. :)
looks cool, cant wait to play with webgpu from grain.
Yeah, I really want to build demos for more languages, especially ones that are less like C.
Would it be easy to write bindings in Grain to match these header file definitions?
@@contextfree I havent looked over the header file's personaly but cant imagine it would be too hard. you could probably write wit bindings and generate them to some degree, as things get more complex.
Looked a little closer at this, you are going to have a slightly issue where grain doesnt let you export the function table but with a single line compiler change that can be fixed. the rest seems pretty straight forward the hard part is interoping between the higher level grain types and the lower level wasm types but its pretty easy.
I might play arround with it a bit more later and see if i can get anything useable.
Thanks for looking closer! And yeah, the function table export is pretty vital here. I was surprised how hard it was for me to find the right compiler switch to enable that in Zig. (Though the switch is fairly well named, it turns out.)
this looks interesting, great work!
I like that euphemism "Brrrr" 😊
Love the videos man, keep it up!
Nim also support WASM, waiting for it to get seamless
I'd love to get a Nim demo going for this for sure.
hey, just wanted to say that imo size doesnt really matter, like at all, for wasm, even if its web focused. Consider that, for desktops with fast network nothing matters its going to be fast af anyway and for slow mobile devices the consideration (compared to javascript) is parsing time not dl time - and wasm parsing is super fast. also, size optimized wasm usually runs slower, sometimes way slower, especially some of the rust tooling really deoptimizes your code. so, i'd suggest looking at other metrics than just code size. thanks for all the great content, hoping to maybe save you some frustration and time with the above info.
really cool, great work
0:40, Tomb Raider 2023, running straight from your web browser!
3:25, you don't need to attribute all values, since enum does it for you, increasing by 1 each of them. I just use the 1st value, since I don't trust this default (it already changed in the past), and some value which runs away from the sequence, like your bits mask.
Yeah, I felt like being explicit here, even though it increments by default. And I'm not sure I like the "Force32" thing. I was copying that idea from webgpu.h just to see how I felt about it.
In the demo I notice that the rotation seems to be janking a little bit here and there. Can't tell if that's from the way it's captured or if it's also happening live. Any idea what's causing it?
I'm afraid some of it is from the original, as it takes careful observation, but I'm afraid some of it might be. If so, I'm not sure what's causing it. I think the rendering calls I've borrowed from the tutorial are supposed to avoid that kind of thing. I'll have to do closer analysis sometime.
I checked, and I'm supposedly on auto vsync. I had some extra manual delays happening that might have been trouble. I removed that now, and it still seems occasionally a touch janky but maybe improved? Using 6% CPU, so that should be ok, at least.
CodyJasonBennett's shaderkit has a WGSL minifier.
Thanks much!
Looks Amazing 💥
4:06 - D has nice C interop but you can't just include C header files, you have to first compile the C code, then link it and write bindings for the functions you need. It's easier than it sounds but it still requires you to use a C compiler in your build process
There's the relatively new ImportC feature, which is still a work in progress. I'm not sure of the current state. Have you tried it out? I haven't, so I can't speak well to it. forum.dlang.org/thread/u2el6n$1tee$1@digitalmars.com
And I'm not sure the official docs are caught up with the latest status. It's unclear to me. dlang.org/spec/importc.html
I think many languages have ffi for linking with C.
@@contextfreeI had never used importC until you mentioned. That said importC only works with `.c` and `.i` files. That said you can easily make a wrapper c file like somelib.c that only contains:
`# include `
Then you run it with `dmd somelib.c` and at least on my testing (trying a small sdl + OpenGL application) it works fine.
That being said the documentation still lacks a lot of important details and on my tests it fails on complex C projects that use the pre-processor a lot (in DMD). But if you use the `gdc` compiler everything seems to work perfectly. I tested it with all the C projects in my computer (I do a lot of OpenGL stuff) and it all worked perfectly with the gdc compiler 👍
Which is unsurprising considering gdc is pretty much GCC for D
I've no idea what i just saw but this is very interesting. I am also intrigued by webgpu and it's capabilities. But don't know much about system programming languages or sharder programming or gpu programming. And I am still amazed by how you have inter op the Rust and Zig+C code. How is does that work? And also how can start doing cool shit like this? Where should I start can you give me a roadmap?
WebAssembly or Wasm is a binary format designed originally to run in browsers. You can compile various languages to it. But various Wasm engines exist outside browsers as well, like the one I'm using here. If you just want Rust calling Zig, you don't need it. You could compile either to a C-like library and use it from the other. Are you most interested in running code in a Wasm engine or most interested in just learning a systems language or most interested in interop?
latest and greatest
0:50 WGPU is made by Mozilla? I thought it was created when rust gamedevs used gfx-rs as a graphics library, which wasn't low level enough, so they created gfx-hal, but then they created wgpu instead and not sure if gfx-hal still exists.
Digging in docs and contributors, Firefox uses it, but they still officially call it "independent", so formally, I think you're correct. The top contributor, Dzmitry Malyshau, used to work for Mozilla but seems to have left 1 1/2 years ago. 2nd has no Mozilla affiliation. 3rd/4th (depending on how you count) works for Mozilla. So, while Mozilla has/had some influence, I think you're right that I overstated this in the video.
Dzmitry also seems to have stopped working on the project, though I didn't compare dates carefully. The other two I mentioned seem to be the top contributors today.
wow this is cool
Is it possible to use WebGPU without webpack and node.js stuff? Just pure WebGPU and browser?
Yes, that works, although I didn't do any browser nor js stuff here.
waiting for you to create video about ada programming language
Cool, I am also starting a web gpu project now. I just didn't understand why did you choose to run it outside of the browser. Isn't that the whole point of webgpu?
From what I understood, with your approach you could write a single code that would work both on the browser and outside of it?
My idea is not to need the browser, yeah. Because browsers are big and bulky. This should have a lot lower overhead (and currently does if you notice the ram usage numbers in the video). But I hope to create an implementation for browser as well at some point. And the same wasm app file should just load in the client either way once that is done.
@@contextfreebut why do you need WebGPU to run not on the web?
@@svenyboyyt2304 universal code, same reason why WebAssembly might actually become more popular outside the browser than in
@@SimonMeskens So true, I'm at a company that maintains a desktop app using DirectX, but a third-party vendor provides their libraries in OpenGL. Having the two interface is a big pain. The third-party is now moving to WebGPU to help reduce the pain.
why we needed C again? didn’t quite get that part
The C in here is just used as an interface-Dawn and wgpu are written in C++ and Rust, but each expose a C api, so that applications written in other languages can use them. Some languages make it easier to use that C api than others, tho.
"It takes alot of code to display something with webgpu" laugh in 1k lines vulkan triangle😂
When you say, "running *outside* a browser," don't you actually mean running in headless mode?
Well, I have a window, so it's not headless, but it's also not a web browser at all. It's a separate native app.
absence of mobile though is a deal breaker for me :(
Will there be blueberd video?
I'm not sure I've heard of it. Got a link?
Why am I watching this, I don't even know C or Rust damn..
But is the video fun still?
@@contextfree of course it is:)
23mb?
It includes a wasm engine that compiles to native. Plus all the GPU stuff. But I think I tried some additional options including LTO (link time optimization), and it got several MB smaller. LTO is super slow, though, so not fun for dev time, just for releases.
I hope this doesn't make it out of draft; the last thing I need is a 3d site with million lines of code (rendering my old laptop useless) when I request a simple recipe site!
Helper libraries make a huge difference. But I need to implement the things that helper libraries expect.
It's also a bit simpler from js.
That is the thing i want the most. I want to see that recipe ray-traced on my screen.
I want more from the future than pngs; the web we have now can not be the end of the line.