Avoid using WasmAbi functions on WebGPU backend#3657
Avoid using WasmAbi functions on WebGPU backend#3657cwfitzgerald merged 5 commits intogfx-rs:trunkfrom
WasmAbi functions on WebGPU backend#3657Conversation
|
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 :) |
cwfitzgerald
left a comment
There was a problem hiding this comment.
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-unknownif applicable.Connections
Fixes #3430
Description
IntoWasmAbiandFromWasmAbican be problematic for our use case becauseIntoWasmAbitakes 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
Arcinternally 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.