Skip to content
This repository has been archived by the owner on Jun 18, 2021. It is now read-only.

Target the Web directly #101

Closed
kvark opened this issue Oct 25, 2019 · 6 comments
Closed

Target the Web directly #101

kvark opened this issue Oct 25, 2019 · 6 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@kvark
Copy link
Member

kvark commented Oct 25, 2019

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.

@kvark kvark added enhancement New feature or request help wanted Extra attention is needed labels Oct 25, 2019
@grovesNL
Copy link
Collaborator

grovesNL commented Oct 26, 2019

Steps to get this working:

  1. Ensure mozilla-central has up-to-date WebGPU WebIDL
    • This step can probably be omitted, but technically this is the upstream for many of the existing web-sys WebIDL files
    • Done (we use the complete WebIDL from gpuweb instead)!
  2. Update the existing WebGPU WebIDL in web-sys so we can generate Rust bindings
  3. Split calls in wgpu-rs to use #[cfg(target_arch = "wasm32")] to target web-sys, and #[cfg(not(target_arch = "wasm32"))] to target wgpu-native
    • We might want to consider splitting wgpu-rs into two backends (wgpu-native and web-sys), or use a trait like we do in glow, or something else
  4. Now we can build for wasm32-unknown-unknown and use wasm-bindgen-cli or wasm-pack as usual

@kvark
Copy link
Member Author

kvark commented Oct 26, 2019

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.

@kvark kvark pinned this issue Oct 26, 2019
@kvark
Copy link
Member Author

kvark commented Nov 19, 2019

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.

@grovesNL
Copy link
Collaborator

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.

@grovesNL grovesNL self-assigned this Feb 6, 2020
@grovesNL
Copy link
Collaborator

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

bors bot added a commit to gfx-rs/wgpu that referenced this issue Mar 10, 2020
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>
bors bot added a commit to gfx-rs/wgpu that referenced this issue Mar 11, 2020
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>
bors bot added a commit to gfx-rs/wgpu that referenced this issue Mar 11, 2020
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>
@kvark
Copy link
Member Author

kvark commented Apr 21, 2020

Let's consider this fixed by #193
Amazing work of @grovesNL and everyone involved, thank you all!

@kvark kvark closed this as completed Apr 21, 2020
@kvark kvark unpinned this issue Apr 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants