Re-export wgpu

[jnhyatt]

Objective

Most users don't need direct access to wgpu:: types beyond the ones exposed in bevy_render::render_resource and a couple other places, but users wanting to interact with the render graph typically need more. In addition, we expose wgpu types in several public APIs without exposing those types in Bevy. This means when you want to use these APIs, you have to pull in wgpu as a direct dependency. Since Bevy releases don't always coincide with wgpu releases, it's easy to accidentally pull in a different version than the one Bevy is using. It also means you have to carefully update wgpu version when you update Bevy version.
 

Solution

• Re-export all wgpu:: types as bevy_render::wgpu::
• All wgpu type rexports are unchanged, i.e. bevy_render::render_resource::AddressMode still works as well as bevy_render::wgpu::AddressMode, so no migration guide necessary

---

Changelog

• wgpu types are now available as bevy_render::wgpu::XXX

[alice-i-cecile]

Likely obsoletes #7109

[alice-i-cecile]

All wgpu type rexports are unchanged, i.e. bevy_render::render_resource::AddressMode still works as well as bevy_render::wgpu::AddressMode, so no migration guide necessary

I would prefer we list these as deprecated, and then remove them in the release after this ships.

[jnhyatt]

Just to play devil's advocate, having opaque "aliases" for raw wgpu types might be valuable. That way the average user doesn't have to acknowledge the "bad" raw types, they can focus on the "nice" Bevy types.

Maybe we could take the currently aliased types and put them in a prelude somewhere?

I'm fine either way, and I'll push this up with other usages deprecated if that's the consensus.

[alice-i-cecile]

Just to play devil's advocate, having opaque "aliases" for raw wgpu types might be valuable. That way the average user doesn't have to acknowledge the "bad" raw types, they can focus on the "nice" Bevy types.

This is definitely reasonable as a perspective, but I personally think that adding this level of complexity for both maintainers and users probably isn't worth it. Really curious to see what the rendering experts think though!

[kurtkuehnert]

In my opinion this has nothing todo with #7109.
Exposing wgpu directly has come up multiple times in the past (as far as I know). Most of the time the missing capabilities/exports in bevy_render where just added to the enigne itself. Sometimes we just expose them as Raw{WgpuType}.

Since bevy heavily aliases the wgpu types and changes/improves their API for in engine usage, I am strongly oposing this PR.

For users it will be hard to differentiate between a bevy PipelineDescriptor and a wgpu one for example. This will also be a huge problem for auto imports and IDE support.

I would much rather just reexport all wgpu types (that are not already part of our render API) individually with the Raw prefix. This way they can not be confused and are available for those who need them.

[jnhyatt]

If I understand, the problem is collisions with wgpu/Bevy types? It might be easier to rename the conflicting Bevy types than prefix every wgpu type. That said, if a macro or something could do this for us, I'd be for it. Is that possible? My understanding of proc macros is that this beyond their abilities

[kurtkuehnert]

Bevy alters the API of wgpu to some extend. We reexport most of the wgpu stuff in a more convenient way for engine users.
The problem is that sometimes we would like to use the underlying wgpu API directly. For that I think it makes sense to reexport all of the types with an altered bevy equivalent using the Raw prefix. Doing it the other way around would be much worse, since most of our types would then look like this: BevyBuffer, BevyPipeline, etc.

[jnhyatt]

Alright, then I think this is good to be closed out, prefixing wgpu can be a new pr