So I just went through and updated the gfx-rs big picture to help show the relationship between the various parts of the (gfx) ecosystem works. The original blog post describes each component, the main difference is that spirv-cross is no more and gfx-hal is now wgpu-hal.

It's less that wgsl doesn't covert well to spirv, more that spirv is a pain to parse. There's a bunch of requirements and it's weirdly low (yet high) level, so the frontend has a bunch of work to do to make sense of things.

I'm glad!

Glsl parsing is already supported, but there are quite a few issues with it (it's not been a focus, so we haven't been testing it). I didn't include it as it didn't make notable progress (though ofc some was made).

Yup! We've changed the names of a couple types and such, which is all documented in the changelog, but nothing fundamental changed.

No. We have a thing called "downlevel" features for WebGPU features that don't exist on older backends. You can check these features and determine what you can and can't use. If you can't use something, our validation should catch it before it hits the api and causes chaos

The PR is only a month old, and I don't want to make promises for other people's work, but I'd be highly surprised if it didn't merge within the next month or two, maybe sooner. The webgl backend that was talked about 2 years ago was for extending gfx-hal, which was going to be a lot of work. We're in a significantly better place with wgpu-hal, so especially with bevy needing it, I'm fully confident it's going to happen.

The PR is in progress, no idea when it will be merged, presumably when zicklag has time to finish it. I hear it works fine, just needs some bugs worked out.

Yeah he's a cutey!

Precisely why they can be little evil rapscallions

350mph may be the speed record, but it's very unsafe, so most revenue runs are done at 150-200mph max on most high speed systems.

Thank you!

We'd definitely love help implementing them, support on spirv-passthrough-only should be pretty simple just-feature-checking kinda work.

We don't currently have support for them, but as a shader only feature it should be pretty easy to add.

If you liked using gfx-hal, you should take a look at the new wgpu-hal which is the low level abstraction layer that wgpu is now built on.

Thank you for all the feedback and help you and your team have given us!

You can ofc use naga at compile time in a build script or equivalent, but all work wgpu does with it has to be at runtime. Not only do you not know which backend you're running on, we need to validate your shaders. that begin said, naga is performing really well, so you shouldn't have to worry about its performance too much.

So rust-gpu can output spirv, then you pass that spirv to wgpu, which naga can parse and convert to whatever backend language is needed.

wgpu isn't a viable option

curious what features you are missing that are show stoppers for you?

wgpu has access to proper compute shaders, so it should be able to serve most of your GPGPU needs! If you have things that wgpu isn't able to handle, we'd love to hear about it.

There are some c++ projects that are trying to make abstraction layers over the GPGPU apis, but they are to mixed success.

Yeah that's fair, I guess "voltage detector + relay" would work better.

They couldn't bother like... putting a diode in there?