[Merged by Bors] - Enable wgpu profiling spans when using bevy's trace feature

[superdump]

Objective

• Enable wgpu profiling spans

Solution

• wgpu uses the profiling crate to add profiling span instrumentation to their code
• profiling offers multiple 'backends' for profiling, including tracing
• When the bevy trace feature is used, add the profiling crate with its profile-with-tracing feature to enable appropriate profiling spans in wgpu using tracing which fits nicely into our infrastructure
• Bump our default tracing subscriber filter to wgpu=info from wgpu=error so that the profiling spans are not filtered out as they are created at the info level.

---

Changelog

• Added: tracing profiling support for wgpu when using bevy's trace feature
• Changed: The default tracing filter statement for wgpu has been changed from the error level to the info level to not filter out the wgpu profiling spans

[mockersf]

I think this should be a separate feature from Bevy tracing.
People will often be interested in tracing to profile their system, not always to profile their GPU usage. Ideally we should be able to do both independently

[superdump]

In that case I want to rename the wgpu_trace feature to wgpu_api_trace (because it enables a feature that traces the wgpu api calls for debug and replay purposes) and call this new feature for enabling profiling tracing trace_wgpu for consistency with our other trace_* features. Sound ok @mockersf ?

[mockersf]

I was wondering - are spans enabled depending on the log level of the emitting crate? If that's the case, reusing the feature would be fine, it would just need more docs, something like: "if you want to see your system spans, set this log level, if you want wgpu spans, set this level, if you want both ..."

Otherwise, the feature renaming sounds good!

[superdump]

I was wondering - are spans enabled depending on the log level of the emitting crate? If that's the case, reusing the feature would be fine, it would just need more docs, something like: "if you want to see your system spans, set this log level, if you want wgpu spans, set this level, if you want both ..."

Yes, spans are enabled based on the log level defined at the span creation site. The profiling::scope!() macro used in wgpu uses the tracing info level for its spans. So we could just tell people to override the default tracing subscriber filter with wgpu=info instead of me changing that. However, doing that using RUST_LOG could incur all the wgpu logs as well, and not just the tracing spans... goes to test it... I think it seems like using RUST_LOG=info captures all the bevy and wgpu spans.

So, I will roll back the changes to the default log filter, and instead add documentation about using RUST_LOG=info for profiling to capture the wgpu spans as well.

[superdump]

@mockersf I have added documentation into Cargo.toml above the profiling crate. I do not think this is the best place, but there is a separate open PR for adding information about using Tracy for profiling to the markdown docs so I'll add something more as part of that now and get that finished. We're asking people who contribute to do benchmarking much more frequently these days.

[superdump]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-and-install-on-iOS
• build-android
• build (nightly, ubuntu-latest)
• build (stable, macos-latest)
• build (stable, ubuntu-latest)
• build (stable, windows-latest)
• build-wasm (nightly, ubuntu-latest)
• build-wasm (stable, ubuntu-latest)
• check-compiles
• check-doc
• check-missing-examples-in-docs
• ci
• markdownlint
• miri
• run-examples
• run-examples-on-wasm
• run-examples-on-windows