Switch WgpuWrapper to a macro and have it compute Send/Sync eagerly

[SkiFire13]

Objective

• Improve compile times in bevy_render
• Help with bevy_render 0.19.1 doesn't compile on current Rust nightly due to -Znext-solver enabled by default #25511

Solution

While investigating a wgpu trait overflow issue with the new solver I noticed that eagerly computing its Send/Sync reduces the compile time of bevy_render by around 10 seconds (on my machine debug goes from 20s to 9s and release from 26s to 15s).

I don't like too much having to expose all these types though, and we might get the same perf benefits if gfx-rs/wgpu#9953 is merged though (edit: I tested with that PR changes and that alone reduces compile times by ~6 seconds, however when this PR is added it reduces another ~4 seconds).

I also ended up removing the Arcs used in some of the wgpu wrapper types, as all wgpu types now use Arcs under the hood or equivalent.

[laundmo]

Honestly i think thw 4 seconds are worth it, and it doesn't seem like many of the types are public if any at all?

[SkiFire13]

and it doesn't seem like many of the types are public if any at all?

WgpuQueue, WgpuAdapter, WgpuInstance, WgpuAdapterInfo and WgpuErrorSource are public.

Note that previously WgpuWrapper was public as well.

[laundmo]

It seems only bevy_pbr needs one of them as public, and for a usecase that i think could easily be changed to not need access to the wgpu wrapper type.

tho i haven't looked how much WgpuWrapper is used across the ecosystem. Kinda wish it was easily possible to search all of crates.io (not just all of github)

[futile]

Could this also be added to a (potential) 0.19.2 release? :> Currently the forward compat warning is printed on every build, even on a no-op build. It can be worked around by manually setting the recursion limit to something higher, but every downstream crate needs to repeat that. It's also possible to allow or expect the warning, but that's not the nicest either.

Upside is, it only applies to recent nightly rustc versions, so not everyone should run into this. I would expect it to become more common over time though, as more people upgrade their nightly versions.

So if a 0.19.2 gets released, it would be great to have this, and/or the related wgpu-fix in that release.

[laundmo]

IIRC this is a compile-time optimization discovered while attempting to solve the overflow, but doesn't actually fully solve it. That would mean backporting it would be nice for compile times but not get rid of the warning.

[laundmo]

This seems to conclusively solve

• next solver on bevy render crate uses 7.3x more peak memory then without next solver rust-lang/rust#161748

According to Heaptrack (which i was messing around with trying to understand why) this PR manages to cut the memory needed to compile just bevy_render from 14GB to 1.4GB.

I haven't tested this with just the wgpu PR, but if memory is at all correlated to runtime then its likely this is still way worth it.

The heaptrack files, for those curious: https://share.yadamiel.com/bevy_benchmarks/wgpu-eager-send-sync/
you can view them with heaptrack --analyze <file>

[stuartparmenter]

Seems reasonable to me and can't think of any obvious reasons why one would need it externally. The only hit I found in my dependencies was a test in Hanabi where it is mocking a RenderQueue.

Probably worth a migration guide or note somewhere though

[tychedelia]

I think this is fine? Although it's definitely ugly. Not blowing up the compiler is probably a worthwhile fix no matter the cost.

[SkiFire13]

I changed the way RenderQueue, RenderAdapter, RenderInstance and RenderAdapterInfo are defined, making them the wgpu wrappers themselves and thus avoiding having to create and export other wgpu wrappers.

Moreover I removed the Arc wrappers they had. WGPU almost 3 years ago started reference-counting all their types so there's no need to add an extra Arc on our side.