4 ms·

I've maintained a small WebGPU project for a little while, and haven't had to utilize any solutions like Use.GPU. I'm not here to express an opinion about it, b

I've maintained a small WebGPU project for a little while, and haven't had to utilize any solutions like Use.GPU. I'm not here to express an opinion about it, but if you like using WebGL without adding large dependencies to your projects, you can leverage WebGPU the same way, with one important caveat: the packing of structured data into bindings. In short, if you have a JavaScript object of named values you want to pass into a WGSL shader that has a corresponding binding, you have some homework to do. So I wrote a tiny (work in progress) utility to do it for you. Just like gl-matrix ( https://glmatrix.net https://glmatrix.net ) is a tiny library that trivializes geometric transforms for small projects, gpu-buffer ( https://github.com/Rezmason/matrix/blob/master/lib/gpu-buffer.js https://github.com/Rezmason/matrix/blob/master/lib/gpu-buffe... ) trivializes passing data into WGSL shaders. You hand it a shader, and it'll return a set of objects that'll transform your JS objects into buffers to then bind.

unconed 4y ago
Note that what Use.GPU does is much more polymorphic than that. It uses getters inside shaders to allow e.g. attributes like point color and size to be either uniform or per vertex, without having to change the shader source. It will also autogenerate bind groups and descriptors, including optimized support for volatile bindings that e.g. change every frame (like a front/back buffer). This is necessary if you want to make composable shaders which can adapt to a variety of use cases.
- rezmason 4y ago
  Thanks for making this, by the way. I think the design of standard APIs will increasingly cater to engine developers and folks willing to pore over specs, and the folks running smaller scale operations will have a harder time leveraging new things without considerable personal investment— unless folks implement higher level wrapper libraries, that is. I personally disagree with you on a bunch of things— this is the Internet after all— but you've been undoubtedly empowering graphics programmers for years, and I appreciate you.
  - unconed 4y ago
    Maybe one day you'll realize that being disagreeable on the internet is another service I've been freely providing for public benefit, with very little thanks and at great personal cost.

unconed 4y ago

Note that what Use.GPU does is much more polymorphic than that. It uses getters inside shaders to allow e.g. attributes like point color and size to be either uniform or per vertex, without having to change the shader source. It will also autogenerate bind groups and descriptors, including optimized support for volatile bindings that e.g. change every frame (like a front/back buffer). This is necessary if you want to make composable shaders which can adapt to a variety of use cases.

rezmason 4y ago
Thanks for making this, by the way. I think the design of standard APIs will increasingly cater to engine developers and folks willing to pore over specs, and the folks running smaller scale operations will have a harder time leveraging new things without considerable personal investment— unless folks implement higher level wrapper libraries, that is. I personally disagree with you on a bunch of things— this is the Internet after all— but you've been undoubtedly empowering graphics programmers for years, and I appreciate you.
- unconed 4y ago
  Maybe one day you'll realize that being disagreeable on the internet is another service I've been freely providing for public benefit, with very little thanks and at great personal cost.