Sync with CPU profiling

[gents83]

Do you think it would be possible to have some kind of parameter per-frame to adjust somehow timings in output from wgpu-profiler to the one of a cpu profiler?

As example I've bound a chrome tracing profilier for cpu and I'm using wgpu-profiler for gpu.

It would be awesome to show them in the same tracing,
so offsetting\shifting the gpu ones to match the start of cpu ones in the frame.

I know it'll be never representative of the reality but it would be anyway nice to see them in the same "frame" and with their own correct timings (in millisec or microsec)

[Wumpf]

I had this idea of adding cpu timestamps to GpuTimerScopeResult so you know when a thing was recorded that the gpu then processes later. Giving you a sense of "the cpu spend this much time of this pass, the gpu that much".
Would that do what you want? That's not doing any of the syncing up, but I don't think there's a meaningful way to do that.

[Imberflur]

I just encountered a case where it would be useful to at least of some sort of identifier for a frame so that other metrics collected for that frame can be easily associated to the GPU timings.

[Wumpf]

let's have custom payloads on both scopes and profiler frames, otherwise more of these will keep coming up 🤔

[Wumpf]

fyi another very big bundle of api changes if coming soon anyways, making GpuProfiler threadsafe. So might make sense to bundle all these into a release:

• Profiler can't be used accross threads or with interleaved scopes #46
• Make use of pass timer queries #51
• Allow custom payloads for Profiler Frame and Scopes #54

[Wumpf]

I think being able to add arbitrary data to scopes & frames would solve your syncing ask as well @gents83 , but wanted to check if that's too far off from what you had in mind?

[gents83]

Absolutely! I think that once that we've data that we can pass and then retrieve at the end to do our logic - we can do whatever then :) Tnx a lot @Wumpf