userDaniel Pcancel

682 Commits over 215 Days - 0.13cph!

Today
Clean: removing hanging meta files that I've commited earlier Tests: open editor
Today
Merge: from main Tests: none
Today
Merge: from hackweek_serverprofiler_memory - Records allocations from all threads - Displays allocations on separate thread tracks + a graph of total allocations per thread - Allocations now have last/current method, allocated type and size in the mark's "arguments" - see "current selection" in perfetto - Allocations now also duplicate in the executing thread to make it easier to spot where exactly in the method it was allocated. - Graphs of working set and virtual set memory for the entire process Tests: multiple snapshots in editor on Craggy, single in standalone debug linux server via WSL on 3k procgen map, single in standalone release windows server on 3k procgen map with a harmony mod
Today
Clean: removing unnecessary using Tests: compiled in editor
Today
Clean: deleting empty folder Left-over from the old merge that I didn't clean up properly Tests: none
Today
Update: ServerProfiler - switching to release libs (10b88e05) Tests: tested stanadlone linux server in debug on a 3k procgen map, windows standalone server in release on a 3k procgen map and a harmony mod
Today
Merge: from main Tests: none
Today
Clean: remove a couple unnecessary TODOs Tests: none, trivial change
Today
Clean: ServerProfiler - less IntPtr, more Native.MonoMethod Think I didn't have enough sleep when I was writing it at first. Tests: exported snapshot in editor on Craggy
Today
Update: ServerProfiler - emit the current/last managed method when recording an allocation - using debug binaries (10b88e5) Should reduce/eliminate the need to manually hunt for the allocation in the methods view. Tests: snaspshot in editor on Craggy
Today
Update: ServerProfiler - emit a graph of per-thread total allocation size - Main thread reset the counter every frame, worker threads over their entire lifetime. This makes it easier to see at a glance how much we allocate per frame/thread. Tests: exported snapshot in editor on Craggy
Yesterday
Update: ServerProfiler - update binary exporter & viewer to handle new Allocs format - Made ProfileBinViewer's search work with alloc's names Tests: made a debug export of Craggy in editor, then opened it in the ProfileBinViewer
Yesterday
Clean: ServerProfiler - remove not supported thread sorting keys Tests: none, trivial change
Yesterday
Update: ServerProfiler - remove the class name and duplicate size into args of a mark - They are part of the "arguments" view when you click on the allocation mark - Also assigned all allocations the "A" category so that they can be easily filtered out via queries Turns out cname (controlling colors) is also unsupported via legacy json import (see issue https://github.com/google/perfetto/issues/208 and linked ones), so if we modify the name, we lose the uniform yellow color for allocations that makes it easier to spot. This also allows to run queries on top of these args more easily. Tests: exported snasphot from Craggy in editor
Yesterday
Update: ServerProfiler - track and emit allocation class and array size - using debug binaries (9f4a07f8) Will need to update binary export and fix the bin viewer tool Tests: snapshot on craggy in editor
Yesterday
Bugfix: ServerProfiler - properly name worker thread's allocation track - Another one of the "did it right first time, simplified, now it's borked" cases Tests: snapshot in editor Craggy
Yesterday
Update: ProfilerExporter.JSON - emit virtual memory graph Tests: exported on craggy
Yesterday
Optim: ServerProfiler - properly avoid false-sharing when recording memory state when taking a snapshot - using debug binaries (b445081f) Should be a smidge faster faster in multithread allocation-busy scenarios. Tests: took a snapshot on craggy
Yesterday
Update: ServerProfiler - emit working set as KB instead of Bytes - Also pre-allocate extra size in string builder to account for the memory counters. KB are easier to spot on the graph changing(not really on perfetto's Values view, better on delta view) Tests: exported in editor on Craggy
2 Days Ago
Update: ServerProfiler - vizualize process working set memory - using debug binaries for now(bc3e74cd) Need to add virtual set as well and test standalone servers(Win and Linux) Tests: in editor on craggy.
2 Days Ago
Bugfix: ProfilerExporter - filter out worker thread marks that are before the frame start It was originally correct, but in previous commit I simplified the code, thus breaking it. This restores it. Tests: none, as currently too many changes present in workspace - will test later
3 Days Ago
Update: ServerProfiler - emit fake "Allocation" threads and duplicate allocation marks there - Also updated the whole buffer estimation to take into account these metadata marks - Added support for naming and sorting thread tracks Well, they do appear, but the thread_sort_index is ignored by perfetto(see https://github.com/google/perfetto/issues/555). Might finally bite the bullet and write a protobuf exporter, but afraid that it'll be more expensive to run and won't compress as well. Tests: exported a snapshot from editor
3 Days Ago
Update: ServerProfiler - enable safety checks by default - Also prefixed error logs to make it easy to identify where it came from Tests: did 6 exports in editor, no false-positives
3 Days Ago
Bugfix: ServerProfiler - don't emit thread tracks with only allocations in them - Handle "legal" case where we don't have any method marks on worker threads after frame start timestamp - Handle "legal" case where we get a thread profile for a thread that was stopped before the frame start - Handle "legal" case where we get empty thread profiles due to method filtering - Dead func removal This can be a controversial choice, as allocations do happen there, but it's not something we can interact with because there's not enough helpful information about them(for example, what if we filter out entire thread methods?). Tests: did 4 exports, wasn't able to find weird allocation records on different threads.
3 Days Ago
Update: ServerProfiler - Track allocations on all threads The display of this information is still abysmal - need to figure out how to make it better. Tests: took snapshots both in editor and in standalone server builds (win + linux). Hacked a version that used to crash, but current changes don't anymore.
4 Days Ago
Update: Impllement GamePhysics.HandleIgnoreCollisions as a batch - extended TerrainCollision to support batching - extended WaterColllision to support batching There's still more improvements that can be done (translating into burst jobs and better job-graph building), but currently the goal is to translate more of code into batch form away from singular. Tests: none, it's not hooked up yet - will explore writing unit tests next-ish
7 Days Ago
Bugfix: read back from the right array of heights after sampling ocean - Reported by new unit tests Tests: ran water-related unit tests - now they pass
7 Days Ago
Bugfix: Make sure WaterLevel tests run full simulation path during unit testing Previously it was earlying out during GetWaterLevel Tests: ran the new tests, they report an issue that I need to fix
7 Days Ago
Update: missing meta files from merge Submitting for now, but should nuke once back on main Tests: none, trivial change
7 Days Ago
Merge: from main - Skipping a couple meta files for empty folders, will submit them separately Tests: booted editor for import
7 Days Ago
Clean: removing unused WaterFactorForPlayer that didn't return WaterInfo Tests: compiles in editor in SERVER+CLIENT mode
7 Days Ago
Bugfix: ensure we cache WaterInfo for players that use various vehicles Some vehicles have custom logic to check how submerged the player is, and we would miss the water info taht was used to calculate it. Tests: tested via DPV - submerged factor was 1 and waterinfo was valid (before it would report factor of 1, but invalid waterinfo).
7 Days Ago
Update: BaseMountable.WaterfactorForPlayer can now return WaterInfo - allows further reusing of the same water info down the line I actually need it to make sure all our player's cached values are correct - will fix in next submit. Tests: none (as it's not in use in this CL)
7 Days Ago
Clean: fixing profiling scope name Tests: none, trivial change
7 Days Ago
Update: FinalzieTickParallel now uses batched WaterFactors query - had to add more fork-join-style code to deal with batching This allows us to sample water information for all relevant players as a burst job (and there's further untapped potential). Next up is trying to batch and jobify physics checks. Tests: played in a solo session with parallel processing enabled - running, driving, swimming worked normal. Played back all of my server demos with analysis enabled - no new violations detected.
7 Days Ago
Bugfix: use the right allocator for a waterlevels batch - This revealed that we have an Application.isPlaying check that prevented this from being detected via unit tests Tests: ran unit tests (but they're useless in this case), ran all demos that use the new code(yet to submit) - no more exceptions
8 Days Ago
Update: able to get WaterFactors for players as a batch operation - internally splits players into sequential queries(vehicles, parenting) and a batch query Another building block covered, I should be able to rewrite caching of water factors step of FinalizeMove(next submit). Tests: just editor compilation, I need to adapt rest of code to work with it.
8 Days Ago
Update: BufferList - new utility methods - Resize - to explicitly control internal capacity - ContentSpan, ContentReadOnlySpan - shortcuts to create a ro-/span over the active part of the buffer Need both as I'm using it further in batched player processing operations Tests: none, trivial changes.
8 Days Ago
Bugfix: setup water query params fully 0s are valid, but it caused the sampling positions to lean towards origin Tests: rerun the WaterLevel tests
8 Days Ago
Clean: removing unnecessary logging Tests: none, trivial change
8 Days Ago
Update: Able to grab WaterInfos as a batch - Added a test to validate it returns same results as non-batched - Made sure WaterLevel tests work in an initialized scene It's not fully converted to a batch - there are a couple calls internally that are yet to be converted (game physics and the like). Tests: ran the WaterLevel tests
9 Days Ago
Update: WaterLevel supports getting water heights for a batch of positions - added a test to make sure batched produces same results as the singular version Tests: ran the new unit tests
9 Days Ago
Update: Putting in a skeleton of logic for Parallel update - Duplicated BasePlayer.ServerUpdate and FinalizeMove - rewrote to work on a list of players - Added `server.useplayerupdatejobs` to control whether to use parallel or serial processing of players, default to off New code doesn't really do much, just organized in a way to start working on parallel bits. I feel like I'm about to depart on a year-long journey into the jungle. Tests: compiled in editor in SERVER-CLIENT mode
10 Days Ago
Update: ServerDemoPlayer - use time as progress indicator, instead of bytes of stream consumed - Also removed a couple TODOs that are either done or decided to drop In the previous version there would be no progress report until the next timestamped messages was reached - this is confusing UX. Tests: played back the demo where I connect 15 seconds in, causing a jump from 0% to 18% progress. Now it's gradual.
10 Days Ago
Update: DemoServer - don't try to launch it in SERVER+CLIENT mode That's a can of worms I don't want to deal with right now Tests: none, trivial change
10 Days Ago
Clean: DemoServer - allow configuring the server for demo playback Tests: none, trivial change
10 Days Ago
Update: ServerDemoPlayer - added error logging on hierarchy desync Since some messages are handled by hand, it's possible things can go wrong in the future - this should catch it. Tests: played all demos I have, no errors reported
10 Days Ago
Clean: removing no longer needed method - Was previously part of ClientDemoPlayer Tests: builds in editor in SERVER mode
10 Days Ago
Bugfix: ServerDemoPlayer - handle player rotation properly Tests: played back a new vehicle demo, and an old demo 2p where the player was shot in the head - no violations, no entity stutters
20 Days Ago
Bugfix: ServerDemoPlayer - replicated polayer now follows demo's trajectory - Also added more detialed logging of position messages Decided to stop avoiding syncing player's position to outgoing messages, as there's weird teleport in the recorded demo. But at least now it works as expected. Tests: Played back the longer 2 player demo - all good. Playerd back the known short demo with violations - still present, so also good.