Update to wgpu 0.17.0

[Aaron1011]

This required bumping wasm-bindgen to 0.2.87

[Chickenkeeper]

Would it be possible to remove the minor part of the version number, i.e. "0.17", to match most of the other dependencies? The minor versions are only used for non-breaking updates, which get missed unless egui can be updated every time wgpu does

[Mingun]

Cargo specification already means ^0.17.0, which is shorthand for >=0.17.0,<0.18.0

[Wumpf]

👍

[Wumpf]

This actually breaks the web build because of wgpu's Send/Sync changes. @Aaron1011 do you have time to look into that?

[Chickenkeeper]

Cargo specification already means ^0.17.0, which is shorthand for >=0.17.0,<0.18.0

Oh that's good to know, I was under the impression that it was equal to =0.17.0 instead. Thanks for the links, I'll read up on it properly

[Aaron1011]

This is tricky - the type_map::concurrent::TypeMap instance that egui exposes requires Send + Sync tpyes, which means that you can no longer store wgpu types in it on wasm.

I think our two options are:

• Use a non-concurrent TypeMap in the exposed field. This will complicate multithreaded non-wasm use cases, as references to that TypeMap Wil lno longer be able to be shared between threads.
• Provide two TypeMap instances - one non-concurrent, and one type_map::concurrent::TypeMap. This will require adding a parameter to some user closures, which might break lots of user code. However, it will provide more flexibility, and make it easier for users to write code targeting wasm.

[lucasmerlin]

I solved the typemap problem in my project by choosing the concurrent version based on the target_arch:

#[cfg(not(target_arch = "wasm32"))]
use type_map::concurrent::TypeMap;
#[cfg(target_arch = "wasm32")]
use type_map::TypeMap;

Maybe this would work for egui as well. Since most wasm code is single threaded anyways, I don't think it'd be necessary to have the concurrent typemap on wasm.

[Aaron1011]

@lucasmerlin: My concern is that doing that would make it unnecessarily difficult for downstream crates to compile against wasm - using TypeMap in a function/closure signature (e.g. for PrepareCallback) would require a similar #[cfg] in downstream crates.

[Wumpf]

Huh, tricky. Agreed that the "infectious" cfg isn't great either.
Tbh I'm quite unhappy with the interface having this typemap in there in the first place. Maybe we should bite the bullet and come up with something different 🤔
Need to update wgpu over on https://github.com/rerun-io/rerun/ soon as well, so I might be spending some time on this as well in the next couple of days, but I'd be very happy for more input.
Pondering if we should go with the stop-gap-solution of enabling fragile-send-sync-non-atomic-wasm for the time being (should then ofc referencing new bug ticket explaining the situation)

[Aaron1011]

I believe that gfx-rs/wgpu#3626 will unblock some lifetime constraint relaxtions (see gfx-rs/wgpu#1453). This might remove the need for egui to provide a TypeMap at all.

[Wumpf]

That might very well be, but gfx-rs/wgpu#3626 has been in the works for very long and may not land all that soon. Also will definitely be a major release of wgpu, not a patch; so we're still stack with pre-arcanization.
Also depends a bit how the typemap is used there in the first place, that design is not that tied to lifetime issues I'd argue

[Speak2Erase]

While getting rid of the typemap is nice, even after gfx-rs/wgpu#3626 lands it could take a while for them to fix gfx-rs/wgpu#1453

I'm really hoping that comes sooner rather than later though. The typemap setup is very annoying to work with when doing custom rendering.

[cwfitzgerald]

If everything goes to plan, expect to see both changes in 0.18. No hard promises though.

[fornwall]

As said above, perhaps features = ["fragile-send-sync-non-atomic-wasm"] is the best way forward to unblock the update for now?

We are no worse off than with wgpu 0.16.0, and a proper fix can hopefully be included in a future wgpu 0.18.0/0.19.0 update.

[emilk]

Sounds good to me @fornwall

[fornwall]

@Aaron1011 Is setting features = ["fragile-send-sync-non-atomic-wasm"] in this PR something you have time to do?

[emilk]

Tested natively on Mac, as well as on Web.

[Aaron1011]

Sorry for the delay in getting to this - thank you for taking care of this!

[daxpedda]

As said above, perhaps features = ["fragile-send-sync-non-atomic-wasm"] is the best way forward to unblock the update for now?

We are no worse off than with wgpu 0.16.0, and a proper fix can hopefully be included in a future wgpu 0.18.0/0.19.0 update.

FWIW egui used to work fine with Wasm Atomics, after this PR it won't compile with it.

In any case, great work here!