-
Notifications
You must be signed in to change notification settings - Fork 706
Parallelize space views #1325
Copy link
Copy link
Closed
Labels
🎄 tracking issueissue that tracks a bunch of subissuesissue that tracks a bunch of subissues📉 performanceOptimization, memory use, etcOptimization, memory use, etc📺 re_vieweraffects re_viewer itselfaffects re_viewer itself🔺 re_rendererrendering, graphics, GPUrendering, graphics, GPU🕸️ webregarding running the viewer in a browserregarding running the viewer in a browser
Metadata
Metadata
Assignees
Labels
🎄 tracking issueissue that tracks a bunch of subissuesissue that tracks a bunch of subissues📉 performanceOptimization, memory use, etcOptimization, memory use, etc📺 re_vieweraffects re_viewer itselfaffects re_viewer itself🔺 re_rendererrendering, graphics, GPUrendering, graphics, GPU🕸️ webregarding running the viewer in a browserregarding running the viewer in a browser
The Rerun viewer needs to run in Wasm on the browser. This limits our threading ability.
std::threadis, for instance, not available. At the same time we want to make sure our viewer achieves good frame rate when compiled natively.Parallelism on native, with single-threaded fallback on web
rayonis the go-to Rust crate for fine-grained parallelism. It is commonly used by library crates (behind a feature flag).Currently
rayondoes not run in wasm in the browser, but this might change soon:In the mean-time we can also define our own helpers for parallelism, e.g.:
See #1041 for an experiment along these lines
Parallelism on wasm32
With a bit of work, one can spawn wasm32 threads in the browser with shared memory. Unfortunately, this requires a nightly compiler (for
-Z build-std=std,panic_abort).I think it could be fine for use to rely on the nightly compiler for just wasm32.
I suggest we keep this use-case in mind, but focus on the native performance for now.
Se also: