Not seeing any info other than frame times in profiler

[universeindex]

Hello,

I'm experiencing an issue where the profiler is not displaying any info at all other than the frames from FrameMarkStart/End. I've tried a copy I built from source manually and the profiler from vcpkg, from which I pull the client library as well. I've checked that the versions match (0.13.1) and I am building my project with debug symbols (-O3 -g).

What's strange however is that in the exact same repository, the issue is not present on my other laptop. Profiling works completely fine there with the version of Tracy from the AUR (still 0.13.1).

I'm clueless as to why this is happening... any help is greatly appreciated! Please let me know what other data/logs I should attach, I'm not really sure what's relevant.

Specs (of machine with issue):

• Gentoo (gcc, tkg-bore 6.18.8 kernel)
• AMD Ryzen 7 5800X
• 32gb DDR4
• RX 6600

Specs (of laptop without any issues):

• Arch (6.12 LTS kernel)
• Thinkpad X1 Carbon 8th Gen
• Intel Core i7-10610U
• 16gb LPDDR3
• Integrated graphics

Attempting to profile on my desktop, which does not work Profiling same application on my laptop, no issues

[wolfpld]

Does the issue persist if you build with TRACY_DELAYED_INIT?

[universeindex]

Yes. I should have mentioned though, the documentation says to include TracyClient.cpp in the build, but I am using this from vcpkg, which only supplies a static library for the client, so I'm linking that instead. Could this be problematic?

I now realize messages are working fine as well

P.S. I'm about to be gone for a few hours so sorry if I don't respond for a bit

[wolfpld]

For a variety of reasons, using a pre-made static library someone made is a bad idea.

[universeindex]

compiled from source as intended by the documentation, still yielding same results
It is now showing 10 threads named with random numbers though, before there were 0 threads listed, not even the main thread

[Lectem]

Mmhhh... AMD ryzen again.
can you give us the output of
cat /sys/devices/system/clocksource/clocksource*/current_clocksource
And
cat /proc/cpuinfo | tr ' ' '\n' | sort -u | grep -i "tsc"?

We've had issues with some ryzen processors, similar to RPCS3/rpcs3#16545

[universeindex]

will do as soon as i can, not home at the moment though :(

[universeindex]

have Ryzen issues been a thing on Windows, too? or just Linux systems mostly? I could have a friend test on their system, but they are running Windows

[universeindex]

As of a few minutes ago this started occurring on my laptop which was previously unaffected too, since you mentioned the kernel clocksource I switched it from tsc to acpi_pm (the only other available option) and that immediately fixed it, will try this on my Ryzen system (and paste the output of those commands of course) as soon as I get back home

[universeindex]

cat /sys/devices/system/clocksource/clocksource*/current_clocksource returns tsc,
cat /proc/cpuinfo | tr ' ' '\n' | sort -u | grep -i "tsc" returns

constant_tsc
nonstop_tsc
rdtscp
tsc
tsc_scale

[Lectem]

Definitely looks like a clock issue.

We currently do not check that the clock source used by the system tracing is indeed the TSC (would need to look at cat /sys/devices/system/clocksource/clocksource0/current_clocksource), and assume it is unless TRACY_HW_TIMER is undefined or HardwareSupportsInvariantTSC returns false. On buggy TSC systems, the kernel may fall back to other clock sources by default if it consider TSC is not stable enough.

The weird part is that you said changing clock from tsc to acpi_pm fixed it? constant_tsc
nonstop_tsc should be enough but may still be unreliable.

Can you try dmesg | grep -i tsc ?

[universeindex]

The weird part is that you said changing clock from tsc to acpi_pm fixed it?

That was on my thinkpad, which has an intel CPU, and started experiencing the same issue the other day on TSC. (It was unaffected when I first made this issue.)

On the same laptop with acpi_pm still enabled it returns nothing, I'll run it on my Ryzen system once I have access again

(I generally am away from the Ryzen system until 3:30PM EST, but I have a long weekend starting tomorrow. Perhaps I might port forward it to SSH)

[Lectem]

Could you try the branch fix/detect-tsc-issues ? https://github.com/wolfpld/tracy/tree/fix/detect-tsc-issues

[universeindex]

Can you try dmesg | grep -i tsc ?

$ doas dmesg | grep -i tsc
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] tsc: Detected 3792.952 MHz processor
[    0.421985] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x6d58ad86300, max_idle_ns: 881590646351 ns
[    0.632045] clocksource: Switched to clocksource tsc-early
[    1.663236] tsc: Refined TSC clocksource calibration: 3792.873 MHz
[    1.663241] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6d5818a734c, max_idle_ns: 881590694765 ns
[    1.663262] clocksource: Switched to clocksource tsc
[    4.651930] kvm_amd: TSC scaling supported
[    4.736690] vboxdrv: TSC mode is Invariant, tentative frequency 3792873862 Hz

Could you try the branch fix/detect-tsc-issues ? https://github.com/wolfpld/tracy/tree/fix/detect-tsc-issues

This definitely fixed it. Works great with this version

https://github.com/user-attachments/assets/dff2915c-8f02-41c5-a226-d817723857a2
release 0.13.1 ^

https://files.catbox.moe/olsb58.mp4
fix/detect-tsc-issues ^

(edit: uploaded the wrong video)

[Lectem]

Interesting... That means kernel detects invariant tsc at boot but something goes wrong later on?
Can you build with TRACY_VERBOSE and check what CheckLinuxPerfTscConsistency outputs?
or maybe just step using a debugger.

Sadly this runs before tracy messages can be sent so you wouldn't see them in the messages list, hence the TRACY_VERBOSE (which outputs to standard output)

Thanks!

[universeindex]

What should I be looking for exactly? I don't see anything related to TSC in stdout

stdout

perf_event_paranoid: 2
tracefs path: /sys/kernel/debug/tracing
sched_switch id: -1
sched_waking id: -1
drm_vblank_event id: -1
Setup software sampling
  Probed precise_ip: 0
  Probed precise_ip: 3
  No access to kernel samples
  Target 0 ok
  Target 1 ok
  Target 2 ok
  Target 3 ok
  Target 4 ok
  Target 5 ok
  Target 6 ok
  Target 7 ok
  Target 8 ok
  Target 9 ok
  Target 10 ok
  Target 11 ok
  Target 12 ok
  Target 13 ok
  Target 14 ok
  Target 15 ok
Setup sampling cycles + retirement
  Probed precise_ip: 0
  Target 0 ok
  Target 1 ok
  Target 2 ok
  Target 3 ok
  Target 4 ok
  Target 5 ok
  Target 6 ok
  Target 7 ok
  Target 8 ok
  Target 9 ok
  Target 10 ok
  Target 11 ok
  Target 12 ok
  Target 13 ok
  Target 14 ok
  Target 15 ok
  Target 0 ok
  Target 1 ok
  Target 2 ok
  Target 3 ok
  Target 4 ok
  Target 5 ok
  Target 6 ok
  Target 7 ok
  Target 8 ok
  Target 9 ok
  Target 10 ok
  Target 11 ok
  Target 12 ok
  Target 13 ok
  Target 14 ok
  Target 15 ok
Setup sampling CPU cache references + misses
  Probed precise_ip: 0
  Target 0 ok
  Target 1 ok
  Target 2 ok
  Target 3 ok
  Target 4 ok
  Target 5 ok
  Target 6 ok
  Target 7 ok
  Target 8 ok
  Target 9 ok
  Target 10 ok
  Target 11 ok
  Target 12 ok
  Target 13 ok
  Target 14 ok
  Target 15 ok
  Target 0 ok
  Target 1 ok
  Target 2 ok
  Target 3 ok
  Target 4 ok
  Target 5 ok
  Target 6 ok
  Target 7 ok
  Target 8 ok
  Target 9 ok
  Target 10 ok
  Target 11 ok
  Target 12 ok
  Target 13 ok
  Target 14 ok
  Target 15 ok
Setup sampling CPU branch retirements + misses
  Probed precise_ip: 0
  Target 0 ok
  Target 1 ok
  Target 2 ok
  Target 3 ok
  Target 4 ok
  Target 5 ok
  Target 6 ok
  Target 7 ok
  Target 8 ok
  Target 9 ok
  Target 10 ok
  Target 11 ok
  Target 12 ok
  Target 13 ok
  Target 14 ok
  Target 15 ok
  Target 0 ok
  Target 1 ok
  Target 2 ok
  Target 3 ok
  Target 4 ok
  Target 5 ok
  Target 6 ok
  Target 7 ok
  Target 8 ok
  Target 9 ok
  Target 10 ok
  Target 11 ok
  Target 12 ok
  Target 13 ok
  Target 14 ok
  Target 15 ok
Ringbuffers in use: 112
Failed to increase SysTraceWorker thread priority!

and some other Overriding dlclose for ... with some libvulkan libraries