wgpu-rs VS gpuweb

You could start with one of examples from wgpu and tinker with it to see if that's your thing. Ie. copy hello-triangle and add more triangles / make them move, etc.

wgpu-rs (https://github.com/gfx-rs/wgpu-rs) is probably closer to what you're looking for, it's a "high level wrapper" over wgpu-core (Which implements "WebGPU", an upcoming browser API for graphics using gfx-rs, and AIUI "implements" means this is what a browser might use to actually call a graphics API when javascript uses webGPU, although if you're compiling for wasm it could just call the browser APIs). It can run natively, ignore the fact it has "Web" in the name

rust-gpu) is used for compiling a compute shader written in Rust to SPIR-V. wgpu-rs is used natively for running the GPU computation.

For web assembly there is the unofficial bevy_webgl2 plugin. Official bevy web assembly support would probably use the wgpu webgl backend, which still needs some work, and is currently untested in bevy.

We let wgpu https://github.com/gfx-rs/wgpu-rs handle our graphics backend abstraction, so our OpenGL support will come whenever they implement and release it. Currently, it seems to be a WIP.

It's the same thing, the Rust implementation is just called[wgpu](https://wgpu.rs/)

Same as with GLSL, isn't it? What we do in wgpu-rs examples, and that's something I expect to see more widely, is having an integration test that just parses all the WGSL in the project and reports errors. Ideally though, we'd have a set of IDE plugins to do the parsing and report errors right where you type the code. We'd appreciate any help to get these started!

Also you could use an existing cross-platform graphics library, e.g. wgpu-rs. It supports Vulkan, Metal, DirectX, OpenGL and WebGPU. Oh and it seems to allow switching backends at compile-time via the WGPU_BACKEND environment variable, so maybe check out how they're doing it.

https://github.com/gpuweb/gpuweb/issues/380

> Would you like to render high quality lines or points? Sorry, it's not been a priority to make that simple. Better go study up on SDFs and beziers.

I realize lines and font rendering are an insanely complex fields, and that OpenGL offering at least lines and Vulkan not sure feels like a slap in the face. The work being done by groups like https://linebender.org/ is intense. Overall though that intensity makes me question the logic of trying to include it, wonders whether fighting to specify something that clearly we don't have full mastery over makes sense: even the very best folks are still improving the craft. We could specify an API without specifying an exact implementation, without conformance tests, perhaps, but that feels like a different risk. Maybe having to reach for a library that does the work reflects where we are, causes the iteration & development we sort of need?

> actually producing a lit, shaded and occlusioned image with PBR, indirect lighting, antialiasing and postfx

I admit to envying the ambition to make this simple, to have such a great deep knowledge as Steve and to think such hard things possible.

I see your point, but one issue is that you can't go from HLSL or GLSL to WGSL for compute work, as the way atomics are typed is incompatible[1]. That's a primary reason we (currently) use WGSL, because going from that to legacy shader languages does work. But then you have all the limitations of WGSL.

Slang had to make a change to its type system[2] to make this work. But they did it, and as a result Slang is appealing as an "apex" language - you can translate from that to anything, and also get advanced features lacking in WebGPU.

[1]: https://github.com/gpuweb/gpuweb/issues/2377

[2]: https://github.com/shader-slang/slang/issues/5084

I am referring primarily to the fact that a restricted subset of WebGPU is needed ('compatibility mode') for D3D11 / GLES era hardware[0]

[0] https://github.com/gpuweb/gpuweb/issues/4266

Dev tools gave me this link: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#...

Looks like I'll skip this one.

> It would be great if you could find that Unity/Adobe discussion as I would be interested to read it.

https://github.com/gpuweb/gpuweb/wiki/Minutes-2019-09-24

Corentin: Web Shading Language — A high-level shading language made by Apple for WebGPU.

[...]

Jesse B (Unity): We care about HLSL

Eric B (Adobe): Creating a new high level language is a cardinal sin. Don’t. Do. That. Don’t want to rewrite all my shaders AGAIN.

See https://news.ycombinator.com/item?id=40952182#40957959

It's early but my current since WGSL -> SPIRV is fairly shallow mapping you should be able to get close modulo extensions. Extensions can be important though, in particular I'm tracking this closely:

https://github.com/gpuweb/gpuweb/issues/4195

One subgoal of gpu.cpp is to be able to have a canvas to experiment and see how far we can push the limits.

On Chrome for Linux you'll need

> The chrome://flags/#enable-unsafe-webgpu flag must be enabled (not enable-webgpu-developer-features). Linux experimental support also requires launching the browser with --enable-features=Vulkan.

Nightly Firefox should have it already.

https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#...