-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider what to do with wgpu_trace feature #14725
Comments
As per my comment over at #14401 (comment), I personally think it should be removed. This is because, as far as I'm aware, This does mean that the user will have to update |
@LikeLakers2 if you pull in a dependency of a dependency, you can use |
It technically does I think? |
@TrialDragon Ahh, good catch. If I might propose a solution then... perhaps allow that tracing path to be set as a field on |
That sounds good to me. Presuming there are no objections, this seems ready for implementation, then. |
@TrialDragon I have little experience with bevy's codebase - but I will try making this change. |
…gs::WgpuSettings` (#14842) # Objective - Remove the `wgpu_trace` feature while still making it easy/possible to record wgpu traces for debugging. - Close #14725. - Get a taste of the bevy codebase. :P ## Solution This PR performs the above objective by removing the `wgpu_trace` feature from all `Cargo.toml` files. However, wgpu traces are still useful for debugging - but to record them, you need to pass in a directory path to store the traces in. To avoid forcing users into manually creating the renderer, `bevy_render::settings::WgpuSettings` now has a `trace_path` field, so that all of Bevy's automatic initialization can happen while still allowing for tracing. ## Testing - Did you test these changes? If so, how? - I have tested these changes, but only via running `cargo run -p ci`. I am hoping the Github Actions workflows will catch anything I missed. - Are there any parts that need more testing? - I do not believe so. - How can other people (reviewers) test your changes? Is there anything specific they need to know? - If you want to test these changes, I have updated the debugging guide (`docs/debugging.md`) section on WGPU Tracing. - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? - I ran the above command on a Windows 10 64-bit (x64) machine, using the `stable-x86_64-pc-windows-msvc` toolchain. I do not have anything set up for other platforms or targets (though I can't imagine this needs testing on other platforms). --- ## Migration Guide 1. The `bevy/wgpu_trace`, `bevy_render/wgpu_trace`, and `bevy_internal/wgpu_trace` features no longer exist. Remove them from your `Cargo.toml`, CI, tooling, and what-not. 2. Follow the instructions in the updated `docs/debugging.md` file in the repository, under the WGPU Tracing section. Because of the changes made, you can now generate traces to any path, rather than the hardcoded `%WorkspaceRoot%/wgpu_trace` (where `%WorkspaceRoot%` is... the root of your crate's workspace) folder. (If WGPU hasn't restored tracing functionality...) Do note that WGPU has not yet restored tracing functionality. However, once it does, the above should be sufficient to generate new traces. --------- Co-authored-by: TrialDragon <[email protected]>
Description
Wgpu 22 removed the wgpu/trace feature, but the PR to update to wgpu 22 for bevy kept the
wgpu_trace
feature. We should either remove it or add a compile warning that the feature currently doesn't do anything.#14401 (comment)
wgpu issue gfx-rs/wgpu#5974
Since this is only temporary, we could consider keeping it in with just a warning. Personally I think we should just remove it.
The text was updated successfully, but these errors were encountered: