-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[Merged by Bors] - Converted exclusive systems to parallel systems wherever possible #2774
Conversation
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.
Awesome, thanks for doing this! Left one nit, but it looks great.
We should verify that we're not introducing one-frame delays with new execution order ambiguities. I'm a bit loathe to ask you to do that in this PR; feel free to investigate if you'd like but if it's beyond you we can do a proper cleanup pass for that in a seperate PR.
It is probably introducing ambiguity and some one-frame delays. From what I understand by default all the exclusive systems run at the start of the stage and this change makes it run in between. I would assume the same applies to I don't know how to make these systems run first without making them exclusive again or putting labels everywhere. Idk if putting labels everywhere is an acceptable solution, I don't think it is very maintainable. For Reference:
|
Yeah; there's a larger conversation ongoing about this: see #2747. I suspect that the |
I think that will exacerbate the issue of one-frame delays because the majority of commands put into the |
@alice-i-cecile I did some testing with timing the duration it takes for changes triggered in
I think the parallel ones change the order they are executed in across executions of the binary. They produce extremely varying results. |
Hmm, I agree. We could make another stage :/ I think the best solution here is probably to add a public label to
Yep, that's standard ambiguous ordering behavior :( |
@alice-i-cecile Added the labels in. Ran a benchmark again and now its around 0.302998 ms - 0.411899 ms pretty reliably. There are no more ambiguities reported related to this pr now. |
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.
Fantastic; looks good to me now! Thanks for tackling this.
e135d8d
to
9a0c1b2
Compare
@SarthakSingh31 can you rebase this on main? :) I'd like to get this merged but there are now merge conflicts |
7c54787
to
562dc29
Compare
@alice-i-cecile rebased. It looks like |
The system |
My intution is that this should run after, both to preserve existing behavior and for correctness. @SarthakSingh31 can you make that change? We can revert it if our rendering experts tell us otherwise. |
Hmm. I think the current setup has add_clusters being run first as an exclusive system to ensure the presence of Clusters components on appropriate views, and then update_clusters is a normal system that overwrites the cluster configuration based on the window size. I think that suggests it only has to be correct when update_clusters is run. To complicate things further, I know that update_clusters is going to move to being called from assign_lights_to_clusters in an upcoming PR. To be clear, add_clusters needs to be run such that the Clusters components are actually added (ie commands are applied to the world) before any of the subsequent clustered forward rendering PostUpdate systems are run. And I think the window sizes only have to be correct at the point of execution of update_clusters currently but it would have to be tested. If possible just preserve current behaviour. |
If add_clusters required windows to be correct and it is an exclusive system, then it would then require that change_windows is either exclusive and run before it, or it is run in an earlier stage, right? |
Huh, However, it looks like bevy/crates/bevy_winit/src/lib.rs Line 48 in caf6611
|
yup, this pr is changing it seems |
It isn't only for ordering. It inserts That said, I don't think add_clusters was specified to necessarily run after change_windows among the exclusive PostUpdate systems, so it could have run after. And, also as said, I think as long as update_clusters runs after change_windows, it should be fine, but we need to test it. |
662d429
to
4f4b478
Compare
@mockersf fixed the ordering and resolved the new merge conflicts. I feel like |
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.
I left a couple of comments.
Separately, continuing the add_clusters discussion, I think before this PR, add_clusters would run after change_windows with DefaultsPlugins plugin ordering because winit would be initialised before pbr so the change_windows exclusive system would be registered before the add_clusters exclusive system and so change_windows would also be executed before add_clusters.
With this PR change_windows is being moved to after add_clusters because add_clusters is still exclusive and change_windows is not.
As mentioned, I think the important things from a practical perspective are that add_clusters remains exclusive so that clusters components get added to appropriate views before update_clusters is later executed, and change_windows must run before update_clusters. The labelling of change_windows and the ordering condition that update_clusters be run after change_windows satisfies this.
crates/bevy_pbr/src/lib.rs
Outdated
@@ -80,14 +82,16 @@ impl Plugin for PbrPlugin { | |||
// add as an exclusive system | |||
add_clusters | |||
.exclusive_system() | |||
.label(SimulationLightSystems::AddClusters), | |||
.label(SimulationLightSystems::AddClusters) | |||
.after(ModifiesWindows), |
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.
I think now that change_windows is not exclusive, this will cause a warning to be logged that this system tried to be scheduled after ModifiesWindows and that system doesn’t exist in the exclusive part of PostUpdate.
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.
Removed it
@@ -73,3 +73,6 @@ impl Plugin for WindowPlugin { | |||
} | |||
} | |||
} | |||
|
|||
#[derive(Debug, Hash, PartialEq, Eq, Clone, SystemLabel)] | |||
pub struct ModifiesWindows; |
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.
Can systems have multiple labels, if not then the approach of tagging a system with things it does doesn’t really hold because a system could modify multiple things as well as the windows.
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.
Yes, multiple levels are permitted.
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. Then this is not a problem.
@SarthakSingh31 can you rebase this? I'd like to merge this in. |
4f4b478
to
f04d91c
Compare
bors r+ |
) Closes #2767. Converted: - `play_queued_audio_system` - `change_window`
I don't know if it's too late now, but it would be nice if this PR used the actual system as a label instead of a new SystemLabel now that we have this feature. edit: it's too late now |
…vyengine#2774) Closes bevyengine#2767. Converted: - `play_queued_audio_system` - `change_window`
…vyengine#2774) Closes bevyengine#2767. Converted: - `play_queued_audio_system` - `change_window`
Closes #2767.
Converted:
play_queued_audio_system
change_window