EmbarkStudios / EmbarkStudios/puffin

Is it sensible to sum overlapping thread scopes?

Open
#60 1 comment 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Rust
Stars
1.7k
Forks
111
Avg merge
2h 50m
Merged PRs (30d)
1

Description

**Is your feature request related to a problem? Please describe.**

While visualizing delays from an identical starting point - effectively overlapping each other - through scopes manually added to `puffin::Stream`, the resulting scopes get summed and show a prolonged track. This is an example registering the same 500ms `child` workload - starting at `0` - three times:

![image](https://user-images.githubusercontent.com/2325264/150794442-5c9011e5-87f7-4da6-8372-8650cf286b65.png)

Likewise we have GPU workloads where the next command buffer starts running ahead of the previous one completing. Here too - albeit with different names - their entire track gets prolonged to fit every item on the line, even when it exceeds the parent `` Context `frame 0` Command buffer `2` `` parent scope despite setting explicit start and end timings for a scope.

![image](https://user-images.githubusercontent.com/2325264/150789735-7304df35-15ef-467d-9ec9-81cfa2665cf3.png)

(I take no responsibility for three different pipelines in the same frame having both a space, hyphen, and underscore :rofl:)

That's done by:
https://github.com/EmbarkStudios/puffin/blob/17d0429bcca5f8b398378918b38d109a4c1caf9d/puffin/src/merge.rs#L128-L133

This is somewhat related to GPU profiling in #59.

**Describe the solution you'd like**
I expected either a `panic`/`Err()` because of submitting invalid data through the `puffin::global_reporter`, and not initially knowing that - presumably - profiling submitted for "threads" (a CPU thread in the literal sense) is assumed to run serially. Ie. if the start of the next sibling scope lies before the end of the current, that should be an error?

**Describe alternatives you've considered**

It'd be great if puffin could _somehow_ visualize these overlapping scopes, maybe a color or pattern to display overdraw? Displaying on multiple tracks is bound to be tricky, hard to see, and pretty much breaks the "flamegraph" concept. Perhaps a different waterfall view like Radeon Graphics Profiler could be considered? This may need a different kind of "profiling mode" to allow such kind of overlaps though.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.