rust-gamedev/wg

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!

kvark commented

Math competition raises - https://crates.io/crates/ultraviolet
cc @termhn

We might want to talk to the embedded WG about allocator use cases too.

kvark commented

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)).

fu5ha commented

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

  • @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,

fu5ha commented

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

@Lokathor did you have recordings of the second meeting?

Karl did.. uh, and that's @kabergstrom on github I guess.

Sometimes I wish out Google Hangouts names matched our GitHub names.