Wgpu: CPU profiling infrastructure

[kvark]

Candidates:

• https://github.com/glennw/thread_profiler (note: our threading is not fixed when in standalone mode, I don't think we can use this)
• https://github.com/AlexEne/rust_hawktracer
• https://github.com/padenot/chrome-tracing (used by WebAudio implementation in Gecko)

Some obvious things we'd like to track down:

• time to acquire a new swapchain image (including the fence block time)
• time to submit
• time to record a pass
• time to create resources

[JoNil]

I have been thinking about building rust bindings to tracy, maybe that could be an option: https://bitbucket.org/wolfpld/tracy/src/master/

[kvark]

That does look pretty fancy and functional! My personal preference though would be to have something Rusty :) The chrome-tracing thing, in particular, appears to be battle-tested.

[kvark]

Interesting windows-only solution - https://github.com/embarkStudios/superluminal-perf-rs

[gw3583]

I have been thinking about building rust bindings to tracy, maybe that could be an option: https://bitbucket.org/wolfpld/tracy/src/master/

FWIW, I built an early pass as rust bindings for tracy - https://github.com/gw3583/tracy-rs - it only exposes a basic set of CPU profiling APIs for now. It's published on crates.io.

[kvark]

We didn't have enough choices, so here is some more by @gw3583:

• https://github.com/yse/easy_profiler#easy_profiler
• https://github.com/jonasmr/microprofile
• https://github.com/Celtoys/Remotery

[GabrielMajeri]

How about the tracing crate? It seems to be a pretty mature pure Rust solution.

[kvark]

This is a very interesting one, which somehow I didn't see before. I'd be open to trying it out in wgpu! The only unclear thing to me is how we are going to analyze its output.

[mstange]

I think tracing leaves the output part as "any way you want" - I think tracing is more of an abstraction layer you put in between the capturing and the analysis. So, for example, you could instrument your code with tracing spans, and then have a subscriber that takes those and uses tracy-rs to convert them into output that can be analyzed.

[kvark]

@mstange yes, I understand that abstract nature of it. I'm more asking about the practical side: what do people use with it (i.e. which subscribers)?

[GabrielMajeri]

From what I can tell, they already have support for some subscribers. For example, they can export data in the OpenTelemetry format, and it seems to be supported by jaeger (which is open source).

I'd say we could implement this feature using tracing, and then create exporters for anything else we need.

[cwfitzgerald]

To add even more options to the fire: https://github.com/hrydgard/minitrace is out there. Doesn't fit the rusty component, but it exists. It also outputs to chrome traces.

chrome-tracing imo looks really simple, is pure rust, and will probably get done exactly what we need to. The only possible missing feature would be events, but that's probably not a show stopper and could likely be added in if needed.

[kvark]

chrome-tracing gives me an uneasy feeling because of its name :)
Let's start with tracing as the Rust idiomatic solution, and consider others if we hit any blockers (i.e. dependency tree is too large, doesn't support our use case, or something else).

[GabrielMajeri]

I've been looking through the code, wgpu-core already has a trace feature, and it seems to be used for tracing some events to a trace.ron file. How is that affected by this issue?

[cwfitzgerald]

@GabrielMajeri That's for api tracing, which serializes all calls to wgpu into RON files so the player can replay them later.

[cwfitzgerald]

I think this is pretty solved by our tracing integration.