tp: Add flow event support for GPU render stage events

[dreveman]

Add flow_ids and terminating_flow_ids fields to GpuRenderStageEvent proto, matching TrackEvent's flow semantics. Wire the parser to use FlowTracker for begin/step/end of explicit flows.

This enables connecting host-side kernel launch events with GPU render stage events via flow arrows in the UI, making it easier to trace work from CPU submission to GPU execution. It also supports visualizing GPU synchronization primitives (fences, barriers, semaphores) by linking the slices that signal and wait on them.

[github-actions]

🎨 Perfetto UI Builds

• 75039ea (2026-03-28 18:03 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-23690957290-1-ui/ui/index.html

[LalitMaganti]

Before I look at this, please have a read through #1794.

What I say there very much applies. I actually don't want to extend the concept of flows to things other than track event. Flows to me represent a very abstract "causal relationship between two events". In track event, we have to be abstract like that because they can be used to represent many different things.

I'm not convinced that applies for render stage events. I think you can be quite a bit more concrete here and specify things in the way it would make sense to a GPU developer.

If I'm wrong I'd like to understand why to help better direct how we model this problem.

[dreveman]

Before I look at this, please have a read through #1794.

Ah, I wasn't aware of that.

What I say there very much applies. I actually don't want to extend the concept of flows to things other than track event. Flows to me represent a very abstract "causal relationship between two events". In track event, we have to be abstract like that because they can be used to represent many different things.

I'm not convinced that applies for render stage events. I think you can be quite a bit more concrete here and specify things in the way it would make sense to a GPU developer.

If I'm wrong I'd like to understand why to help better direct how we model this problem.

The reasoning that we want something less abstract makes sense to me. Not sure exactly what is best. I need some more time to think about this. Here are the too areas I want to encode in traces:

1. host side activity <-> gpu side activity, so we can tell when the GPU work that was submitted actually execute and on what hw queue. The profiling APIs available for GPUs typically have some form of "Correlation ID" to allow connect these two. Host side activity is ideally represented or connected to track events as that gives the context for why the work was issued.
2. Synchronization between GPU work on. E.g. render stage X running on HW queue 0 needs to complete before render stage Y can start on HW queue 1.

From a UI perspective, flows would work well to represent this but doesn't have be what we use. We can definitely use something less abstract in the protos. I'll think more about this and then update this PR or that issue you linked to. Let me know if you have some ideas.

[LalitMaganti]

Let me know if you have some ideas.

I don't personally understand enough about GPU profiling to give any good advice here :)

You should be aware that color is another dimension you could use for correlation and it's what we use for track events correlation id.