This value is not used for anything, it was just a number displayed in
the UI without much meaning to anyone.
Operations on the queue during early init may not work correctly, stopping
some programs from running past the calibration loop.
Instead of crashing when reaching the maximum number of source locations, display an empty source location ( with "???" everywhere).
Keeping the assert for discoverability of the limit in debug, but ensure profiler won't crash later on (or in release).
This PR does the following things:
- Allow to lock the highlighted thread using left mouse click or lane popup menu
- Add more descriptions for wait reasons in View::DecodeContextSwitchReason
- Stores the Wakeup CPU so that we may display it in the CPU data view
- `QueueThreadWakeup` now contains cpu and adjust info (currently unused). Fits in the padding, no struct size change.
- `QueueContextSwitch` now also contains thread priorities information (windows+linux) and CState (windows), but currently unused by the profiler. Fits in the padding, no struct size change.
- Fixes Linux `EventWakeup` which tries to remove PERF_SAMPLE_CALLCHAIN on the wrong member. Set the whole `perf_event_attr` explicitely instead.
- Fixes Windows ReadyThread event being dropped if triggered before the thread switches out (this is confirmed to be normal behaviour, probably due to thread being switched out but context switch actually happening later)
- Bumps tracy file version and protocol versions
PPQSort is supposedly quite fast: https://github.com/GabTux/PPQSort
More importantly, it does not depend on TBB fuckery, so there's no longer
a need to link with an external library that people may or may not have.
The NO_PARALLEL_STL option is out, as it was provided solely to deal with
TBB being not available. Sequential sorting is still used on emscripten.
When TRACY_NO_STATISTICS is defined, the assert in
GetGpuSourceLocationZonesCntReal will always get hit
as nothing is ever inserted in gpuSourceLocationZonesCnt
unless reading from a file.
Match the behavior with GetGpuSourceLocationZonesReal
to add the source location if it is missing.
With on-demand profiling we're very likely to connect in the middle of a
discontinuous frame and thus receive a frame end without any preceding
frame start. So don't error out in this case.
- Add a tool "tracy-edit" that allows loading a tracy capture, patching symbols and recompress the result
- Add offline symbol resolvers for linux (using addr2line) and windows (using dbghelper)
For some unknown reason, local threads may be attributed to an external
process (at least when profiling on Windows). This causes some problems,
for example the CPU usage graph may show that CPU is pegged by some other
program, when it reality it is the profiled program that uses the CPU time.
Workaround by checking first, if the thread id is known to be local by the
profiler, i.e. if there were user-generated events originating from it.
This still leaves other things, such as the CPU data list, being wrong,
but the CPU data is meant to show raw TID -> PID mapping. If the source
data is wrong, there's not much to fix here.
