Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support WebGL2 and WebGPU in the same WASM file #13168

Open
BD103 opened this issue May 1, 2024 · 6 comments
Open

Support WebGL2 and WebGPU in the same WASM file #13168

BD103 opened this issue May 1, 2024 · 6 comments
Labels
A-Rendering Drawing game state to the screen C-Feature A new feature, making something new possible C-Usability A targeted quality-of-life change that makes Bevy easier to use D-Complex Quite challenging from either a design or technical perspective. Ask for help! M-Needs-Release-Note Work that should be called out in the blog due to impact O-Web Specific to web (WASM) builds S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it!

Comments

@BD103
Copy link
Member

BD103 commented May 1, 2024

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

Bevy currently forces you to choose either WebGL2 or WebGPU when building a project. This is one extra thing that developers need to think about when deploying their games, which is already a complicated enough process.

Since the web is a large, incredibly portable platform, we should attempt to make targeting it as painless as possible.

What solution would you like?

In gfx-rs/wgpu#5044, WGPU added support for detecting WebGL2 and WebGPU at runtime. I think integrating this into Bevy would be incredibly useful, and give WebGPU more exposure. This would be achieved through the existing webgl2 and webgpu features.

webgl2 enabled? webgpu enabled? Behavior
Detect API at runtime, preferring WebGPU and falling back to WebGL2 if not available
Use WebGL2, panicking if not available at runtime
Use WebGPU, panicking if not available at runtime
Fail to compile for WASM

Questions

  • What crate(s) will need to implement this functionality? Is there a way we can abstract over both APIs to reduce the amount of logic necessary?
  • Does WebGPU still need --cfg=web_sys_unstable_apis, and do we handle this already?
  • How difficult will this change be? Is it something we can plan on finishing by Bevy 0.14?

What alternative(s) have you considered?

  • Instead of panicking, using the error!(...) macro may be preferred because it will be visible in the Javascript console.
    • Do we have a panic handler for WASM that logs panics? If not, then error! may be preferred.

Additional context

cc @Elabajaba, who originally migrated Bevy to the WGPU version that introduced this feature.

@BD103 BD103 added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled A-Rendering Drawing game state to the screen C-Usability A targeted quality-of-life change that makes Bevy easier to use M-Needs-Release-Note Work that should be called out in the blog due to impact and removed S-Needs-Triage This issue needs to be labelled labels May 1, 2024
@mockersf
Copy link
Member

mockersf commented May 1, 2024

Questions

  • What crate(s) will need to implement this functionality? Is there a way we can abstract over both APIs to reduce the amount of logic necessary?

Only rendering part should be affected. mostly bevy_render and bevy_pbr

  • Does WebGPU still need --cfg=web_sys_unstable_apis, and do we handle this already?

No, wgpu now vendors those so they're not needed anymore

  • How difficult will this change be? Is it something we can plan on finishing by Bevy 0.14?

Biggest difficulty I think is that currently some const change value depending on WebGL2 / WebGPU / Native. Deciding them at runtime means they won't be const anymore.

Also I think WebGPU detection is hard to do perfectly, so we need a way to "force" fallback on WebGL2 even if WebGPU is detected

@BD103
Copy link
Member Author

BD103 commented May 2, 2024

Biggest difficulty I think is that currently some const change value depending on WebGL2 / WebGPU / Native. Deciding them at runtime means they won't be const anymore.

Ok, that will require a bit of benchmarking then to ensure the performance hit is not too great. This will probably affect all of WASM, even if you don't runtime detection.

Also I think WebGPU detection is hard to do perfectly, so we need a way to "force" fallback on WebGL2 even if WebGPU is detected

You can toggle off the webgpu feature at compile time. If we want to do this at runtime, perhaps there can be a resource that configures it. Quick draft:

// This is a bad name, please ignore it
#[derive(Resource)]
enum WASMBackend {
    WebGPU,
    WebGL2,
    Available, // Prefers WebGPU if possible, could instead be named `PreferWebGPU`
}

@mockersf mockersf added the O-Web Specific to web (WASM) builds label May 2, 2024
@mockersf
Copy link
Member

Ideally (parts of) Bevy should also support building without WebGL2 and WebGPU, and support targeting wasi (#4906 & #8520)

@rparrett
Copy link
Contributor

Related: #11505

@BenjaminBrienen BenjaminBrienen added D-Complex Quite challenging from either a design or technical perspective. Ask for help! S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it! labels Oct 29, 2024
@lomirus
Copy link
Contributor

lomirus commented Dec 23, 2024

Will this feature double the WASM file size for those who only want to use WebGPU or WebGL2, or just increase the size slightly?

@mockersf
Copy link
Member

just increase slightly!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Feature A new feature, making something new possible C-Usability A targeted quality-of-life change that makes Bevy easier to use D-Complex Quite challenging from either a design or technical perspective. Ask for help! M-Needs-Release-Note Work that should be called out in the blog due to impact O-Web Specific to web (WASM) builds S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it!
Projects
None yet
Development

No branches or pull requests

5 participants