Hi,
we're using the new TracySectionEnter/TracySectionLeave API to mark logical sections in a frame (like "game simulation", "texture streaming" and so on - all of which consists of multiple jobs on different threads, so the section API is helpful in giving us an overview, what part of a frame we're looking at and what parts of the frame run in parallel to one another. We also have some larger sections like "loading screen", which span over many frames. In total we have maybe around 40 sections per frame, each lasting single-digit milliseconds).
In principle, this works great (thanks a lot for adding this API). However, when viewing the capture in the Tracy profiler, the performance of the profiler quickly degrades when zooming out, falling to less than 1 FPS when zoomed out to view about 20 seconds at once. This does not happen without the sections, even though we (obviously) have much more function profiling regions than we have sections. This FPS loss in the profiler can be very annoying, especially when trying to quickly move around in the capture, or when trying to view one of the larger sections (ie a loading screen, which can span many seconds).
Also, just mentioning: When zoomed out far enough, the rendering of sections seems to sometimes bug out while the capture is still recording, rendering each section in its own line rather than the compact display of how they are rendered usually. This "recovers" when zooming in or when the capture ends, I think this is just a bug with rendering not-yet-closed sections. That's much less of a problem than the low FPS when zooming out.
Activity
4
Bizzarrus3d agoCorrect me if I'm wrong, but to my understanding a top-level zone requires a top level function to encompass the whole region. Such a function does not exist in our case.
For example, the "texture streaming" region consists of a pipeline of jobs - 8 jobs to iterate over buckets to gather memory usage and state requests, followed by one job to sort requests by priority and decide on a cut-off point based on physically available memory, followed by 8 more jobs to update texture state and kick background loading/unloading tasks. We have other regions which consist of pipelines with up to 12 distinct tasks, each task may or may not have multiple jobs, and some of these tasks might run in parallel to other tasks of the same pipeline. Different pipelines may also run in parallel to one another. And each job runs on an arbitrary thread of the job system.
So, there is no top-level function or thread to encompass one region, because each region consists of a chain of jobs in a job graph. Each individual job has a top-level zone of its own, but with an engine that kicks hundreds of jobs per frame, we need a more high-level overview of how one frame looks like and what parts of the "frame job graph" is running at what time. This is especially needed when modifying the job graph or when debugging multithreading bugs between different regions of the job graph.
We've been using "Spans" in RAD Telemetry (which is pretty much the same as sections in tracy) for this purpose and it has been working great. For a long time, the lack of such a feature was our biggest blocker for switching from Telemetry to tracy, so with the introduction of sections in tracy, it now became realistic for us to switch over. It is a shame, though, that sections in tracy have much worse performance in the profiler than Telemetry's spans, particularly when zooming out. If there's a better way to display a chain of jobs/section of a per-frame job graph in tracy, which is between a per-job zone and a multi-frame section, please tell me.
wolfpld3d agoNot really. The reason sections are slow is the view ordering algorithm is performed per-frame and it iterates over each section. With the assumption that sections are long and rare this is not a problem. When you have multiple sections per frame this obviously does not work well.
How do spans work in Telemetry?
Bizzarrus3d agoI obviously don't know exactly how they implement spans in Telemetry, since it's closed source. But visually, it looks pretty much exactly like sections in tracy, and the API is also very similar (they require the caller to allocate and pass an ID rather than the begin function to return one, and they have a few more features like multiple tracks (similar to how threads are separated in tracy - within each track, you get the tighly packed timeline of multiple spans, just exactly how sections look in tracy) and custom color per span, but otherwise it's basically the same. We're not using any of these additional features).
Based on how I implemented a similar feature in my private pet project, I assume that telemetry is assigning a row to the span at the point the begin/enter function is called (keeping a runtime structure that stores which rows are currently free). Then, on the rendering side in the profiler, spans/sections are rendered pretty much exactly like zones, with a similar hierarchy/lod data structure and search algorithm, just that they might be much longer than the usual zone (might need some extra handling to render not-yet-closed spans/sections at the end of each row)
Sections are intended to encompass many frames. The way they are designed will not work well with what you are trying to do. Short lived regions are better represented by top-level zones.