fluencelabs/wasm-bindgen
1
0
Fork 0
mirror of https://github.com/fluencelabs/wasm-bindgen synced 2025-03-31 01:11:06 +00:00
Code Issues Projects Releases Wiki Activity
wasm-bindgen/examples/raytrace-parallel/Cargo.toml

33 lines
703 B
TOML
Raw Normal View History

Implement support for WebAssembly threads ... and add a parallel raytracing demo! This commit adds enough support to `wasm-bindgen` to produce a workable wasm binary *today* with the experimental WebAssembly threads support implemented in Firefox Nightly. I've tried to comment what's going on in the commits and such, but at a high level the changes made here are: * A new transformation, living in a new `wasm-bindgen-threads-xform` crate, prepares a wasm module for parallel execution. This performs a number of mundane tasks which I hope to detail in a blog post later on. * The `--no-modules` output is enhanced with more support for when shared memory is enabled, allowing passing in the module/memory to initialize the wasm instance on multiple threads (sharing both module and memory). * The `wasm-bindgen` crate now offers the ability, in `--no-modules` mode, to get a handle on the `WebAssembly.Module` instance. * The example itself requires Xargo to recompile the standard library with atomics and an experimental feature enabled. Afterwards it experimentally also enables threading support in wasm-bindgen. I've also added hopefully enough CI support to compile this example in a builder so we can upload it and poke around live online. I hope to detail more about the technical details here in a blog post soon as well!
2018-10-04 20:00:23 -07:00
[package]
name = "raytrace-parallel"
version = "0.1.0"
authors = ["The wasm-bindgen Developers"]
Update raytrace-parallel to rust 2018
2018-12-11 16:37:17 -02:00
edition = "2018"
Implement support for WebAssembly threads ... and add a parallel raytracing demo! This commit adds enough support to `wasm-bindgen` to produce a workable wasm binary *today* with the experimental WebAssembly threads support implemented in Firefox Nightly. I've tried to comment what's going on in the commits and such, but at a high level the changes made here are: * A new transformation, living in a new `wasm-bindgen-threads-xform` crate, prepares a wasm module for parallel execution. This performs a number of mundane tasks which I hope to detail in a blog post later on. * The `--no-modules` output is enhanced with more support for when shared memory is enabled, allowing passing in the module/memory to initialize the wasm instance on multiple threads (sharing both module and memory). * The `wasm-bindgen` crate now offers the ability, in `--no-modules` mode, to get a handle on the `WebAssembly.Module` instance. * The example itself requires Xargo to recompile the standard library with atomics and an experimental feature enabled. Afterwards it experimentally also enables threading support in wasm-bindgen. I've also added hopefully enough CI support to compile this example in a builder so we can upload it and poke around live online. I hope to detail more about the technical details here in a blog post soon as well!
2018-10-04 20:00:23 -07:00
[lib]
crate-type = ["cdylib"]
[dependencies]
console_error_panic_hook = "0.1"
Bump to 0.2.63 (#2163) * Update `syn` version requirement Require latest version to fix issues with nightly. * Bump to 0.2.63
2020-05-27 10:07:18 -05:00
js-sys = "0.3.40"
Rewrite the parallel raytracing example with `rayon` One of the best parts about concurrency in Rust is using `rayon` and how easy it makes parallelization of tasks, so it's the ideal example for parallel Rust on the web! Previously we've been unable to use `rayon` because there wasn't a way to customize how rayon threads themselves are spawned, but [that's now being developed for us][rayon]! This commit uses that PR to rewrite the `raytrace-parallel` example in this repository. While not a perfect idiomatic representation of using `rayon` I think this is far more idiomatic than the previous iteration of `raytrace-parallel`! I'm hoping that we can continue to iterate on this, but otherwise show it off as a good example of parallel Rust on the web. [rayon]: https://github.com/rayon-rs/rayon/pull/636
2019-02-28 10:37:53 -08:00
rayon = "1.1.0"
rayon-core = "1.5.0"
Implement support for WebAssembly threads ... and add a parallel raytracing demo! This commit adds enough support to `wasm-bindgen` to produce a workable wasm binary *today* with the experimental WebAssembly threads support implemented in Firefox Nightly. I've tried to comment what's going on in the commits and such, but at a high level the changes made here are: * A new transformation, living in a new `wasm-bindgen-threads-xform` crate, prepares a wasm module for parallel execution. This performs a number of mundane tasks which I hope to detail in a blog post later on. * The `--no-modules` output is enhanced with more support for when shared memory is enabled, allowing passing in the module/memory to initialize the wasm instance on multiple threads (sharing both module and memory). * The `wasm-bindgen` crate now offers the ability, in `--no-modules` mode, to get a handle on the `WebAssembly.Module` instance. * The example itself requires Xargo to recompile the standard library with atomics and an experimental feature enabled. Afterwards it experimentally also enables threading support in wasm-bindgen. I've also added hopefully enough CI support to compile this example in a builder so we can upload it and poke around live online. I hope to detail more about the technical details here in a blog post soon as well!
2018-10-04 20:00:23 -07:00
raytracer = { git = 'https://github.com/alexcrichton/raytracer', branch = 'update-deps' }
Default all async support to `std::future` (#1741) This commit defaults all crates in-tree to use `std::future` by default and none of them support the crates.io `futures` 0.1 crate any more. This is a breaking change for `wasm-bindgen-futures` and `wasm-bindgen-test` so they've both received a major version bump to reflect the new defaults. Historical versions of these crates should continue to work if necessary, but they won't receive any more maintenance after this is merged. The movement here liberally uses `async`/`await` to remove the need for using any combinators on the `Future` trait. As a result many of the crates now rely on a much more recent version of the compiler, especially to run tests. The `wasm-bindgen-futures` crate was updated to remove all of its futures-related dependencies and purely use `std::future`, hopefully improving its compatibility by not having any version compat considerations over time. The implementations of the executors here are relatively simple and only delve slightly into the `RawWaker` business since there are no other stable APIs in `std::task` for wrapping these. This commit also adds support for: #[wasm_bindgen_test] async fn foo() { // ... } where previously you needed to pass `(async)` now that's inferred because it's an `async fn`. Closes #1558 Closes #1695
2019-09-05 11:18:36 -05:00
futures-channel-preview = "0.3.0-alpha.18"
Bump to 0.2.63 (#2163) * Update `syn` version requirement Require latest version to fix issues with nightly. * Bump to 0.2.63
2020-05-27 10:07:18 -05:00
wasm-bindgen = { version = "0.2.63", features = ['serde-serialize'] }
wasm-bindgen-futures = "0.4.13"
Implement support for WebAssembly threads ... and add a parallel raytracing demo! This commit adds enough support to `wasm-bindgen` to produce a workable wasm binary *today* with the experimental WebAssembly threads support implemented in Firefox Nightly. I've tried to comment what's going on in the commits and such, but at a high level the changes made here are: * A new transformation, living in a new `wasm-bindgen-threads-xform` crate, prepares a wasm module for parallel execution. This performs a number of mundane tasks which I hope to detail in a blog post later on. * The `--no-modules` output is enhanced with more support for when shared memory is enabled, allowing passing in the module/memory to initialize the wasm instance on multiple threads (sharing both module and memory). * The `wasm-bindgen` crate now offers the ability, in `--no-modules` mode, to get a handle on the `WebAssembly.Module` instance. * The example itself requires Xargo to recompile the standard library with atomics and an experimental feature enabled. Afterwards it experimentally also enables threading support in wasm-bindgen. I've also added hopefully enough CI support to compile this example in a builder so we can upload it and poke around live online. I hope to detail more about the technical details here in a blog post soon as well!
2018-10-04 20:00:23 -07:00
[dependencies.web-sys]
moved threadsafe futures implementation to a separate file, made updates after review
2019-06-17 20:25:25 +03:00
version = "0.3.23"
Implement support for WebAssembly threads ... and add a parallel raytracing demo! This commit adds enough support to `wasm-bindgen` to produce a workable wasm binary *today* with the experimental WebAssembly threads support implemented in Firefox Nightly. I've tried to comment what's going on in the commits and such, but at a high level the changes made here are: * A new transformation, living in a new `wasm-bindgen-threads-xform` crate, prepares a wasm module for parallel execution. This performs a number of mundane tasks which I hope to detail in a blog post later on. * The `--no-modules` output is enhanced with more support for when shared memory is enabled, allowing passing in the module/memory to initialize the wasm instance on multiple threads (sharing both module and memory). * The `wasm-bindgen` crate now offers the ability, in `--no-modules` mode, to get a handle on the `WebAssembly.Module` instance. * The example itself requires Xargo to recompile the standard library with atomics and an experimental feature enabled. Afterwards it experimentally also enables threading support in wasm-bindgen. I've also added hopefully enough CI support to compile this example in a builder so we can upload it and poke around live online. I hope to detail more about the technical details here in a blog post soon as well!
2018-10-04 20:00:23 -07:00
features = [
'CanvasRenderingContext2d',
'ErrorEvent',
'Event',
'ImageData',
'Navigator',
'Window',
'Worker',
'DedicatedWorkerGlobalScope',
'MessageEvent',
]
Reference in New Issue Copy Permalink