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

Allow WebGPU & WebGL in same wasm and detect WebGPU availability #5044

Merged
merged 14 commits into from
Jan 14, 2024

Conversation

Wumpf
Copy link
Member

@Wumpf Wumpf commented Jan 11, 2024

Connections

Shoutout to @daxpedda who did a lot of the groundwork to make this possible!

Description
Allows to compile with both webgpu & webgl backends enabled. There's a new webgpu feature flag that is enabled by default for this purpose. When additionally enabling webgl this will no longer disable webgpu and both features can live side by side.
The WebGPU backend remains a special case in that far that an instance decides (via very simple support detection logic) upon creation if it is a WebGPU instance or a WgpuCore instance. I did a bunch of renamings in that area to make this more obvious. Also, all as_hal methods now return an Option (most already did) to make it possible for them to return None whenever both WebGPU & WebGL are enabled (only a WebGL/WgpuCore instance can do hal conversion). Similar patter applies to a variety of things.

DRAFT until #4984 lands
(makes the diff also significantly smaller)

Testing

image

Checklist

  • Run cargo fmt.
  • Run cargo clippy. If applicable, add:
    • --target wasm32-unknown-unknown
    • --target wasm32-unknown-emscripten
  • Run cargo xtask test to run tests.
  • Add change to CHANGELOG.md. See simple instructions inside file.

Copy link
Member

@cwfitzgerald cwfitzgerald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to see it rebased to fully review, but some initial comments

wgpu/src/backend/mod.rs Show resolved Hide resolved
wgpu/src/lib.rs Outdated Show resolved Hide resolved
wgpu/src/lib.rs Outdated Show resolved Hide resolved
wgpu/src/lib.rs Outdated Show resolved Hide resolved
@Wumpf Wumpf marked this pull request as ready for review January 12, 2024 08:27
@Wumpf Wumpf requested a review from a team as a code owner January 12, 2024 08:27
Copy link
Member

@cwfitzgerald cwfitzgerald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good outside of a issue with get_mapped_range

wgpu/src/backend/wgpu_core.rs Outdated Show resolved Hide resolved
@cwfitzgerald cwfitzgerald self-requested a review January 13, 2024 20:55
Copy link
Member

@cwfitzgerald cwfitzgerald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hell yes!

@cwfitzgerald
Copy link
Member

@Wumpf please resolve conflicts, then merge

@Wumpf
Copy link
Member Author

Wumpf commented Jan 14, 2024

woo 🥳

@Wumpf Wumpf enabled auto-merge (squash) January 14, 2024 09:24
@Wumpf Wumpf merged commit 7774f31 into gfx-rs:trunk Jan 14, 2024
27 checks passed
@Keavon
Copy link

Keavon commented Jan 16, 2024

This looks very handy! Is there a documented list of things the WebGL version doesn't support? I assume compute shaders is one such obvious missing feature (although I wonder if there's been any effort put towards polyfilling compute shaders with fragment shader magic?).

@Wumpf
Copy link
Member Author

Wumpf commented Jan 16, 2024

@Keavon there's unfortunately no written out list since it's a bit hard to capture - some of the exact capabilities are determined at runtime. But you can check https://docs.rs/wgpu/latest/wgpu/struct.DownlevelFlags.html# for possible lacking features as well as https://docs.rs/wgpu/latest/wgpu/struct.Limits.html#method.downlevel_webgl2_defaults which lists out the reduced limits of webgl directly.
As you guessed there's no compute shaders and no effort to polyfill them - this would be huge undertaking and likely run into issues that would make you resort to cpu based emulation (most prominently there's no random access writes at all which bars the door to emulating the harder stuff like shared memory and don't even get me started about atomics ;))

@cwfitzgerald
Copy link
Member

It's almost certainly easier to polyfill them in the user's application using application specific knowledge if you need them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Dynamic WebGPU support detection
3 participants