Webgpu support

[mockersf]

Objective

• Support WebGPU
• alternative to WebGPU support #5027 that doesn't need any async / await
• fixes Official WebGPU Support #8315
• Surprise fix Wayland windows' colors are too dark #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

// 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>();
    }
}

[github-actions]

Example no_renderer failed to run, please try running it locally and check the result.

[github-actions]

Example no_renderer failed to run, please try running it locally and check the result.

[superdump]

Yeeeeeeeeaaaaahhh! Much excite! :) I’ll take a look at the errors if no one else beats me to it. And you’re welcome to.

[hymm]

Rather than a finish lifecycle, would it make sense to have a renderer specific one to simplify the thinking around "where do I put what code".

impl RenderPlugin for MyPlugin {
  fn render_app(&self, mut render_app: &mut App) {
    // put code modifying render app here.
  }
  
  fn extract_app(&self mut extract_app: &mut App) {
    // put code modifying extract app here.
  }
}

you could not add the render and extract app until after the renderer is ready, to make it 100% clear to not modify the render app in the build function.

[mockersf]

Rather than a finish lifecycle, would it make sense to have a renderer specific one to simplify the thinking around "where do I put what code".

Sounds good to me, to have a RenderPlugin "specialisation" of the general Plugin that would automatically plug the correct methods with the correct app at the correct step.

I'll wait for more feedback on the API which is definitely open to discussion

[cart]

Yesssssss well done! This definitely seems like the better path. I'm stoked we don't need to async-ify the entire plugin api. I'll give the pipeline / render app init apis some thought, but I'm on board for the general direction.

We might even want to skip blocking on the "ideal render init api design" and do that in a follow up pr. It would be nice to get this in peoples' hands asap so we can iron out the kinks and capitalize on the "WebGPU release hype".

[superdump]

Completely agree on not getting hung up too much on render app init api for this PR. It's a good discussion to have, and this PR is about making WebGPU go. :)

[mockersf]

stencilLoadOp errors are now fixed on wgpu trunk

remaining:

Sample type TextureSampleType::Float for multisampled texture bindings was TextureSampleType::Float.
 - While validating entries[17]
 - While validating [BindGroupLayoutDescriptor "mesh_view_layout_multisampled"]
 - While calling [Device].CreateBindGroupLayout([BindGroupLayoutDescriptor "mesh_view_layout_multisampled"]).

[Invalid BindGroupLayout "mesh_view_layout_multisampled"] is invalid.
 - While validating [BindGroupDescriptor "mesh_view_bind_group"] against [Invalid BindGroupLayout "mesh_view_layout_multisampled"]
 - While calling [Device].CreateBindGroup([BindGroupDescriptor "mesh_view_bind_group"]).

[Invalid PipelineLayout] is invalid.
 - While calling [Device].CreateRenderPipeline([RenderPipelineDescriptor "gizmo_3d_pipeline"]).

[Invalid RenderPipeline "gizmo_3d_pipeline"] is invalid.
 - While encoding [RenderPassEncoder "main_opaque_pass_3d"].SetPipeline([Invalid RenderPipeline "gizmo_3d_pipeline"]).

[Invalid PipelineLayout] is invalid.
 - While calling [Device].CreateRenderPipeline([RenderPipelineDescriptor "pbr_opaque_mesh_pipeline"]).

[Invalid PipelineLayout] is invalid.
 - While calling [Device].CreateRenderPipeline([RenderPipelineDescriptor "pbr_alpha_blend_mesh_pipeline"]).

and a lot of unhelpful

[Invalid CommandBuffer] is invalid.
    at ValidateObject (..<URL>)
    at ValidateSubmit (..<URL>)

which I'm hoping will be fixed by fixing other issues

[mockersf]

Fixed now, the flight helmet can be displayed 🎉

There is an issue with gamma correction, trying to find it

[tim-blackbird]

Incorrect colors should be because of the TODO left in the code here.
See this comment on the wgpu 0.15 update PR: #7356 (comment).

It should be the same surface format issue as with Nvidia + Wayland.

[mockersf]

fixed too!

[superdump]

Awesome! Well done @mockersf ! :)

[tim-blackbird]

Nice! I can confirm that fixes Nvidia + Wayland (and probably some other hardware/software combos) as well : )

[mockersf]

Nice! I can confirm that fixes Nvidia + Wayland (and probably some other hardware/software combos) as well : )

Ho that's a nice side effect 😄 Do you know if there are issues opened?

[tim-blackbird]

#7318 for Nvidia + Wayland
#2374 and #5809 seem similar but for Intel iGPUs on either X11 or Wayland

[mockersf]

thanks! let's wait for this to be merged so someone can check for the two others.

with gfx-rs/wgpu#3689 and a small workaround in Bevy, bloom also works 🎉

[mockersf]

every example I tried seems to work now, except compute_shader_game_of_life because it uses a read/write texture of format Rgba8Unorm which is not yet supported (gpuweb/gpuweb#1772 and gpuweb/gpuweb#3838)

[mockersf]

With #8446 merged and wgpu updated to 0.16, this is now ready 🎉

[superdump]

I don’t have too much in the way of opinions about plugin stuff. Others should definitely review that, please. It does feel like a shame that users implementing rendering stuff have to care about that and implement finish() but maybe that’s the only way to handle it.

The rendering bits generally look fine. It’s mostly just plugin adjustment. Just a few comments.

[superdump]

It would be better to know what value should be used. But I guess this will do.

[mockersf]

Should webgpu be the default? It's the easiest way to do it through rust features, and adding one to target webgl2 instead.

It would probably be possible to keep webgl2 the default, but that would mean needing to disable default features to target webgpu.

[cart]

Should webgpu be the default? It's the easiest way to do it through rust features, and adding one to target webgl2 instead. It would probably be possible to keep webgl2 the default, but that would mean needing to disable default features to target webgpu.

I think WebGL2 should be the default until WebGPU is more widely supported. Making it harder to target WebGPU (by requiring disabling default features) while it is still rolling out seems very reasonable to me. The alternative (forcing users onto WebGPU by default before it is widely supported) seems worse to me.

[mockersf]

I think WebGL2 should be the default until WebGPU is more widely supported. Making it harder to target WebGPU (by requiring disabling default features) while it is still rolling out seems very reasonable to me. The alternative (forcing users onto WebGPU by default before it is widely supported) seems worse to me.

Done!

[cart]

This is in a good spot now. Im stoked to finally have WebGPU support!
We should follow up with a "render plugin init" rethink.