Feature gate wgpu-core's api and resource level logging

[Elabajaba]

Connections
Alternative to #6010
Fixes #6010

Description
This gates wgpu core's api_log and resource_log macros behind an enable_heavy_logs cargo feature (feature could probably use a better name).

Testing
Explain how this change is tested.

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[jimblandy]

In the absence of benchmark results, we can't take PRs like this. This isn't a final decision; if you are able to post numbers, by all means let's re-open.

[Elabajaba]

Here's an older/outdated but well written look at wgpu's logging overhead https://danchia.github.io/posts/bevy-perf-deep-dive-2/

On linux+nvidia (not sure what specific GPU) zeux recently profiled wgpu's logging overhead at about 15% with bevy, (not sure what scene/example was used for testing though). wgpu's overhead was also about 4.5x the driver time on linux+nvidia, and ~6x on RADV. On Metal it's apparently around 50:50 wgpu:driver. (https://discord.com/channels/691052431525675048/743663924229963868/1257828514632044645 for logging numbers, and https://discord.com/channels/691052431525675048/743663924229963868/1257826346290122873 for wgpu overhead numbers)

I'll try to put together a more reproducible and up to date writeup this weekend.

[jimblandy]

@Elabajaba wrote:

wgpu's overhead was also about 4.5x the driver time on linux+nvidia, and ~6x on RADV. On Metal it's apparently around 50:50 wgpu:driver.

That sounds high, and I'd like to know more. But it's hard for us to act on reports without the ability to reproduce the problem ourselves, which is why we have to raise the bar for perf issues. Ideally, perf issues would include a new benchmark that shows the issue, ready to be included in our suite: that would both help us fix the problem, and prevent it from arising again.

We have recently found quite a number of big improvements available from rearchitecture, like @teoxoy's recent PR changing the tracking of resources used by submitted command buffers. I expect we'll be able to continue to find these issues and tighten things up.