-
Notifications
You must be signed in to change notification settings - Fork 930
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
Avoid using WasmAbi
functions on WebGPU backend
#3657
Avoid using WasmAbi
functions on WebGPU backend
#3657
Conversation
Tried it on https://github.com/niklaskorz/linon/tree/dynamic-dispatch-workaround and it works (deployed on https://niklaskorz.github.io/linon/): A note though (that might be unrelated to this PR, not sure): using depth textures without a stencil part in the format does not seem to work in Chrome, i.e. using
Edit: ok this is indeed unrelated to this PR but it's an existing bug in wgpu, I'll try to fix it :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All seems reasonable, thank you for taking the time to fix this!
Checklist
cargo clippy
.RUSTFLAGS=--cfg=web_sys_unstable_apis cargo clippy --target wasm32-unknown-unknown
if applicable.Connections
Fixes #3430
Description
IntoWasmAbi
andFromWasmAbi
can be problematic for our use case becauseIntoWasmAbi
takes ownership of our type. We could workaround this in different ways, but the most straightforward path right now seems to be to avoid using these entirely and instead not tracking IDs for the WebGPU backend.We could look at doing this in a few different ways once we internally make some changes to better support multi-threading (e.g., many types will be
Arc
internally so we could consider some other approaches).Testing
Tested the WebGPU examples that are known to work (hello-triangle, boids, msaa-line, etc.) in Canary.