31–40 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.
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.
I dunno, writing GPU code that works across Mac/Win/Lin/iOS/droid isn’t easy to deploy.
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.
Don’t be fooled by “web” in the name. Just like WebAssembly is/will be a better JVM, WebGPU is already posed to be a better OpenGL/Vulkan. It is a full graphics API unconstrained by browser implementations, and available without a browser runtime.
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?
Earlier quoted context omitted.
A single code base for both native & web? Not having to write Javascript on the web?
Exactly this, along with a lot of the "smoothing-out" done by the webgpu spec which provides a clear and open abstraction target.
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.
Safari Technology Preview finally turned it on again. Of course when Apple will ship it on Mac and/or iOS is unknown but at least they showed some progress after hiding for 6 or more months
Firefox is doing their best to ship ASAP.
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.
Don’t be fooled by “web” in the name. Just like WebAssembly is/will be a better JVM, WebGPU is already posed to be a better OpenGL/Vulkan. It is a full graphics API unconstrained by browser implementations, and available without a browser runtime.
Earlier quoted context omitted.
Don’t be fooled by “web” in the name. Just like WebAssembly is/will be a better JVM, WebGPU is already posed to be a better OpenGL/Vulkan. It is a full graphics API unconstrained by browser implementations, and available without a browser runtime.
I am curious, in what ways is WebGPU better than Vulkan or Metal? From my point of view, WebGPU going back to an interpreted shading language like OpenGL makes it conceptually closer to JavaScript than WebAssembly.
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.
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://registry.khronos.org/webgl/specs/latest/2.0-compute/
https://github.com/9ballsyndrome/WebGL_Compute_shader/issues...
Earlier quoted context omitted.
Don’t be fooled by “web” in the name. Just like WebAssembly is/will be a better JVM, WebGPU is already posed to be a better OpenGL/Vulkan. It is a full graphics API unconstrained by browser implementations, and available without a browser runtime.
I am curious, in what ways is WebGPU better than Vulkan or Metal? From my point of view, WebGPU going back to an interpreted shading language like OpenGL makes it conceptually closer to JavaScript than WebAssembly.