-
-
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
Remove render_resource_wrapper #15441
Remove render_resource_wrapper #15441
Conversation
Welcome, new contributor! Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨ |
ce23c9b
to
cea2a10
Compare
Looks like Here's one of many similar errors: error[E0277]: `(dyn std::any::Any + 'static)` cannot be shared between threads safely
--> crates/bevy_render/src/view/window/mod.rs:51:40
|
51 | render_app.init_resource::<ScreenshotToScreenPipeline>();
| ------------- ^^^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn std::any::Any + 'static)` cannot be shared between threads safely
| |
| required by a bound introduced by this call
|
= help: the trait `Sync` is not implemented for `(dyn std::any::Any + 'static)`, which is required by `ScreenshotToScreenPipeline: bevy_ecs::system::Resource`
= help: the trait `bevy_ecs::system::Resource` is implemented for `ScreenshotToScreenPipeline`
= note: required for `Unique<(dyn std::any::Any + 'static)>` to implement `Sync`
note: required because it appears within the type `Box<(dyn std::any::Any + 'static)>`
--> /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:233:12
|
233 | pub struct Box<
| ^^^
note: required because it appears within the type `wgpu::BindGroupLayout`
--> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-22.1.0/src/lib.rs:796:12
|
796 | pub struct BindGroupLayout {
| ^^^^^^^^^^^^^^^
= note: required for `Arc<wgpu::BindGroupLayout>` to implement `std::marker::Send`
note: required because it appears within the type `bind_group_layout::BindGroupLayout`
--> crates/bevy_render/src/render_resource/bind_group_layout.rs:8:12 Funnily enough, I can't reproduce it on my mac with latest nightly 🤔 cargo +nightly check --target wasm32-unknown-unknown -Z build-std=std,panic_abort |
I think (?) we need to add |
cea2a10
to
1340167
Compare
It was a bit of an ick, but i wrapped everything in |
ff6a82a
to
d25e7ac
Compare
d25e7ac
to
78d5671
Compare
since it seems like extra functionality (beyond the compile time optimizations) have been added to the i don't think removing the compile-time optimizations should be resulting in any call-site changes though... |
This will work for everything except But I'm wondering what extra functionality you mean? Deref, or the atomics stuff, or both? |
Could you check the compilation duration with this PR? The erased types were introduce for compilation speed, see #5950 |
maybe? sorry i'm not sure what was in the pr to begin with (i looked when it only addressed the
both - i think the call sites should all be unchanged. The macro can (i think) be replaced with a struct that encapsulates the extra behaviour that's been added on top of the compile time optimizations (which were only ever in the debug version of the macro). |
Any external user that depends on Bevy and wants to use a shared Do you mean something like this (just a sketch): struct BevyArc<T> where T: Send + Sync {
inner: Arc<send_wrapper::SendWrapper<T>>,
}
impl<T: Send + Sync> Deref for BevyArc<T> { //... And then remove |
It'a bit depressing that we can't just use an |
I'm not familiar with the history here, I also agree it's a bit unfortunate we can't just use the arc'd types as well as |
I would love some guidance on what to do here. I just wanted a slightly better API for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok sorry, after a closer look i think this will be totally fine.
moving the SurfaceTexture
into_inner
up a level should avoid the api/callsite changes completely.
then we just need to run compile timings - are you happy to do that or shall i do it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Applied the given suggestions. Thanks!
78d5671
to
533fa23
Compare
I can do it if you teach me how to, but I also think that you doing it yourself might lead to better results. If you don't have an M-series mac on hand, I can do it for mac. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. Approving pending no major regression in compile time.
It’s just #5950 had a particularly bad userspace example in the top comment that would get like 95% worse as well. I’ll run windows tomorrow if nobody else does it in the meantime |
MacBook Pro M2 Max - 32GB RAM Before my changes - commit 5fcbdc1 $ cargo clean
Removed 148120 files, 123.9GiB total
$ cargo build --timings
...
Finished `dev` profile [unoptimized + debuginfo] target(s) in 47.31s |
MacBook Pro M2 Max - 32GB RAM After my changes - commit 533fa23 $ cargo clean
Removed 19794 files, 6.0GiB total
$ cargo build --timings
...
Finished `dev` profile [unoptimized + debuginfo] target(s) in 43.66s Meaning - On my machine, compilation speed decreased by 4 seconds for the debug build (7.7% shorter) |
For release ( |
533fa23
to
807acb0
Compare
Looks like the wasm issue is back. I think that’s because |
I think the fix is easy, go back to the coersion i used before: As I wrote in the review comment:
|
Yes go ahead, your original way makes sense. Sorry! |
This commit removes the render_resource_wrapper macro, which was added because using Arc was deemed too slow. After discussing on Discord, it was suggested that we could remove the macro and just wrap the affected types in Arc instead.
807acb0
to
b368a0d
Compare
Great! Updated! Let me know how to proceed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
windows debug build 1m29s main vs 1m26s pr.
lgtm
# Objective * Remove all uses of render_resource_wrapper. * Make it easier to share a `wgpu::Device` between Bevy and application code. ## Solution Removed the `render_resource_wrapper` macro. To improve the `RenderCreation:: Manual ` API, `ErasedRenderDevice` was replaced by `Arc`. Unfortunately I had to introduce one more usage of `WgpuWrapper` which seems like an unwanted constraint on the caller. ## Testing - Did you test these changes? If so, how? - Ran `cargo test`. - Ran a few examples. - Used `RenderCreation::Manual` in my own project - Exercised `RenderCreation::Automatic` through examples - Are there any parts that need more testing? - No - How can other people (reviewers) test your changes? Is there anything specific they need to know? - Run examples - Use `RenderCreation::Manual` in their own project
Objective
wgpu::Device
between Bevy and application code.Solution
Removed the
render_resource_wrapper
macro.To improve the
RenderCreation:: Manual
API,ErasedRenderDevice
was replaced byArc
. Unfortunately I had to introduce one more usage ofWgpuWrapper
which seems like an unwanted constraint on the caller.Testing
Did you test these changes? If so, how?
cargo test
.RenderCreation::Manual
in my own projectRenderCreation::Automatic
through examplesAre there any parts that need more testing?
How can other people (reviewers) test your changes? Is there anything specific they need to know?
RenderCreation::Manual
in their own project