WebGPU support #5027

mockersf · 2022-06-16T11:01:35Z

Objective

Enable building Bevy for WebGPU

Solution

Make building a plugin async. This allows us to initialize the renderer without blocking in wasm
Make #[bevy_main] handles async fn main

details per commit:

Those 3 commits are only partially related to webgpu, and I feel could be pushed in other PRs if needed to reduce this one

commit	details
`missing wasm flag`	just remove a warning when building with wasm - #5038
`spirv as a feature`	disable default support of spirv. This doesn't build in wasm, and is probably not needed in most case - fixed by gfx-rs/wgpu#2355
`fix skinning shader syntax`	the skinning shader uses a deprecated syntax to access a matrix, and it doesn't work anymore in webgpu - #5039

Those 4 commits are most of the changes:

commit	details
`async plugin v0`	makes building a plugin async
`webgpu feature and how to build`	update the wasm example builder to be able to build examples for webgpu. some manual editing is needed for now
`async bevy_main v0`	have `#[bevy_main]` handle async main function in the correct manner for each arch
`automatically update shader syntax`	WGSL syntax has been updated but the latest version is not yet supported in most places. it is needed to run WGSL shaders in chrome

The last two commits are updating examples and tests

commit	details
`update many examples`	update examples
`fix tests`	fix tests

to build an example for WebGPU:

edit root Cargo.toml and remove the automatic webgl feature added for wasm32
cargo run -p build-wasm-example -- lighting --webgpu

Migration Guide

TODO

mockersf · 2022-06-16T11:09:16Z

I didn't test all examples, but at least all the stress tests work
I didn't test android and iOS

This adds some boilerplate:

plugins need to build async, but async trait are not possible in Rust yet so https://crates.io/crates/async-trait is needed
creating an app is now async too, and that adds additional dependencies (and only small code change if we want to push for #[bevy_main])

alice-i-cecile · 2022-06-16T11:10:46Z

Can we test this in CI yet? It looks like WebGPU support still isn't general access, so that may be hard 🤔

mockersf · 2022-06-16T11:17:28Z

You can check if your browser supports WebGPU here: https://wgpu.rs/examples-gpu/?example=hello-triangle. I was able to run Bevy examples in Chromium 105.0.5114.0, but not on Firefox Nightly 103.0a1. It seems Firefox doesn't support the new WGSL syntax yet.

As for running in CI, Bevy assumes for now that wasm32 means WebGL2. It requires manual editing of the Cargo.toml file to comment those lines to build for WebGPU. This PR doesn't make it easy to build for WebGPU but possible (you can depend on sub crates instead of Bevy if you don't want to keep up a fork with the webgl feature removed). I think for now keeping webgl as default is a good choice as WebGPU is very young and it's not possible to have both webgl and webgpu enabled at the same time.

bjorn3 · 2022-06-16T12:51:58Z

crates/bevy_app/src/app.rs

@@ -763,12 +763,12 @@ impl App {
    /// #
    /// App::new().add_plugin(bevy_log::LogPlugin::default());
    /// ```
-    pub fn add_plugin<T>(&mut self, plugin: T) -> &mut Self
+    pub async fn add_plugin<T>(&mut self, plugin: T) -> &mut Self


I don't think adding plugins should ever be async. IMO they should just register things, not do any actual work until the startup systems run.

I agree with this, but that ties into the broader discussion in #1255.

The current add_plugin does all the work of building the plugin immediately.
We could (and probably should) switch to a register_plugin that would actually build the plugin just before running, then only the last step would need to be async. That would open a lot of solutions for plugin ordering and dependencies

bjorn3 · 2022-06-16T12:56:20Z

crates/bevy_render/src/lib.rs

-                renderer::initialize_renderer(&instance, &options, &request_adapter_options),
-            );
+            let (device, queue, adapter_info) =
+                renderer::initialize_renderer(&instance, &options, &request_adapter_options).await;


#4913 moves this into a closure called once winit says that the app has resumed rather than immediatly running it when building the plugin. This is necessary for android and would solve all the threading through of async plugin building.

I think this is not enough in this case. I tried using #4913 and it crashed here:

bevy/crates/bevy_render/src/lib.rs

Lines 144 to 146 in ab72c83

let (device, queue, adapter_info) = futures_lite::future::block_on(

renderer::initialize_renderer(&instance, &options, &request_adapter_options),

);

The issue with wasm/WebGPU is not to do it later, it's to be able to wait for it without blocking.

I suppose the WebGPU context takes just long enough that it blocks. Some people reported a similar issue when using WebGL2 not in release mode, if initialising the renderer takes too long it doesn't work in wasm to block for it.

WIth #4913 it would be possible to turn just the render initialize functions into async functions (hidden from the user) rather than forcing all plugin builders to be async (right in the face of every user).

I suppose the WebGPU context takes just long enough that it blocks.

Getting a value out of a javascript promise requires either calling .then() on it, or await on it. Using a mutex on the main thread like futures_lite does isn't possible in javascript. Only workers are allowed to block.

Using a mutex on the main thread like futures_lite does isn't possible in javascript

This is what Bevy is currently doing, and it works... if it's fast enough

No, it works on systems where blocking is allowed (non-web platforms). Or when the future is already resolved (webgl on web as webgl isn't async).

So that code can't work for WebGPU, even if its execution is delayed. If I understand correctly its asyncness needs to be kept, so at some point we need to expose something async to the user

It should be possible to call the initialize_renderer function and then use wasm_bindgen_futures to run the rest of the render initialization after the promise resolves. This can be handled entirely inside bevy itself.

With #4913 the runner is essentially given responsibility to iterate over a vector of callbacks to handle initializing the render state.

One possibility is that those callbacks could be broken up relatively easily if there's some requirement to not block for too long with Web GPU for something. e.g. the runner could potentially run a single callback at a time and return to the browser mainloop between each callback if that would work to keep it happy.

Or, maybe as an alternative to making add_plugin() async then maybe the render_init callbacks could be made async for this. It would probably be fairly simple for the runner to continue running them as blocking functions via pollster::block_on in the general case but then there could be some extra care taken for webgpu to let them complete asynchronously.

Maybe the need to make the render_init functions async could be hidden for the most part from most plugins that don't need async render initialization by having separate APIs for .add_render_init and .add_async_render_init so only the few things dealing with webgpu would utilize async render init callbacks?

# Objective - Support WebGPU - alternative to #5027 that doesn't need any async / await - fixes #8315 - Surprise fix #7318 ## Solution ### For async renderer initialisation - Update the plugin lifecycle: - app builds the plugin - calls `plugin.build` - registers the plugin - app starts the event loop - event loop waits for `ready` of all registered plugins in the same order - returns `true` by default - then call all `finish` then all `cleanup` in the same order as registered - then execute the schedule In the case of the renderer, to avoid anything async: - building the renderer plugin creates a detached task that will send back the initialised renderer through a mutex in a resource - `ready` will wait for the renderer to be present in the resource - `finish` will take that renderer and place it in the expected resources by other plugins - other plugins (that expect the renderer to be available) `finish` are called and they are able to set up their pipelines - `cleanup` is called, only custom one is still for pipeline rendering ### For WebGPU support - update the `build-wasm-example` script to support passing `--api webgpu` that will build the example with WebGPU support - feature for webgl2 was always enabled when building for wasm. it's now in the default feature list and enabled on all platforms, so check for this feature must also check that the target_arch is `wasm32` --- ## Migration Guide - `Plugin::setup` has been renamed `Plugin::cleanup` - `Plugin::finish` has been added, and plugins adding pipelines should do it in this function instead of `Plugin::build` ```rust // Before impl Plugin for MyPlugin { fn build(&self, app: &mut App) { app.insert_resource::<MyResource> .add_systems(Update, my_system); let render_app = match app.get_sub_app_mut(RenderApp) { Ok(render_app) => render_app, Err(_) => return, }; render_app .init_resource::<RenderResourceNeedingDevice>() .init_resource::<OtherRenderResource>(); } } // After impl Plugin for MyPlugin { fn build(&self, app: &mut App) { app.insert_resource::<MyResource> .add_systems(Update, my_system); let render_app = match app.get_sub_app_mut(RenderApp) { Ok(render_app) => render_app, Err(_) => return, }; render_app .init_resource::<OtherRenderResource>(); } fn finish(&self, app: &mut App) { let render_app = match app.get_sub_app_mut(RenderApp) { Ok(render_app) => render_app, Err(_) => return, }; render_app .init_resource::<RenderResourceNeedingDevice>(); } } ```

mockersf added 9 commits June 16, 2022 12:42

missing wasm flag

0da663a

spirv as a feature

df8687d

fix skinning shader syntax

9cb28bb

async plugin v0

da07597

webgpu feature and how to build

556a578

async bevy_main v0

5100cbe

automatically update shader syntax

b7a2590

update many examples

d12ccba

fix tests

4595de3

mockersf added O-Web Specific to web (WASM) builds X-Controversial There is active debate or serious implications around merging this PR labels Jun 16, 2022

alice-i-cecile added C-Enhancement A new feature A-Rendering Drawing game state to the screen C-Performance A change motivated by improving speed, memory usage or compile times labels Jun 16, 2022

DJMcNab added A-App Bevy apps and plugins C-Breaking-Change A breaking change to Bevy's public API that needs to be noted in a migration guide labels Jun 16, 2022

bjorn3 reviewed Jun 16, 2022

View reviewed changes

This was referenced Apr 6, 2023

Official WebGPU Support #8315

Closed

Webgpu support #8336

Merged

mockersf closed this Apr 29, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WebGPU support #5027

WebGPU support #5027

mockersf commented Jun 16, 2022 •

edited

Loading

mockersf commented Jun 16, 2022

alice-i-cecile commented Jun 16, 2022

mockersf commented Jun 16, 2022

bjorn3 Jun 16, 2022

alice-i-cecile Jun 16, 2022

mockersf Jun 16, 2022

bjorn3 Jun 16, 2022

mockersf Jun 16, 2022

bjorn3 Jun 16, 2022

mockersf Jun 16, 2022

bjorn3 Jun 16, 2022

mockersf Jun 16, 2022

bjorn3 Jun 16, 2022 •

edited

Loading

rib Jul 4, 2022

	let (device, queue, adapter_info) = futures_lite::future::block_on(
	renderer::initialize_renderer(&instance, &options, &request_adapter_options),
	);

WebGPU support #5027

WebGPU support #5027

Conversation

mockersf commented Jun 16, 2022 • edited Loading

Objective

Solution

details per commit:

Migration Guide

mockersf commented Jun 16, 2022

alice-i-cecile commented Jun 16, 2022

mockersf commented Jun 16, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bjorn3 Jun 16, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mockersf commented Jun 16, 2022 •

edited

Loading

bjorn3 Jun 16, 2022 •

edited

Loading