Async Plugin Initialization

[mrk-its]

Why we need it

Wgpu initialization is async, and currently bevy calls it using futures_lite::future::block_on. Unfortunately this approach doesn't work well in the browser on wasm32 target. During webgpu initialization it panics with condvar wait not supported - it seems future returned by Adapter::request_device needs to be await'ed on 'JS executor'. We already do this in bevy_assets - async function needs to be spawned by TaskPool::spawn_local (which calls wasm_bindgen_futures::spawn_local under the hood)

Proposal

Let's introduce additional App methods:

impl App {
     pub fn add_plugin_async<'a, T>(&'a mut self, plugin: &'a T) -> NonSendBoxedFuture<'a, Result<()>>
         Box::pin(async move {
             plugin.build_async(self).await.unwrap();
             Ok(self) 
         })
    }
}

and corresponding method in Plugin trait

pub trait Plugin {
    fn build_async<'a>(&'a self, app: &'a mut App) -> NonSendBoxedFuture<'a, Result<()>> {
        self.build(app);
        Box::pin(async move { Ok(()) })
    }
}

The similar thing may be done for App::add_plugins_async and PluginGroup

Default Plugin::build_async implementation makes it optional, this way we only need to implement it when necessary (currently only for bevy_render2::RenderPlugin)

Additionally we can add support for async main functions to #[bevy_main] macro and allow for following:

#[bevy_main]
async fn main() {
    App::new()
        .add_plugins_async(PipelinedDefaultPlugins)
        .await
        .unwrap()
        .add_startup_system(setup)
        .run();
}

or

#[bevy_main]
async fn main() -> Result<()> {
    App::new()
        .add_plugins_async(PipelinedDefaultPlugins)
        .await?
        .add_startup_system(setup)
        .run();
    Ok(())
}

Of course standard, non-async main will still work for native (non-web) targets (async version will work for both native and web)

PoC code including async plugin initialization and #[bevy_main] proc macro changes is here: https://github.com/mrk-its/bevy/commits/webgpu

[cart]

If we absolutely need "async all the way up" to target WebGPU, then I think this approach is probably the way to go. My main reservation is that I like having "one way" to do things. Something as central as App setup should be standardized. Having add_plugin and add_plugin_async variants already adds confusion. Then theres the whole "async main" vs "main" issue. If we need async for WebGPU to work, and we need one consistent way of doing things, then async-everything seems like the way to go. But then we have a bunch of awaits everywhere, which isn't particularly pretty, especially when rustfmt puts them on their own lines.

So it sort of feels like we either need to:

1. Compromise our ergonomics in the interest of consistency (async everywhere). We might be able to make this ergonomically better by deferring plugin init and doing a single await at the end.
2. Compromise our simplicity in the interest of ergonomics (async sometimes / only as needed, but consistent for a given use case).
3. Give up "write once run everywhere" in the interest of ergonomics where possible (async only as needed, inconsistent based on user preferences, probably defaulting to non-async in examples for simplicity)
4. Find a way to make this work without "async all the way up"

In the immediate short term (4) has my preference by a landslide. But that may be impossible, so we should have a contingency plan. I'm biased toward (1) if we can make it suitably ergonomic.

[cart]

We do have some time before we need to commit to something because WebGPU is still in the experimental phase and isn't yet a viable target for real apps. But we do want to make it easy for people to test Bevy + WebGPU so we can ensure that everything works / drive fixes upstream. 3) does feel like a reasonable middleground solution: add opt-in support for async variants without changing our recommendations / examples. When people are motivated to test WebGPU, they can go against our standards / recommendations. That buys us time to come up with a better holistic solution (like (1) or (4))

[cart]

It is worth calling out that it looks like @mrk-its has already implemented (3) in their PR.

[mrk-its]

Thanks for very detailed answer!
I agree 1) is the way to go long term (I really think web with webgpu has potential to be very important target in the future, so we will have to do more and more async), but for now it is definitely to early to force users to go async everywhere because of such experimental target.
4) is probably harder than 3) (if possible at all) - I chose this approach because it was simplest way to test bevy on webgpu :) Nice thing is it introduces async as optional, so we can pretend it doesn't exist and use it only when necessary (for webgpu experiments). It is probably good idea to not convert and complicate examples (maybe let's simply create some single dedicated webgpu example with async main). And if we decide to go 1) in the future we will have async path tested already.

[hymm]

Is initializing wgpu something we have to do during plugin initialization? If we had async systems could we do it in a startup system?

[mrk-its]

Probably wgpu initialization may be done in hypothetical async startup system, but implementing them would be much harder task than presented approach (for example all systems dependent on wgpu will need to be deferred until wgpu is initialized)
We were considering something similar in terms of bevy_webgl2 initialization, but it was really hard to implement.