aszkid / milsim Goto Github PK

We call Hermes::clear(), which deletes the message queue, at every main-thread update tick (fixed 60Hz rate). In parallel, the render thread runs for a single render-frame, so it sees the message queue disappear a few times. It's a miracle that we are catching (from the render-thread perspective) all messages we care about.

Fix: have a double-buffered message queue. Pushing a message writes to the "hot" (writing) queue, while reading messages fetches from the "cold" (reading) queue. Hermes::swap() should clean the cold queue, and be assigned std::move(hot_queue). This has benefits and drawbacks.

The good: no synchronization. The queue implementation we use is lock-free to begin with, and no read-write locks are necessary using double-buffering.
The bad: one frame (16ms) of reaction delay. Game entities react to events that happened on the previous frame.

Looking at my system's task manager, it seems like a fresh milsim instance (no assets LOADED, pipeline created) acquires 0.2MB of memory every second or so, while truly doing nothing.

That's clearly bad. Look it up.

In the same vein as #1, sanitize flags detect a bunch of indirect leaks related to my radeongpu open-source driver.

Indirect leak of 4 byte(s) in 1 object(s) allocated from:
# 0 0x7fe7b4894b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)
# 1 0x7fe7acc542c3 (/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so+0x2912c3)

etc, which add up to

SUMMARY: AddressSanitizer: 365299 byte(s) leaked in 758 allocation(s).

As far as I know, we clean up all OpenGL resources, and I have seen these reports since I added sanitize flags to the build.

In

we have a potentially dangerous instruction. This is called from the render thread, while Alexandria essentially runs on the main thread, so we might be inserting or removing assets while the render thread requests for one.

We should either change the architecture of things or synchronize access to Alexandria (and in either case, eventually move Alexandria to its own "asset" thread).

Adding and removing assets is not such a common thing (it's in our best interest to batch loading at start-up), but I imagine that accessing them is a relatively frequent task. An initial implementation will of course use a simple mutex, until further benchmarking.