You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here's a screenshot from the 0.7.2 manual showing platform-specific features :
0. Define where and how how to integrate it.
I think it's important to keep Tracy as an optional build config : not everybody will need it, and as is seems to need recent system software to be able to inspect. What about a 3rd build option : Debug, DebugTracy, Release ?
Later on, (special) release builds could also include it with a menu option to enable it, allowing remote debugging.
1. Integrate the Tracy client into Mosaic/ofxVP. Easy : add submodule, include 1 file and set compile flag to enable.
I have tested this with the Mosaic-Engine-Tester on a local branch. There seem to be some compile flags to set for better results (name stripping...). Also, they recommend not to run a client with a "debug config" regarding the associated compilation optimization flags.
This makes Tracy send real-time Mosaic debug info over a network socket. (local by default)
2. Compile the Tracy Profiler which allows to view & inspect the data.
This seems as the easiest way to get started, there are more possibilities such as recording data for non-real-time debugging, and on-demand remote debugging.
To build, you need to have a recent C++17 compiler. OSX 10.12.6 seems not possible. Maybe 10.13 with a more recent toolchain. I tried on a relatively old Linux Mint 16, with GCC 6.1, which should support C++17 but not with the needed extra features that Tracy uses. (Didn't try available workarounds yet.) So it looks like the Profiler needs a recent OS to be plug-and-play, compared to general OF/Mosaic capable setups.
3. Fine-tune Tracy to our specific needs. Playing around with it will tell us. Probably some macros to add to get the best results, plus the optional-recommended macros to implement.
4. Document usage.
The text was updated successfully, but these errors were encountered:
I got some time for this, it's quite easy to integrate but everything you collect is manual.
I'll definitely implement Tracy to facilitate #22. It will help optimize code, detect order-of-execution glitches, locks/mutexes that slow down threads, spot useless memory allocations, etc. And it might give an interactive insight of the inner mechanics of Mosaic for newcomers.
Here's 2 first screenshots to give an insight of what to expect.
Here, MosaicEngineTester ran on osx while the Tracy Profiler ran on Linux.
I'll add some details soon.
Side note: Tracy 0.8 brings a lot of multithreading-related updates, looks promising.
Edit: Current state:
Basic Tracy support has been added in c72c920 and 7de0753 . If I'm correct, all steps above still need to be checked, and some more Tracy features could be enabled.
There's also a Tracy Profiler Wiki with some initial instructions.
Opening a new issue for the Tracy integration, continuing the off-topic discussion from #22 .
So the idea is to integrate Tracy to facilitate debugging, with a focus on :
Here's a screenshot from the 0.7.2 manual showing platform-specific features :
0. Define where and how how to integrate it.
I think it's important to keep Tracy as an optional build config : not everybody will need it, and as is seems to need recent system software to be able to inspect. What about a 3rd build option : Debug, DebugTracy, Release ?
Later on, (special) release builds could also include it with a menu option to enable it, allowing remote debugging.
1. Integrate the Tracy client into Mosaic/ofxVP. Easy : add submodule, include 1 file and set compile flag to enable.
I have tested this with the Mosaic-Engine-Tester on a local branch. There seem to be some compile flags to set for better results (name stripping...). Also, they recommend not to run a client with a "debug config" regarding the associated compilation optimization flags.
This makes Tracy send real-time Mosaic debug info over a network socket. (local by default)
2. Compile the Tracy Profiler which allows to view & inspect the data.
This seems as the easiest way to get started, there are more possibilities such as recording data for non-real-time debugging, and on-demand remote debugging.
To build, you need to have a recent C++17 compiler. OSX 10.12.6 seems not possible. Maybe 10.13 with a more recent toolchain. I tried on a relatively old Linux Mint 16, with GCC 6.1, which should support C++17 but not with the needed extra features that Tracy uses. (Didn't try available workarounds yet.) So it looks like the Profiler needs a recent OS to be plug-and-play, compared to general OF/Mosaic capable setups.
3. Fine-tune Tracy to our specific needs. Playing around with it will tell us. Probably some macros to add to get the best results, plus the optional-recommended macros to implement.
4. Document usage.
The text was updated successfully, but these errors were encountered: