10 ms·

Show HN: Shadeup – A language that makes WebGPU easier

179 points by jrmydev 3y ago

keeganpoppen 3y ago
this is impressively well designed, as someone who dabbled in this kind of thing many moons ago. hats off to you.
- jrmydev 3y ago
  Thank you! That means a lot
MattRix 3y ago
Not sure if this page is rendering only via WebGPU or something, but on iOS this is just a blank page.
- jrmydev 3y ago
  Yeah, unfortunately, the main background is running webgpu so edge/chrome/opera desktop are the only browsers that can see it. Here's a screenshot of what it should look like: https://i.imgur.com/CBHaftp.jpg https://i.imgur.com/CBHaftp.jpg
  - paranoidxprod 3y ago
    I just checked on Linux Firefox and iOS Firefox and both loaded the background without issues.
    - jrmydev 3y ago
      Hmm, that's probably the static picture fallback you're seeing. Here's a video of what the particles look like when moving if interested: https://www.loom.com/share/c2608492dce44ab4b84b8fe4c68c44cd?sid=b7ca32b9-67dc-462b-8898-3f6870fa464c https://www.loom.com/share/c2608492dce44ab4b84b8fe4c68c44cd?...
      - paranoidxprod 3y ago
        That was exactly it, and the video of it looks awesome!
hyperthesis 3y ago
I like https://github.com/evanw/lightgl.js https://github.com/evanw/lightgl.js learnt from https://jamie-wong.com/2016/08/05/webgl-fluid-simulation/#implementation https://jamie-wong.com/2016/08/05/webgl-fluid-simulation/#im... the elegant lightgl.js, which is an abstraction layer on top of WebGL that makes it much nicer to work with. Unlike THREE.js, it doesn’t make any assumptions about you wanting any concept of a camera or lighting or that you’re working in 3D at all.
- zamadatix 3y ago
  Key highlight for anyone unfamiliar with web graphics technologies reading this comment and interested in trying one out themselves: as mentioned above, lightgl only abstracts WebGL and this is different than the more flexible WebGPU Shadeup abstracts. One example of the difference is the fluid sim example in lightgl/WebGL has to be written as pixel based shaders (meant to do operations on pixels in textures) while Shadeup/WebGPU let you do this as a pure general purpose compute shader (more like a generic bit of code that happens to run on a GPU). This is both much more flexible in terms of what you can do as well as much more efficient/scalable in execution.
stanleykm 3y ago
This is really cool. As far as boilerplate goes WebGPU is really not that bad (one just needs to look at Vulkan to see how fun it can get) but really anything to lower the barrier to entry is nice. I am curious about the API overhead here. For example if I run two separate passes using bare WebGPU I could use a single command encoder. Would two function calls here result in two command encoders? Another question - from the example code this doesnt look asynchronous, does it wait for everything to finish before returning? I could also be misreading the code I dont know typescript very well.
- jrmydev 3y ago
  Thanks, and great question: Shadeup will try to fit it all into one command encoder but may need to split if the coder: 1. Manually flushes 2. Reads/downloads a buffer on the CPU Most calls are lazily evaluated, and a small dep graph is built as you reference/draw things. That being said, shadeup does make some perf sacrifices in the name of simplicity. I'd say it's well suited to prototyping and learning. Of course, once you have a working prototype of something porting it to native wgsl should be easy
  - stanleykm 3y ago
    Oh nice thanks for the explanation.
  - burntcaramel 3y ago
    Have you thought about having an "eject" command? For example, Create React App had an eject command to go from the self-contained version to a full customisable Webpack app.
    - jrmydev 3y ago
      Users can already kinda do this by showing the compiled output, but the js engine itself is still tucked away. At some point, I would probably have a tree shaken full output for each shadeup.
- pjmlp 3y ago
zamadatix 3y ago
The particles effect on this page is a great example of "old web" feel in a page with "new web" looks in that it's just so fun and impractical solely because it can be. The "browse" button towards the bottom has a few editable examples as well, including one for the effect seen on the main page https://shadeup.dev/zv5twftezv2y https://shadeup.dev/zv5twftezv2y
TheRoque 3y ago
Shadeup is also pretty useful for unreal engine. Use of compute shaders is very cryptic in UE5, and shadeup makes it more accessible.
- astlouis44 3y ago
  My team has built out a WebGPU backend for Unreal Engine 5, for anyone interested!
Cieric 3y ago
This is interesting, I'm working on something similar but I'm starting from an existing gpu language and working my way backwards to add more support and allow for efficient cpu side execution. It's more geared as a game engine language to support both the game script (allowing easy parallelization) and the rendering side of things (as it's already a gpu language). Mine is currently more geared towards vulkan though. Looking through the examples on your website does give me some ideas though, I might try and adopt some of them myself.
- jrmydev 3y ago
  Your project sounds interesting as well. Do you have a social channel or GitHub for this project? Or is there something I can follow to be updated when you release it? I'd love to learn more about what you're working on as I've been wanting to integrate shadeup with existing game engines like unreal/unity but realizing it would be a massive undertaking.
  - astlouis44 3y ago
    My startup has been working on WebGPU support for Unreal Engine 5 for the past several years, and we've already achieved multiple demos that will be going live relatively soon.
    - jrmydev 3y ago
      Drop a link! I'd be interested to check it out
  - Cieric 3y ago
    I will warn that it's mostly been rewritten at this point, but most changes haven't made it to the repo due to being held up by my current employer's legal team. Most of the code is also poorly written due to it mostly being written during half asleep/burned out state. With all the "don't judge me to hard"'s out of the way, https://gitlab.com/Cieric/gellang https://gitlab.com/Cieric/gellang I don't currently have plans to integrate with an existing game engine, just my own. I have however considered in the past integrating with Godot, so that would be my first target if I do ever attempt it. I also was assuming no one would use my project professionally so the idea was to be a superset of glsl so any glsl code could be pasted into a script and be compiled without any modifications. That would aid in debugging gpu code in an actual debugger without needing to rewrite it. Once all the paper work is finished additional updates should start rolling out again since it would just be reviewing the new changes not everything again. Hope your expectations are in line, I'm not trying to under or over sell my project. I was just wanted to fix my own gripes with the projects of the time.
matmulbro 3y ago
webgpu hype is pretty cringe,even if you want to run in a browser (and most customers don’t) most game engines can still bake WebAssembly/WebGPU packages.
- jrmydev 3y ago
  I think the main feature that's exciting for me is the gpgpu potential. Even just looking at the ability to accelerate llms in the browser on any device without an installation is awesome For example: fleetwood.dev has a really cool project that does audio transcription in browser on the GPU: https://whisper-turbo.com/# https://whisper-turbo.com/#
  - pjmlp 3y ago
    We could have had that already in WebGL if it wasn't for Chrome team botching Intel's work on OpenGL ES compute shaders being available in WebGL. https://registry.khronos.org/webgl/specs/latest/2.0-compute/ https://registry.khronos.org/webgl/specs/latest/2.0-compute/ https://github.com/9ballsyndrome/WebGL_Compute_shader/issues/9 https://github.com/9ballsyndrome/WebGL_Compute_shader/issues...
    - lmeyerov 3y ago
      Hah that was me ~12 years ago trying to get WebCL (OpenCL) through the same gate keepers. Meanwhile, in Python, we are doing multi-node multi-GPU. Maybe OpenAI's and soon Apple's success with LLMs will change the economics for them.
      - pjmlp 3y ago
        Much appreciated for the efforts. This is why I don't like Khronos APIs, even when actually those are the ones I know relatively well, the way they work end up being a much worse experience than writting backend specific plugins ourselves with much better tooling, also the extension spaghetti ultimately doesn't save us from multiple code paths anyway, given the differences between some of those extensions. To pick your example, something like PyTorch ends up being a much better developer experience, similar to game engines, than relying on Khronos APIs.
tppiotrowski 3y ago
Very cool project. I learned WebGL three years ago but before I dove into the underlying concepts I used GPU.js [1] to quickly prototype my project. Eventually, the abstraction prevented necessary performance optimizations so I switched to vanilla GLSL and these vanilla GLSL "shaders" were initially ejected from GPU.js. Writing JS code then looking at the generated WebGPU output is a great way to get familiar with WebGPU. Thanks for this. [1] https://github.com/gpujs/gpu.js/ https://github.com/gpujs/gpu.js/

179 points by jrmydev 3y ago

keeganpoppen 3y ago

this is impressively well designed, as someone who dabbled in this kind of thing many moons ago. hats off to you.

jrmydev 3y ago
Thank you! That means a lot

MattRix 3y ago

Not sure if this page is rendering only via WebGPU or something, but on iOS this is just a blank page.

jrmydev 3y ago
Yeah, unfortunately, the main background is running webgpu so edge/chrome/opera desktop are the only browsers that can see it. Here's a screenshot of what it should look like: https://i.imgur.com/CBHaftp.jpg https://i.imgur.com/CBHaftp.jpg
- paranoidxprod 3y ago
  I just checked on Linux Firefox and iOS Firefox and both loaded the background without issues.
  - jrmydev 3y ago
    Hmm, that's probably the static picture fallback you're seeing. Here's a video of what the particles look like when moving if interested: https://www.loom.com/share/c2608492dce44ab4b84b8fe4c68c44cd?sid=b7ca32b9-67dc-462b-8898-3f6870fa464c https://www.loom.com/share/c2608492dce44ab4b84b8fe4c68c44cd?...
    - paranoidxprod 3y ago
      That was exactly it, and the video of it looks awesome!

hyperthesis 3y ago

I like https://github.com/evanw/lightgl.js https://github.com/evanw/lightgl.js learnt from https://jamie-wong.com/2016/08/05/webgl-fluid-simulation/#implementation https://jamie-wong.com/2016/08/05/webgl-fluid-simulation/#im... the elegant lightgl.js, which is an abstraction layer on top of WebGL that makes it much nicer to work with. Unlike THREE.js, it doesn’t make any assumptions about you wanting any concept of a camera or lighting or that you’re working in 3D at all.

zamadatix 3y ago
Key highlight for anyone unfamiliar with web graphics technologies reading this comment and interested in trying one out themselves: as mentioned above, lightgl only abstracts WebGL and this is different than the more flexible WebGPU Shadeup abstracts. One example of the difference is the fluid sim example in lightgl/WebGL has to be written as pixel based shaders (meant to do operations on pixels in textures) while Shadeup/WebGPU let you do this as a pure general purpose compute shader (more like a generic bit of code that happens to run on a GPU). This is both much more flexible in terms of what you can do as well as much more efficient/scalable in execution.

stanleykm 3y ago

This is really cool. As far as boilerplate goes WebGPU is really not that bad (one just needs to look at Vulkan to see how fun it can get) but really anything to lower the barrier to entry is nice. I am curious about the API overhead here. For example if I run two separate passes using bare WebGPU I could use a single command encoder. Would two function calls here result in two command encoders? Another question - from the example code this doesnt look asynchronous, does it wait for everything to finish before returning? I could also be misreading the code I dont know typescript very well.

jrmydev 3y ago
Thanks, and great question: Shadeup will try to fit it all into one command encoder but may need to split if the coder: 1. Manually flushes 2. Reads/downloads a buffer on the CPU Most calls are lazily evaluated, and a small dep graph is built as you reference/draw things. That being said, shadeup does make some perf sacrifices in the name of simplicity. I'd say it's well suited to prototyping and learning. Of course, once you have a working prototype of something porting it to native wgsl should be easy
- stanleykm 3y ago
  Oh nice thanks for the explanation.
- burntcaramel 3y ago
  Have you thought about having an "eject" command? For example, Create React App had an eject command to go from the self-contained version to a full customisable Webpack app.
  - jrmydev 3y ago
    Users can already kinda do this by showing the compiled output, but the js engine itself is still tucked away. At some point, I would probably have a tree shaken full output for each shadeup.
pjmlp 3y ago

zamadatix 3y ago

The particles effect on this page is a great example of "old web" feel in a page with "new web" looks in that it's just so fun and impractical solely because it can be. The "browse" button towards the bottom has a few editable examples as well, including one for the effect seen on the main page https://shadeup.dev/zv5twftezv2y https://shadeup.dev/zv5twftezv2y

TheRoque 3y ago

Shadeup is also pretty useful for unreal engine. Use of compute shaders is very cryptic in UE5, and shadeup makes it more accessible.

astlouis44 3y ago
My team has built out a WebGPU backend for Unreal Engine 5, for anyone interested!

Cieric 3y ago

This is interesting, I'm working on something similar but I'm starting from an existing gpu language and working my way backwards to add more support and allow for efficient cpu side execution. It's more geared as a game engine language to support both the game script (allowing easy parallelization) and the rendering side of things (as it's already a gpu language). Mine is currently more geared towards vulkan though. Looking through the examples on your website does give me some ideas though, I might try and adopt some of them myself.

jrmydev 3y ago
Your project sounds interesting as well. Do you have a social channel or GitHub for this project? Or is there something I can follow to be updated when you release it? I'd love to learn more about what you're working on as I've been wanting to integrate shadeup with existing game engines like unreal/unity but realizing it would be a massive undertaking.
- astlouis44 3y ago
  My startup has been working on WebGPU support for Unreal Engine 5 for the past several years, and we've already achieved multiple demos that will be going live relatively soon.
  - jrmydev 3y ago
    Drop a link! I'd be interested to check it out
- Cieric 3y ago
  I will warn that it's mostly been rewritten at this point, but most changes haven't made it to the repo due to being held up by my current employer's legal team. Most of the code is also poorly written due to it mostly being written during half asleep/burned out state. With all the "don't judge me to hard"'s out of the way, https://gitlab.com/Cieric/gellang https://gitlab.com/Cieric/gellang I don't currently have plans to integrate with an existing game engine, just my own. I have however considered in the past integrating with Godot, so that would be my first target if I do ever attempt it. I also was assuming no one would use my project professionally so the idea was to be a superset of glsl so any glsl code could be pasted into a script and be compiled without any modifications. That would aid in debugging gpu code in an actual debugger without needing to rewrite it. Once all the paper work is finished additional updates should start rolling out again since it would just be reviewing the new changes not everything again. Hope your expectations are in line, I'm not trying to under or over sell my project. I was just wanted to fix my own gripes with the projects of the time.

matmulbro 3y ago

webgpu hype is pretty cringe,even if you want to run in a browser (and most customers don’t) most game engines can still bake WebAssembly/WebGPU packages.

jrmydev 3y ago
I think the main feature that's exciting for me is the gpgpu potential. Even just looking at the ability to accelerate llms in the browser on any device without an installation is awesome For example: fleetwood.dev has a really cool project that does audio transcription in browser on the GPU: https://whisper-turbo.com/# https://whisper-turbo.com/#
- pjmlp 3y ago
  We could have had that already in WebGL if it wasn't for Chrome team botching Intel's work on OpenGL ES compute shaders being available in WebGL. https://registry.khronos.org/webgl/specs/latest/2.0-compute/ https://registry.khronos.org/webgl/specs/latest/2.0-compute/ https://github.com/9ballsyndrome/WebGL_Compute_shader/issues/9 https://github.com/9ballsyndrome/WebGL_Compute_shader/issues...
  - lmeyerov 3y ago
    Hah that was me ~12 years ago trying to get WebCL (OpenCL) through the same gate keepers. Meanwhile, in Python, we are doing multi-node multi-GPU. Maybe OpenAI's and soon Apple's success with LLMs will change the economics for them.
    - pjmlp 3y ago
      Much appreciated for the efforts. This is why I don't like Khronos APIs, even when actually those are the ones I know relatively well, the way they work end up being a much worse experience than writting backend specific plugins ourselves with much better tooling, also the extension spaghetti ultimately doesn't save us from multiple code paths anyway, given the differences between some of those extensions. To pick your example, something like PyTorch ends up being a much better developer experience, similar to game engines, than relying on Khronos APIs.

tppiotrowski 3y ago

Very cool project. I learned WebGL three years ago but before I dove into the underlying concepts I used GPU.js [1] to quickly prototype my project. Eventually, the abstraction prevented necessary performance optimizations so I switched to vanilla GLSL and these vanilla GLSL "shaders" were initially ejected from GPU.js. Writing JS code then looking at the generated WebGPU output is a great way to get familiar with WebGPU. Thanks for this. [1] https://github.com/gpujs/gpu.js/ https://github.com/gpujs/gpu.js/