the long term goal of this demo is to see if:
(a) we can get stronger coupling between two cores than with multi-core-inverter.
(b) we can get amplification by using a charge-pump like concept.
(c) we can construct a *working* multi-core-inverter from this.
- these tools shouldn't need access to coremem internals.
- lifting them out reduces some dependencies in coremem-the-library.
- separation allows faster iteration in the coremem library while
temporarily breaking the post-processing tools (specifically,
those tools could take deps on a specific coremem version and thereby
we split the update process into two, smaller steps).
this achieves a few things:
- trivial way to get these shipped as the default nix package
- better dependency management
- ability to split large applications into multiple files
the README probably needs some updating.
this was a hack from earlier where we needed a different lib types
based on whethere we were targeting the native host or the spirv
backend.
at some point we no longer needed different lib types. so the _lib piece
is unnecessary.
this solves an issue in the Nix build, where managing multiple
Cargo.lock files is otherwise tricky. it causes (or fails to fix?) an adjacent issue where
the spirv builder doesn't seem to have everything it needs vendored.
this means that we unconditionally build the spirv runner,
and hence it requires that the user setup the proper rustc toolchain,
etc. may want to hide this behind a feature flag.
this resolves the issue where Nix builds would segfault when trying to
initialize wgpu -- *possibly* because of multiple dynamically linked
versions of LLVM sitting in the mix (hence, dylib => lib).
also add the Cargo.lock files to version control, since the spirv stuff
is highly dependent on specific versions of dependencies.
TODO: update wgpu to 0.12
i.e. `cargo test`, `cargo bench`, `Cargo run --release --bin csv` all
pass. Previously they couldn't all pass.
Also, change the benchmarks so that spirv code is compiled only once per
bench.
Early results have the spirv backend taking twice as long per-frame as
the cpu backend for a 80x80x80 sim.
Git/crates.io version of plotly had some bugs which were patched locally.
But this added extra maintenance and I haven't used the plotly renderer for some time.
So, remove plotly & reintegrate it only when we need it.
It's CBOR, which seems to pack not so efficiently (250*250*20 * 12
floats takes 400 MB per frame, whereas this many doubles could pack into
120 MB). serde_cbor also seems to be extremely slow: taking multiple
minutes per frame. This could be parallelized to be less problematic
though (it already is -- just bump the parallelism).
Might be worth testing other formats.
NOTE: this requires you to clone `plotly`, copy the
`plotly_kaleido` folder to be adjacent to this one, and then run `cargo
build --release` from within that plotly_kaleido folder.
colin