Improve control over initialization of render plugin

[MDeiml]

What problem does this solve or what need does it fill?

At the moment, initialization of the render plugin focuses on the most common use case, i.e. writing a standalone game / app. There are some use cases though, where the author wants to have more control over initialization of hardware resources. This might be the case for:

• Writing tests (minimal hardware access desired)
• An editor (should share hardware resources / control the apps use of resources)
• Embedding games into other applications
• Machine learning, bots, ...

What solution would you like?

Enable the user to create Render(Device|Queue|Adapter|Instance|...) themselves. An example how this could be implemented without adding complexity to the API is like in the asset plugin

bevy/crates/bevy_asset/src/lib.rs

Lines 111 to 115 in 92ba622

	if !app.world.contains_resource::<AssetServer>() {
	let source = create_platform_default_asset_io(app);
	let asset_server = AssetServer::with_boxed_io(source);
	app.insert_resource(asset_server);
	}

I.e. the plugin should check if the resources it is creating are already present in the app's World and use them if they exist.

What alternative(s) have you considered?

The use cases I mentioned should also be fine with running the app headless in another process and adding some kind of inter-process communication, but this would require modifying the game's code and be inefficient and more complex.

More Context

All render resources besides RenderInstance are wrapped in an Arc and thus can be easily shared. RenderInstance is not linked to any hardware resources. It's just the entry point to wgpu. A new RenderInstance can easily be created. We should just make sure that it uses the same backend as the RenderAdapter which can be found in RenderAdapterInfo.

[jinleili]

Embedding games into other applications

For this, I created bevy-in-app to demonstrate how to embed into an existing app.

[MDeiml]

Looks good. If I understand correctly the "bevy app" still has its own wgpu context though? I was thinking about bevy being able to share a GPU context with a "wrapper" app. You would need to be able to tell bevy "Please use this wgpu Device and this Queue" or similar.

[jinleili]

Sharing the wgpu context with external wgpu instances only requires bevy_render to expose it. By the time wgpu 0.15 is released, the new device_from_hal, adapter_from_hal ... APIs will provide the ability to share contexts with external vulkan, metal, etc. instances