colin
859a7f8b18
rename `FullyGenericMaterial` -> `GenericMaterial`
...
this naming was an artifact from the separate CPU/GPU material implementations.
2022-12-07 09:46:33 +00:00
colin
f61c0aeb00
spirv_backend: document why we don't support f64
2022-08-14 19:15:58 -07:00
colin
45d2de29c6
rename 'coremem_types' -> 'coremem_cross' to better reflect its purpose
2022-07-28 15:40:23 -07:00
colin
07dfb9d852
spirv: add R32 support to the GPU code
2022-07-28 13:18:14 -07:00
colin
568d61c598
spirv: remove the Optionality around entry points: compute them statically with traits
2022-07-27 12:32:43 -07:00
colin
baaeeb9463
spirv_backend: no need to re-export glam
2022-07-27 12:13:01 -07:00
colin
d93d14d260
spirv_backend: use RuntimeArray to remove all this UnsizedArray stuff
2022-07-26 15:58:23 -07:00
colin
8a16a5ce30
lift SimMeta from spirv_backend -> coremem_types
2022-07-25 00:52:11 -07:00
colin
15aaa3e893
move spirv_backend/sim.rs -> coremem_types/step.rs
2022-07-25 00:40:27 -07:00
colin
5490634fe7
move `Optional` out of spirv_backend and into coremem_types
2022-07-25 00:35:04 -07:00
colin
9c7ef7ec88
spirv_backend: split the array operations out of sim.rs -> adapt.rs
2022-07-25 00:28:03 -07:00
colin
8ab89640f2
spirv_backend: split out some of the spirv entry point adapters into `adapt.rs`
2022-07-25 00:21:20 -07:00
colin
ebd2762d7a
spirv: sim: adjust so `Step{E,H}Context` does not use `ArrayHandle`
...
the specific way to accomplish this is touchy.
see <https://github.com/EmbarkStudios/rust-gpu/issues/312#issuecomment-738824131 >:
> So I'd say placing any of the spirv_std::storage_class types into an aggregate (including capturing it in a closure) is unsupported for now
in our specific case, we can't return a tuple where one element is a `&`
to a spirv Input, and another element is a `&mut` to a spirv Output.
when we have a struct, it can enclose either ONLY inputs,
or ONLY outputs -- not a mix.
i'm not 100% on how the Serialized stuff works, since it appears to
violate that. i guess that's exactly what this ArrayHandle stuff
achieves though.
2022-07-24 22:57:41 -07:00
colin
05f5f75dd3
spirv: remove the ArrayHandleMut artifacts in `Step{H,E}Context`
...
this will make it easier to reuse these blocks on the CPU side.
2022-07-24 22:17:44 -07:00
colin
4a6a43fb31
plumb the R type parameter through spirv code
2022-07-22 16:21:03 -07:00
colin
66ccbd1ada
spirv: remove `mat.rs` and reuse coremem_types::mat everywhere
2022-07-22 15:22:09 -07:00
colin
716e0e12b4
move Ferroxcube3R1MH from spirv_bindings to coremem_types::mat
2022-07-18 15:33:47 -07:00
colin
7d2a3baadc
spirv: migrate Material trait to types, and parameterize by R
2022-07-18 14:33:09 -07:00
colin
35251f5a7f
coremem_types: move Vec3u under the vec:: namespace
...
it's conceivable that Vec3u could be merged with Vec3 someday.
best to keep them in the same namespace, to make any such effort easier.
2022-07-18 14:23:35 -07:00
colin
19f00c9076
spirv_backend: remove Vec3Std and use coremem_types::Vec3 everywhere
2022-07-18 13:51:11 -07:00
colin
d7d8be62d1
spirv_backend: remove UVec3Std in favor of Vec3u
2022-07-18 13:39:15 -07:00
colin
4378f33eb9
spirv_backend: strip out the glam stuff, except for the lib.rs interface
2022-07-18 01:48:19 -07:00
colin
5b99d30cda
restructure this multi-crate project to use Cargo's "workspace" feature
...
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.
2022-07-05 17:34:21 -07:00
colin