-
Notifications
You must be signed in to change notification settings - Fork 186
Target the Web directly #101
Comments
Steps to get this working:
|
Thank you for describing the steps! They look very actionable, and make me believe we can get a prototype running (at least device creation) by the end of the year. FYI, (1) was mostly updated to latest WebIDL by https://phabricator.services.mozilla.com/D46166, which took more of my blood and tears than I'd hope or expect. Edit: actually, we settled on not exporting any WebGPU logic that isn't implemented yet, other than the bare interfaces... which means that at least my https://phabricator.services.mozilla.com/D49458 needs to be merged before we proceed here. |
Gecko PR has landed, and now one can at least create a device on WebGPU (in Nightly!). I think the work can be started here, according to @grovesNL plan. |
I also already have some branches for web-sys changes and wgpu-rs changes for this – just need to update them based on the recent changes and then we can start making some progress here. |
Small update: rustwasm/wasm-bindgen#1997 has been merged which allows us to use web-sys bindings for WebGPU while the WebIDL is still unstable |
514: Move some types into shared wgpu-types crate r=kvark a=grovesNL As we discussed a while ago, we need to be able to share some types between wgpu-core/wgpu-native/wgpu-remote/wgpu-rs. The problem is that we want to avoid a dependency on wgpu-core and wgpu-native when building [wgpu-rs for the wasm32-unknown-unknown target](gfx-rs/wgpu-rs#101). We can avoid this by moving all shared types into a separate crate which is exposed on all targets. Let me know if we should use some other approach or organize the types somehow. This isn't complete yet, but it might be easier to integrate this over several PRs instead of diverging my branch too far. Co-authored-by: Joshua Groves <josh@joshgroves.com>
514: Move some types into shared wgpu-types crate r=kvark a=grovesNL As we discussed a while ago, we need to be able to share some types between wgpu-core/wgpu-native/wgpu-remote/wgpu-rs. The problem is that we want to avoid a dependency on wgpu-core and wgpu-native when building [wgpu-rs for the wasm32-unknown-unknown target](gfx-rs/wgpu-rs#101). We can avoid this by moving all shared types into a separate crate which is exposed on all targets. Let me know if we should use some other approach or organize the types somehow. This isn't complete yet, but it might be easier to integrate this over several PRs instead of diverging my branch too far. Co-authored-by: Joshua Groves <josh@joshgroves.com>
514: Move some types into shared wgpu-types crate r=kvark a=grovesNL As we discussed a while ago, we need to be able to share some types between wgpu-core/wgpu-native/wgpu-remote/wgpu-rs. The problem is that we want to avoid a dependency on wgpu-core and wgpu-native when building [wgpu-rs for the wasm32-unknown-unknown target](gfx-rs/wgpu-rs#101). We can avoid this by moving all shared types into a separate crate which is exposed on all targets. Let me know if we should use some other approach or organize the types somehow. This isn't complete yet, but it might be easier to integrate this over several PRs instead of diverging my branch too far. Co-authored-by: Joshua Groves <josh@joshgroves.com>
We need to make wgpu-rs do the actual Web calls and run in the browser supporting WebGPU API. The API itself is still evolving, but we should start exploring what our side would look like, and maybe we'll already get something running.
The text was updated successfully, but these errors were encountered: