Support extern context impl

[sagudev]

Connections
Based on #6619, fixes #6330

Description
This PR enables users of wgpu to provide custom Instance impl (and other wgpu types as all other types are derived from Instance->Adapter->Device), by adding Custom variant and custom backend that has dyn wrapper for all types: struct DynDevice(Arc<dyn DeviceInterface>). I'm intermixing Custom with Dyn because I cannot really decide on name (CustomDevice is weird, but we already have Dyn* in wgpu-hal).
There are few rough sports:

• RenderBundleEncoderInterface::finish (other backends hacks around by not using dyn dispatch, but we can't:

  wgpu/wgpu/src/api/render_bundle_encoder.rs

  Lines 54 to 60 in b876b8c

  	pub fn finish(self, desc: &RenderBundleDescriptor<'_>) -> RenderBundle {
  	let bundle = match self.inner {
  	#[cfg(wgpu_core)]
  	dispatch::DispatchRenderBundleEncoder::Core(b) => b.finish(desc),
  	#[cfg(webgpu)]
  	dispatch::DispatchRenderBundleEncoder::WebGPU(b) => b.finish(desc),
  	};

Testing
There is wgpu-custom crate that showcases how one can create Custom wgpu types.

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[sagudev]

TBH, I have no idea what's wrong with WASM.

[sagudev]

This is triggering visibility problems for WASM, but I do not know why.

[cwfitzgerald]

Ping me if this needs looking at or you need help before it is out of draft, going to un-assign myself for bookeeeping

[sagudev]

In 79ecded I removed InterfaceTypes trait as it's not really needed anymore (this makes writing Custom/Dyn wrappers easier as they do not need to impl traits directly, avoiding a lot of boilerplate), all bounds are actually enforced in dispatch_types_inner anyway. The only useful application was making writing macros easier, but I replaced this with mod interface_types that has aliases for interface types (there is a lot of this pattern in servo as it was used before associate trait types), but we could also just write more stuff in macro and remove the completely. Does approach like this sounds reasonable @cwfitzgerald? I would be willing to split this into separate PR if it's ok.

[cwfitzgerald]

Hmm... I don't love it as it makes things less structured, but can't see a strong argument against removing the trait. Will fully consider it when I review this. You can leave it as part of this PR for now.

[sagudev]

I have alternative approach in sagudev@ce58280 which keeps the trait but instead of using interfaces in bounds it uses Dispatch<Target = dyn Interface> (clone of Deref trait, I avoid Deref to avoid compiler magic as it makes bounds less explicit esp between Dispatch and DispatchMut). One thing to consider here is that implementations of custom context will need to provide all types, even those that are not needed (ex. if one does not need/use compute pass). Should I switch to this approach @cwfitzgerald?

[cwfitzgerald]

I have alternative approach in sagudev@ce58280 which keeps the trait but instead of using interfaces in bounds it uses Dispatch<Target = dyn Interface> (clone of Deref trait, I avoid Deref to avoid compiler magic as it makes bounds less explicit esp between Dispatch and DispatchMut).

I'm going to leave this up to your own judgement which is cleaner and more parsable, my initial impression is that the mod { type } approach is less infrastructure and less confusing than adding the Dispatch one

[sagudev]

@cwfitzgerald I think this is ready for concept review, it still needs more docs and maybe some polish 💅🏾.

[cwfitzgerald]

Nice! I'm going to take this out of draft for bookkeeping

[cwfitzgerald]

Don't love the whole new type alias thing, but don't really hate it enough to say no

[sagudev]

Don't love the whole new type alias thing, but don't really hate it enough to say no

I think we could actually inline all types uses into macro invocation (all 3 of them). Would that be better?

[cwfitzgerald]

I think we could actually inline all types uses into macro invocation

Hmm, yeah I think that's fine - the whole appeal to me is to make sure things have uniform naming conventions and are all filled out, so having them all in one place seems to do that trick fine.

[sagudev]

I think we could actually inline all types uses into macro invocation

Hmm, yeah I think that's fine - the whole appeal to me is to make sure things have uniform naming conventions and are all filled out, so having them all in one place seems to do that trick fine.

I am not sure I understand, should I inline all types uses into macro or keep the mods?

[cwfitzgerald]

Oh sorry was unclear, inline into the macro.

[cwfitzgerald]

Some small things, but I think this is good to go after that!

[cwfitzgerald]

I have some futzing I want to do to the examples, but I'll do that post land.

Thanks!

[DJMcNab]

Has this been released? I'm trying to check the changelog for when this got released

[sagudev]

Has this been released? I'm trying to check the changelog for when this got released

Yes it was, but there are still some rough edges: #7533