Meeting: Nov 13, 2019
Lokathor opened this issue · 15 comments
Action Items From Last Week:
- @kabergstrom: help gather more info about allocator use cases
- @kvark: ask
granka
about custom allocators progress (also generics?) - Debug performance (mostly generics)
- AreWeGameYet status
Post more topics to discuss!
Math competition raises - https://crates.io/crates/ultraviolet
cc @termhn
We might want to talk to the embedded WG about allocator use cases too.
My task is done in #60 (comment)
AreWeGameYet status
I guess this was mostly resolved in #64 (comment)? The only open question is w.r.t. the domain itself (#64 (comment)).
I won't be able to make the meeting because I'll be in the middle of class, but if anyone has questions etc about ultraviolet
, please feel free to ping me on discord/github/etc.
Will anyone else be joining tonight's meeting? Remember, DST "moved" the meeting ahead one hour.
I forgot about the time change and told people itd be an hour from now
Participants:
@parasyte
@msiglreith
@kabergstrom
@Wodann
-
@kabergstrom spoke with Embark members at RustFest:
- Most desired allocator use case: scratch buffer / linear bump allocator that is resetable (e.g. frame allocator or double frame allocator)
- Reducing Rust compile time / performance decrease by avoiding crates that heavily rely on generics (seem happy with that solution for now)
- Embark's cargo-deny allows you to maintain a list of banned crates and licenses
- Thread local storage doesn't work across shared library (e.g rayon)
- It would be good to have a standardised API for sharing thread pools (rayon, tokio, etc. all have their own thread pool)
- It could be that crates exist that fill their needs, but end up being banned due to aforementioned limitations. In that case they might just make their own implementation that does not have these issues.
-
To avoid fragmentation, it would be good for the WG to focus on standardizing more common concepts like RawHandle (e.g. ThreadPool, etc.)
-
AreWeGameYet has been transferred to the WG by @ozkriff, but we still need to obtain domains
-
@msiglreith opened an issue about input handling (#69) as Rust support is lacking
- Some bindings for existing C libraries are available (e.g openxr)
- @msiglreith is looking into creating a native Rust input mapping crate, but unsure where the ecosystem is going. What's winit going to do?
- Call for review on his ecosystem overview to hear other people's opinions
-
audio and input are neglected topics within gamedev
- Nannou got a MOSS grant (partially) to work on cpal (https://nannou.cc/posts/moss_grant_announce)
-
@kabergstrom released the serde-diff crate. Possible use cases are Unity-style prefabs, undo-redo history systems.
Requested to be posted here by Lokathor: https://github.com/microsoft/mimalloc
The default allocator on Windows uses HeapAlloc, which uses a mutex internally when allocating. Using a custom allocator can really improve performance for multi-threaded applications,
Also, for a bump allocator today, though must reimplement collections https://docs.rs/bumpalo
Reminder from the meeting: link times can be improved with the llvm linker in many cases. instructions here: #50
I brought this up in the meeting: if you're on Windows, this is by far the best step-through debugging experience I've managed to find: https://www.microsoft.com/en-us/p/windbg-preview/9pgjgd53tn86?activetab=pivot:overviewtab
Here's the recording of the first meeting: https://www.youtube.com/watch?v=V8gpUXguLuY
Karl did.. uh, and that's @kabergstrom on github I guess.
Sometimes I wish out Google Hangouts names matched our GitHub names.