`ZoneNameF(fmt, ...)` was error-prone: if the format is inconsistent
with arguments, the code compiled fine without errors or warnings.
Use gcc/clang `__attribute__((format(printf, fmt_idx, arg_idx)))`
function attribute, so that `ZoneNameF(fmt, ...)` can now check
at compilation time the consistency between the format and the
arguments.
See https://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Function-Attributes.html
In Profiler::DequeueSerial if AppendData fails part way through m_serialDequeue then the elements could be freed again in Profiler::ClearSerial, which leads to memory corruption in rpmalloc.
This provides some instructions and tips for the manual. Also:
* Made the calibration feature a CMake option
* Cleaned up some minor code issues
* Fixed an issue with the calibration
* Incremented patch number
Synchronizes the GPU timeline periodically. This is needed to counter
network time updates that cause drift in the GPU and CPU timeline.
Signed-off-by: Eric Eaton <erieaton@amd.com>
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.
[`/DELAYLOAD`](https://learn.microsoft.com/en-us/cpp/build/reference/delayload-delay-load-import?view=msvc-170) only works with exported functions, not variables (as it patches thunks after the first load).
So instead of using exporting a pointer for `___tracy_RtlWalkFrameChain`, make it a function that will call said pointer. This only adds a `mov`+`jmp` instructions in optimized builds to the call, which is negligible compared to the actual cost of RtlWalkFrameChain. This also does not affect the reported callstack since it will use a `jmp` without touching the stack, so `___tracy_RtlWalkFrameChain` won't appear in the capture stacktrace.
`sched_wakeup` notifies about the kernel saying it will be waking up the thread, not the reason for the actual wakeup. This only allows to measure the scheduling latency, not the full wake up latency.
Instead, use `sched_waking` which is triggered on the ring of the CPU and thread responsible for the wakeup. `target_cpu` contains the cpu on which the thread will be woken up.
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
