21–30 of 57 posts
Earlier quoted context omitted.
wgpu is a nice implementation of webgpu for native rust applications on desktop.
I don't see a point of that versus middleware engines, with much better tooling. WebGPU/WebGL are like JavaScript, something that we have to put up with, because on the browser there is no other alternative. No need to constrain ourselves to the browser limitations when there are other options.
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 - fr…
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,…
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 - fr…
WebGPU main pain point is forcing everyone to rewrite their shaders, no wonder most Web native game engines are going the shading language abstraction route, when only Chrome does WebGPU on desktop, and it isn't even an option on mobile years to come. Thus cross API WebGL / WebGPU shading middleware is needed.
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 - fr…
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,…
Earlier quoted context omitted.
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,…
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.
Earlier quoted context omitted.
I don't see a point of that versus middleware engines, with much better tooling. WebGPU/WebGL are like JavaScript, something that we have to put up with, because on the browser there is no other alternative. No need to constrain ourselves to the browser limitations when there are other options.
A single code base for both native & web? Not having to write Javascript on the web?
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.
For example: fleetwood.dev has a really cool project that does audio transcription in browser on the GPU: https://whisper-turbo.com/#
I like https://github.com/evanw/lightgl.js learnt from 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.
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.
Earlier quoted context omitted.
wgpu is a nice implementation of webgpu for native rust applications on desktop.
I don't see a point of that versus middleware engines, with much better tooling. WebGPU/WebGL are like JavaScript, something that we have to put up with, because on the browser there is no other alternative. No need to constrain ourselves to the browser limitations when there are other options.