Hi, I noticed that in my application, every few seconds I have a longer frame and I don't know where the time is spent since it's a simple test application that doesn't do a lot at the moment. So I wanted to try CxxProfiler to figure out what is happening. The profiler is working fine, but is there a way to "record frames" (or any timespan) to get something like the profiler in HMH so that I could see which frame has the time spike and see the timings for that frame ? Is it something possible with a sampling profiler ? I guess it would require to add some kinds of markers in the code.
Detection of "frames" automatically most likely won't happen. It's too tricky and very specific use case, also it would require figuring out if application uses D3D, GL, Vulkan or something else. I want to keep things simple.
But I probably could add some kind of manual marker calls, so you can isolate the section you want to analyze. Not sure how well it will work, I don't think sampling profilers usually do this. Manually placing markers typically is done by instrumentation profilers.
I'll put this on my TODO list. Currently I'm working on better profiling mechanism - lower overhead and higher frequency. After that I'll look into adding markers.
One option could be have each sample copy a int from memory (from a user defined location) and then let you filter the samples based those copied values to for example focus only on frames that spiked and ignore frames that ran well.
Then the user code just need to do (*framenumber)++ each time you swapbuffers and then combine with own instrumentation to write out the numbers of frames that spiked.
Thanks. I found out were the time was spent (using __rdtsc) and it turns out that, now that I know what to look for, it's visible in CxxProfiler. It shows a ~2% time spent on an OpenGL call. Maybe having a min/max/avg time spent in a function (with some way to know how much time or calls are spent near min/max) would help without needing to add markers ?
But doing a simple "profiler" was easy and fast to do so all that might not even be needed.
With sampling profilers there really are no timing information or call count. They don't know how long or how many times function runs. They simply periodically take snapshot of call stack, then its up to you to analyze where did most of samples land. For timing/counts you really want instrumenting profiler.