Wgpu-rs: What is the current level of API stability (roughly)?

[chinedufn]

Hey!

At this point in wgpu-rs's development, how much API churn is expected going forwards?

This is a bit of a general question, but really any answer will help me with making a decision on whether to start laying the foundation for using wgpu-rs in my web application (it's not an issue for my use case that browsers don't support it yet.), or if I should wait some time and check back later.

To ask more simply.

Is it likely that the entire API will churn to significantly going forwards, or are things already ~80%+ "stable"?

I know .. it's a very vague question .. But really any answer helps since right now I have almost no sense of this.

Cheers!

[kvark]

Oh hi @chinedufn !

I believe the upstream has mostly resolved all the major architectural questions:

• [x] synchronization (implicit)
• [x] passes (compute and render)
• [ ] error model (resolved in upstream on the Web, but still figuring out the wgpu-rs side, also see https://github.com/gfx-rs/wgpu/issues/638)
• [x] data transfers (write_buffer, write_texture, and explicit promise-based mapping with sub-ranges)
• [ ] shading language (WGSL is accepted but still being specified in early stages, Naga support is WIP)

It's not clear if we'll have API changes for the error model. The current idea (that I'm pursuing) is to have the native code just panicking on invalid use at wgpu-rs level (while at wgpu level we return proper Result). On the Web, we'd get the error scopes and delayed errors, like written in the spec, without affecting the API.

The only major change left is the shading language, which, again, doesn't necessarily affect us since we can keep using SPIR-V for as long as we want or need.

So all in all, I'd say we are either on 80% mark or past it with regards to API changes. There is still going to be some non-semantical refactor of the API, but updating it should be mostly mechanical. Please consider joining "#wgpu:matrix.org" to chat about this with us!

[chinedufn]

Yo yo!

THIS WAS EXACTLY WHAT I NEEDED THANK YOU.

Awesome. I'll definitely consider joining that channel (oddly enough I've haven't used IRC before but the thought of a place with a bunch of graphics devs to chat with sounds very very juicy)

Cool. This is way passed the point where I'd have any concerns. I don't mind some API-changes-refactoring, I was just concerned about needing to do multiple huge-massive-difficult refactors.

I read somewhere that browsers won't retire the spirv support until naga and tint etc are working... So no concerns there either.

Sweet. This answers all of my questions.

Thanks as always!!

[kvark]

oddly enough I've haven't used IRC before but the thought of a place with a bunch of graphics devs to chat with sounds very very juicy

Note that we are on Matrix, not IRC :)

I also forgot to mention the multi-queue support, which has been hanging in the air (within the design space) with nothing concrete yet, and may very well be moved to after MVP.

I read somewhere that browsers won't retire the spirv support until naga and tint etc are working...

That's right. We can't retire SPIRV until WGSL tools are working. We are getting close to this point though.