bevy
bevy copied to clipboard
Make RenderPlugin emit only a soft error when there's no gpu, instead of panicking
- Depends on #5932
Objective
- Fixes #5931
Solution
- In initialize_renderer, I just replaced the
.expect
with aerror!
, and made the function return anOption
- In bevy_render/src/lib.rs I wrapped some code in an
if let
. (The diff is huge, but it's just indentation changes.) - Now that
RenderPlugin
will work in gpu-less environments like CI, I added it toTestPlugins
.
Changelog
Fixed
-
RenderPlugin
no longer panics when run on a device without a GPU.
What is the advantage of this? If there is no GPU but the render plugin is used, the app is in a broken state. It doesn't make sense to needlessly consume resources (it will likely saturate at least a single core due to no vsync) as opposed to exit.
@bjorn3 The rationale is explained in the linked issue.
What is the advantage of this? If there is no GPU but the render plugin is used, the app is in a broken state. It doesn't make sense to needlessly consume resources (it will likely saturate at least a single core due to no vsync) as opposed to exit.
After testing on my mac (by causing initialize_renderer
to always return None
), a window will still be created that can be closed by the user. So at least it probably won't silently consume CPU in way that has to be killed via task manager.
In my opinion, this would be better as a cargo feature disabling rendering when not needed.
In my opinion, this would be better as a cargo feature disabling rendering when not needed.
Can you selectively disable cargo features for specific tests? If so, how?
Alternatively we could add a method to DefaultPlugins
which disables the render and window plugins.
Can you selectively disable cargo features for specific tests? If so, how?
You can select the tests and the features to use when running the command cargo test
. But why would you want some tests with rendering and some without?
Can you selectively disable cargo features for specific tests? If so, how?
You can select the tests and the features to use when running the command
cargo test
. But why would you want some tests with rendering and some without?
I suspect it's simpler from the user's perspective to do what @bjorn3 said (so that's what I did!). But I'm happy to do it with conditional compilation, if you think it's better.
I like the idea, but should we move it to a separated
bevy_tests
crate? So users would use as[dev-dependencies]
. We may also add other useful tests utilities in the future.I don't like the ideia of
for_testing
being available in non-testing builds.
That's an interesting idea. Would it live in a separate github repo, or would it still be in this one? I worry that it adds a lot of complexity (for users, for docs, for examples, etc) for not that great a benefit. A user using the testing plugins would not get a usable game.
But on the other hand, I love the idea of having a separate crate with additional utilities for testing. Another option would be to add an optional feature which exposes a bevy::tests
module, and direct users to configure cargo to enable that feature when running cargo test.
All that said, I'd like to get this merged and it feels a bit preemptive to make a whole crate or module to just export one struct. If there's interest, I'll write an automated testing RFC with an outline for more features and improvements to the organization. Would you be willing to approve the merge without this change?
Closing this out; https://github.com/bevyengine/bevy/blob/main/examples/app/no_renderer.rs should just work.