[Merged by Bors] - Stageless: add a method to scope to always run a task on the scope thread #7415
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hymm
changed the title
alice-i-cecile
added
C-Usability
alice-i-cecile
added
C-Bug
33 tasks
hymm
changed the title
hymm
force-pushed
the
scope-spawn-local-again
branch
from
ac0ef12
to
8efcc1b
Compare
# Objective - Trying to move some of the fixes from bevyengine#7267 to make that one easier to review - The MainThreadExecutor is how the render world runs nonsend systems on the main thread for pipelined rendering. - The multithread executor for stageless wasn't using the MainThreadExecutor. - MainThreadExecutor was declared in the old executor_parallel module that is getting deleted. - The way the MainThreadExecutor was getting passed to the scope was actually unsound as the resource could be dropped from the World while the schedule was running ## Solution - Move MainThreadExecutor to the new multithreaded_executor's file. - Make the multithreaded executor use the MainThreadExecutor - Clone the MainThreadExecutor onto the stack and pass that ref in ## Changelog - Move MainThreadExecutor for stageless migration.
hymm
force-pushed
the
scope-spawn-local-again
branch
from
8efcc1b
to
4e8737a
Compare
cart
approved these changes
Feb 4, 2023
There was a problem hiding this comment.
I don't love it, but this seems alright as a short term solution while we sort out !Send + World issues.
This does appear to markedly improve my stageless "main app" perf (although I've been seeing big ~1ms swings across runs when profiling "main app" so take this with a grain of salt). The improvement is much greater than 1ms (and I could replicate it in a second run), so I think this is still a pretty big win.
alice-i-cecile
approved these changes
Feb 4, 2023
james7132
approved these changes
Feb 4, 2023
There was a problem hiding this comment.
I'm of a similar opinion: the TaskPool implementation is getting exceptionally complex. We definitely need to spend the time to detangle and find better solutions for this.
With that said, we definitely need something to resolve this issue before stageless goes live. I'm fine with this as an interim solution until we have a more permanent approach towards finer control over which thread a task gets scheduled to.
james7132
added
the
S-Ready-For-Final-Review
|
bors r+ |
bors bot
pushed a commit
that referenced
this pull request
Feb 5, 2023
…read (#7415) # Objective - Currently exclusive systems and applying buffers run outside of the multithreaded executor and just calls the funtions on the thread the schedule is running on. Stageless changes this to run these using tasks in a scope. Specifically It uses `spawn_on_scope` to run these. For the render thread this is incorrect as calling `spawn_on_scope` there runs tasks on the main thread. It should instead run these on the render thread and only run nonsend systems on the main thread. ## Solution - Add another executor to `Scope` for spawning tasks on the scope. `spawn_on_scope` now always runs the task on the thread the scope is running on. `spawn_on_external` spawns onto the external executor than is optionally passed in. If None is passed `spawn_on_external` will spawn onto the scope executor. - Eventually this new machinery will be able to be removed. This will happen once a fix for removing NonSend resources from the world lands. So this is a temporary fix to support stageless. --- ## Changelog - add a spawn_on_external method to allow spawning on the scope's thread or an external thread ## Migration Guide > No migration guide. The main thread executor was introduced in pipelined rendering which was merged for 0.10. spawn_on_scope now behaves the same way as on 0.9.
bors
bot
changed the title
bors bot
pushed a commit
that referenced
this pull request
Feb 6, 2023
Huge thanks to @maniwani, @devil-ira, @hymm, @cart, @superdump and @jakobhellermann for the help with this PR. # Objective - Followup #6587. - Minimal integration for the Stageless Scheduling RFC: bevyengine/rfcs#45 ## Solution - [x] Remove old scheduling module - [x] Migrate new methods to no longer use extension methods - [x] Fix compiler errors - [x] Fix benchmarks - [x] Fix examples - [x] Fix docs - [x] Fix tests ## Changelog ### Added - a large number of methods on `App` to work with schedules ergonomically - the `CoreSchedule` enum - `App::add_extract_system` via the `RenderingAppExtension` trait extension method - the private `prepare_view_uniforms` system now has a public system set for scheduling purposes, called `ViewSet::PrepareUniforms` ### Removed - stages, and all code that mentions stages - states have been dramatically simplified, and no longer use a stack - `RunCriteriaLabel` - `AsSystemLabel` trait - `on_hierarchy_reports_enabled` run criteria (now just uses an ad hoc resource checking run condition) - systems in `RenderSet/Stage::Extract` no longer warn when they do not read data from the main world - `RunCriteriaLabel` - `transform_propagate_system_set`: this was a nonstandard pattern that didn't actually provide enough control. The systems are already `pub`: the docs have been updated to ensure that the third-party usage is clear. ### Changed - `System::default_labels` is now `System::default_system_sets`. - `App::add_default_labels` is now `App::add_default_sets` - `CoreStage` and `StartupStage` enums are now `CoreSet` and `StartupSet` - `App::add_system_set` was renamed to `App::add_systems` - The `StartupSchedule` label is now defined as part of the `CoreSchedules` enum - `.label(SystemLabel)` is now referred to as `.in_set(SystemSet)` - `SystemLabel` trait was replaced by `SystemSet` - `SystemTypeIdLabel<T>` was replaced by `SystemSetType<T>` - The `ReportHierarchyIssue` resource now has a public constructor (`new`), and implements `PartialEq` - Fixed time steps now use a schedule (`CoreSchedule::FixedTimeStep`) rather than a run criteria. - Adding rendering extraction systems now panics rather than silently failing if no subapp with the `RenderApp` label is found. - the `calculate_bounds` system, with the `CalculateBounds` label, is now in `CoreSet::Update`, rather than in `CoreSet::PostUpdate` before commands are applied. - `SceneSpawnerSystem` now runs under `CoreSet::Update`, rather than `CoreStage::PreUpdate.at_end()`. - `bevy_pbr::add_clusters` is no longer an exclusive system - the top level `bevy_ecs::schedule` module was replaced with `bevy_ecs::scheduling` - `tick_global_task_pools_on_main_thread` is no longer run as an exclusive system. Instead, it has been replaced by `tick_global_task_pools`, which uses a `NonSend` resource to force running on the main thread. ## Migration Guide - Calls to `.label(MyLabel)` should be replaced with `.in_set(MySet)` - Stages have been removed. Replace these with system sets, and then add command flushes using the `apply_system_buffers` exclusive system where needed. - The `CoreStage`, `StartupStage, `RenderStage` and `AssetStage` enums have been replaced with `CoreSet`, `StartupSet, `RenderSet` and `AssetSet`. The same scheduling guarantees have been preserved. - Systems are no longer added to `CoreSet::Update` by default. Add systems manually if this behavior is needed, although you should consider adding your game logic systems to `CoreSchedule::FixedTimestep` instead for more reliable framerate-independent behavior. - Similarly, startup systems are no longer part of `StartupSet::Startup` by default. In most cases, this won't matter to you. - For example, `add_system_to_stage(CoreStage::PostUpdate, my_system)` should be replaced with - `add_system(my_system.in_set(CoreSet::PostUpdate)` - When testing systems or otherwise running them in a headless fashion, simply construct and run a schedule using `Schedule::new()` and `World::run_schedule` rather than constructing stages - Run criteria have been renamed to run conditions. These can now be combined with each other and with states. - Looping run criteria and state stacks have been removed. Use an exclusive system that runs a schedule if you need this level of control over system control flow. - For app-level control flow over which schedules get run when (such as for rollback networking), create your own schedule and insert it under the `CoreSchedule::Outer` label. - Fixed timesteps are now evaluated in a schedule, rather than controlled via run criteria. The `run_fixed_timestep` system runs this schedule between `CoreSet::First` and `CoreSet::PreUpdate` by default. - Command flush points introduced by `AssetStage` have been removed. If you were relying on these, add them back manually. - Adding extract systems is now typically done directly on the main app. Make sure the `RenderingAppExtension` trait is in scope, then call `app.add_extract_system(my_system)`. - the `calculate_bounds` system, with the `CalculateBounds` label, is now in `CoreSet::Update`, rather than in `CoreSet::PostUpdate` before commands are applied. You may need to order your movement systems to occur before this system in order to avoid system order ambiguities in culling behavior. - the `RenderLabel` `AppLabel` was renamed to `RenderApp` for clarity - `App::add_state` now takes 0 arguments: the starting state is set based on the `Default` impl. - Instead of creating `SystemSet` containers for systems that run in stages, simply use `.on_enter::<State::Variant>()` or its `on_exit` or `on_update` siblings. - `SystemLabel` derives should be replaced with `SystemSet`. You will also need to add the `Debug`, `PartialEq`, `Eq`, and `Hash` traits to satisfy the new trait bounds. - `with_run_criteria` has been renamed to `run_if`. Run criteria have been renamed to run conditions for clarity, and should now simply return a bool. - States have been dramatically simplified: there is no longer a "state stack". To queue a transition to the next state, call `NextState::set` ## TODO - [x] remove dead methods on App and World - [x] add `App::add_system_to_schedule` and `App::add_systems_to_schedule` - [x] avoid adding the default system set at inappropriate times - [x] remove any accidental cycles in the default plugins schedule - [x] migrate benchmarks - [x] expose explicit labels for the built-in command flush points - [x] migrate engine code - [x] remove all mentions of stages from the docs - [x] verify docs for States - [x] fix uses of exclusive systems that use .end / .at_start / .before_commands - [x] migrate RenderStage and AssetStage - [x] migrate examples - [x] ensure that transform propagation is exported in a sufficiently public way (the systems are already pub) - [x] ensure that on_enter schedules are run at least once before the main app - [x] re-enable opt-in to execution order ambiguities - [x] revert change to `update_bounds` to ensure it runs in `PostUpdate` - [x] test all examples - [x] unbreak directional lights - [x] unbreak shadows (see 3d_scene, 3d_shape, lighting, transparaency_3d examples) - [x] game menu example shows loading screen and menu simultaneously - [x] display settings menu is a blank screen - [x] `without_winit` example panics - [x] ensure all tests pass - [x] SubApp doc test fails - [x] runs_spawn_local tasks fails - [x] [Fix panic_when_hierachy_cycle test hanging](alice-i-cecile#120) ## Points of Difficulty and Controversy **Reviewers, please give feedback on these and look closely** 1. Default sets, from the RFC, have been removed. These added a tremendous amount of implicit complexity and result in hard to debug scheduling errors. They're going to be tackled in the form of "base sets" by @cart in a followup. 2. The outer schedule controls which schedule is run when `App::update` is called. 3. I implemented `Label for `Box<dyn Label>` for our label types. This enables us to store schedule labels in concrete form, and then later run them. I ran into the same set of problems when working with one-shot systems. We've previously investigated this pattern in depth, and it does not appear to lead to extra indirection with nested boxes. 4. `SubApp::update` simply runs the default schedule once. This sucks, but this whole API is incomplete and this was the minimal changeset. 5. `time_system` and `tick_global_task_pools_on_main_thread` no longer use exclusive systems to attempt to force scheduling order 6. Implemetnation strategy for fixed timesteps 7. `AssetStage` was migrated to `AssetSet` without reintroducing command flush points. These did not appear to be used, and it's nice to remove these bottlenecks. 8. Migration of `bevy_render/lib.rs` and pipelined rendering. The logic here is unusually tricky, as we have complex scheduling requirements. ## Future Work (ideally before 0.10) - Rename schedule_v3 module to schedule or scheduling - Add a derive macro to states, and likely a `EnumIter` trait of some form - Figure out what exactly to do with the "systems added should basically work by default" problem - Improve ergonomics for working with fixed timesteps and states - Polish FixedTime API to match Time - Rebase and merge #7415 - Resolve all internal ambiguities (blocked on better tools, especially #7442) - Add "base sets" to replace the removed default sets.
bors bot
pushed a commit
that referenced
this pull request
Feb 6, 2023
Huge thanks to @maniwani, @devil-ira, @hymm, @cart, @superdump and @jakobhellermann for the help with this PR. # Objective - Followup #6587. - Minimal integration for the Stageless Scheduling RFC: bevyengine/rfcs#45 ## Solution - [x] Remove old scheduling module - [x] Migrate new methods to no longer use extension methods - [x] Fix compiler errors - [x] Fix benchmarks - [x] Fix examples - [x] Fix docs - [x] Fix tests ## Changelog ### Added - a large number of methods on `App` to work with schedules ergonomically - the `CoreSchedule` enum - `App::add_extract_system` via the `RenderingAppExtension` trait extension method - the private `prepare_view_uniforms` system now has a public system set for scheduling purposes, called `ViewSet::PrepareUniforms` ### Removed - stages, and all code that mentions stages - states have been dramatically simplified, and no longer use a stack - `RunCriteriaLabel` - `AsSystemLabel` trait - `on_hierarchy_reports_enabled` run criteria (now just uses an ad hoc resource checking run condition) - systems in `RenderSet/Stage::Extract` no longer warn when they do not read data from the main world - `RunCriteriaLabel` - `transform_propagate_system_set`: this was a nonstandard pattern that didn't actually provide enough control. The systems are already `pub`: the docs have been updated to ensure that the third-party usage is clear. ### Changed - `System::default_labels` is now `System::default_system_sets`. - `App::add_default_labels` is now `App::add_default_sets` - `CoreStage` and `StartupStage` enums are now `CoreSet` and `StartupSet` - `App::add_system_set` was renamed to `App::add_systems` - The `StartupSchedule` label is now defined as part of the `CoreSchedules` enum - `.label(SystemLabel)` is now referred to as `.in_set(SystemSet)` - `SystemLabel` trait was replaced by `SystemSet` - `SystemTypeIdLabel<T>` was replaced by `SystemSetType<T>` - The `ReportHierarchyIssue` resource now has a public constructor (`new`), and implements `PartialEq` - Fixed time steps now use a schedule (`CoreSchedule::FixedTimeStep`) rather than a run criteria. - Adding rendering extraction systems now panics rather than silently failing if no subapp with the `RenderApp` label is found. - the `calculate_bounds` system, with the `CalculateBounds` label, is now in `CoreSet::Update`, rather than in `CoreSet::PostUpdate` before commands are applied. - `SceneSpawnerSystem` now runs under `CoreSet::Update`, rather than `CoreStage::PreUpdate.at_end()`. - `bevy_pbr::add_clusters` is no longer an exclusive system - the top level `bevy_ecs::schedule` module was replaced with `bevy_ecs::scheduling` - `tick_global_task_pools_on_main_thread` is no longer run as an exclusive system. Instead, it has been replaced by `tick_global_task_pools`, which uses a `NonSend` resource to force running on the main thread. ## Migration Guide - Calls to `.label(MyLabel)` should be replaced with `.in_set(MySet)` - Stages have been removed. Replace these with system sets, and then add command flushes using the `apply_system_buffers` exclusive system where needed. - The `CoreStage`, `StartupStage, `RenderStage` and `AssetStage` enums have been replaced with `CoreSet`, `StartupSet, `RenderSet` and `AssetSet`. The same scheduling guarantees have been preserved. - Systems are no longer added to `CoreSet::Update` by default. Add systems manually if this behavior is needed, although you should consider adding your game logic systems to `CoreSchedule::FixedTimestep` instead for more reliable framerate-independent behavior. - Similarly, startup systems are no longer part of `StartupSet::Startup` by default. In most cases, this won't matter to you. - For example, `add_system_to_stage(CoreStage::PostUpdate, my_system)` should be replaced with - `add_system(my_system.in_set(CoreSet::PostUpdate)` - When testing systems or otherwise running them in a headless fashion, simply construct and run a schedule using `Schedule::new()` and `World::run_schedule` rather than constructing stages - Run criteria have been renamed to run conditions. These can now be combined with each other and with states. - Looping run criteria and state stacks have been removed. Use an exclusive system that runs a schedule if you need this level of control over system control flow. - For app-level control flow over which schedules get run when (such as for rollback networking), create your own schedule and insert it under the `CoreSchedule::Outer` label. - Fixed timesteps are now evaluated in a schedule, rather than controlled via run criteria. The `run_fixed_timestep` system runs this schedule between `CoreSet::First` and `CoreSet::PreUpdate` by default. - Command flush points introduced by `AssetStage` have been removed. If you were relying on these, add them back manually. - Adding extract systems is now typically done directly on the main app. Make sure the `RenderingAppExtension` trait is in scope, then call `app.add_extract_system(my_system)`. - the `calculate_bounds` system, with the `CalculateBounds` label, is now in `CoreSet::Update`, rather than in `CoreSet::PostUpdate` before commands are applied. You may need to order your movement systems to occur before this system in order to avoid system order ambiguities in culling behavior. - the `RenderLabel` `AppLabel` was renamed to `RenderApp` for clarity - `App::add_state` now takes 0 arguments: the starting state is set based on the `Default` impl. - Instead of creating `SystemSet` containers for systems that run in stages, simply use `.on_enter::<State::Variant>()` or its `on_exit` or `on_update` siblings. - `SystemLabel` derives should be replaced with `SystemSet`. You will also need to add the `Debug`, `PartialEq`, `Eq`, and `Hash` traits to satisfy the new trait bounds. - `with_run_criteria` has been renamed to `run_if`. Run criteria have been renamed to run conditions for clarity, and should now simply return a bool. - States have been dramatically simplified: there is no longer a "state stack". To queue a transition to the next state, call `NextState::set` ## TODO - [x] remove dead methods on App and World - [x] add `App::add_system_to_schedule` and `App::add_systems_to_schedule` - [x] avoid adding the default system set at inappropriate times - [x] remove any accidental cycles in the default plugins schedule - [x] migrate benchmarks - [x] expose explicit labels for the built-in command flush points - [x] migrate engine code - [x] remove all mentions of stages from the docs - [x] verify docs for States - [x] fix uses of exclusive systems that use .end / .at_start / .before_commands - [x] migrate RenderStage and AssetStage - [x] migrate examples - [x] ensure that transform propagation is exported in a sufficiently public way (the systems are already pub) - [x] ensure that on_enter schedules are run at least once before the main app - [x] re-enable opt-in to execution order ambiguities - [x] revert change to `update_bounds` to ensure it runs in `PostUpdate` - [x] test all examples - [x] unbreak directional lights - [x] unbreak shadows (see 3d_scene, 3d_shape, lighting, transparaency_3d examples) - [x] game menu example shows loading screen and menu simultaneously - [x] display settings menu is a blank screen - [x] `without_winit` example panics - [x] ensure all tests pass - [x] SubApp doc test fails - [x] runs_spawn_local tasks fails - [x] [Fix panic_when_hierachy_cycle test hanging](alice-i-cecile#120) ## Points of Difficulty and Controversy **Reviewers, please give feedback on these and look closely** 1. Default sets, from the RFC, have been removed. These added a tremendous amount of implicit complexity and result in hard to debug scheduling errors. They're going to be tackled in the form of "base sets" by @cart in a followup. 2. The outer schedule controls which schedule is run when `App::update` is called. 3. I implemented `Label for `Box<dyn Label>` for our label types. This enables us to store schedule labels in concrete form, and then later run them. I ran into the same set of problems when working with one-shot systems. We've previously investigated this pattern in depth, and it does not appear to lead to extra indirection with nested boxes. 4. `SubApp::update` simply runs the default schedule once. This sucks, but this whole API is incomplete and this was the minimal changeset. 5. `time_system` and `tick_global_task_pools_on_main_thread` no longer use exclusive systems to attempt to force scheduling order 6. Implemetnation strategy for fixed timesteps 7. `AssetStage` was migrated to `AssetSet` without reintroducing command flush points. These did not appear to be used, and it's nice to remove these bottlenecks. 8. Migration of `bevy_render/lib.rs` and pipelined rendering. The logic here is unusually tricky, as we have complex scheduling requirements. ## Future Work (ideally before 0.10) - Rename schedule_v3 module to schedule or scheduling - Add a derive macro to states, and likely a `EnumIter` trait of some form - Figure out what exactly to do with the "systems added should basically work by default" problem - Improve ergonomics for working with fixed timesteps and states - Polish FixedTime API to match Time - Rebase and merge #7415 - Resolve all internal ambiguities (blocked on better tools, especially #7442) - Add "base sets" to replace the removed default sets.
bors bot
pushed a commit
that referenced
this pull request
Feb 6, 2023
Huge thanks to @maniwani, @devil-ira, @hymm, @cart, @superdump and @jakobhellermann for the help with this PR. # Objective - Followup #6587. - Minimal integration for the Stageless Scheduling RFC: bevyengine/rfcs#45 ## Solution - [x] Remove old scheduling module - [x] Migrate new methods to no longer use extension methods - [x] Fix compiler errors - [x] Fix benchmarks - [x] Fix examples - [x] Fix docs - [x] Fix tests ## Changelog ### Added - a large number of methods on `App` to work with schedules ergonomically - the `CoreSchedule` enum - `App::add_extract_system` via the `RenderingAppExtension` trait extension method - the private `prepare_view_uniforms` system now has a public system set for scheduling purposes, called `ViewSet::PrepareUniforms` ### Removed - stages, and all code that mentions stages - states have been dramatically simplified, and no longer use a stack - `RunCriteriaLabel` - `AsSystemLabel` trait - `on_hierarchy_reports_enabled` run criteria (now just uses an ad hoc resource checking run condition) - systems in `RenderSet/Stage::Extract` no longer warn when they do not read data from the main world - `RunCriteriaLabel` - `transform_propagate_system_set`: this was a nonstandard pattern that didn't actually provide enough control. The systems are already `pub`: the docs have been updated to ensure that the third-party usage is clear. ### Changed - `System::default_labels` is now `System::default_system_sets`. - `App::add_default_labels` is now `App::add_default_sets` - `CoreStage` and `StartupStage` enums are now `CoreSet` and `StartupSet` - `App::add_system_set` was renamed to `App::add_systems` - The `StartupSchedule` label is now defined as part of the `CoreSchedules` enum - `.label(SystemLabel)` is now referred to as `.in_set(SystemSet)` - `SystemLabel` trait was replaced by `SystemSet` - `SystemTypeIdLabel<T>` was replaced by `SystemSetType<T>` - The `ReportHierarchyIssue` resource now has a public constructor (`new`), and implements `PartialEq` - Fixed time steps now use a schedule (`CoreSchedule::FixedTimeStep`) rather than a run criteria. - Adding rendering extraction systems now panics rather than silently failing if no subapp with the `RenderApp` label is found. - the `calculate_bounds` system, with the `CalculateBounds` label, is now in `CoreSet::Update`, rather than in `CoreSet::PostUpdate` before commands are applied. - `SceneSpawnerSystem` now runs under `CoreSet::Update`, rather than `CoreStage::PreUpdate.at_end()`. - `bevy_pbr::add_clusters` is no longer an exclusive system - the top level `bevy_ecs::schedule` module was replaced with `bevy_ecs::scheduling` - `tick_global_task_pools_on_main_thread` is no longer run as an exclusive system. Instead, it has been replaced by `tick_global_task_pools`, which uses a `NonSend` resource to force running on the main thread. ## Migration Guide - Calls to `.label(MyLabel)` should be replaced with `.in_set(MySet)` - Stages have been removed. Replace these with system sets, and then add command flushes using the `apply_system_buffers` exclusive system where needed. - The `CoreStage`, `StartupStage, `RenderStage` and `AssetStage` enums have been replaced with `CoreSet`, `StartupSet, `RenderSet` and `AssetSet`. The same scheduling guarantees have been preserved. - Systems are no longer added to `CoreSet::Update` by default. Add systems manually if this behavior is needed, although you should consider adding your game logic systems to `CoreSchedule::FixedTimestep` instead for more reliable framerate-independent behavior. - Similarly, startup systems are no longer part of `StartupSet::Startup` by default. In most cases, this won't matter to you. - For example, `add_system_to_stage(CoreStage::PostUpdate, my_system)` should be replaced with - `add_system(my_system.in_set(CoreSet::PostUpdate)` - When testing systems or otherwise running them in a headless fashion, simply construct and run a schedule using `Schedule::new()` and `World::run_schedule` rather than constructing stages - Run criteria have been renamed to run conditions. These can now be combined with each other and with states. - Looping run criteria and state stacks have been removed. Use an exclusive system that runs a schedule if you need this level of control over system control flow. - For app-level control flow over which schedules get run when (such as for rollback networking), create your own schedule and insert it under the `CoreSchedule::Outer` label. - Fixed timesteps are now evaluated in a schedule, rather than controlled via run criteria. The `run_fixed_timestep` system runs this schedule between `CoreSet::First` and `CoreSet::PreUpdate` by default. - Command flush points introduced by `AssetStage` have been removed. If you were relying on these, add them back manually. - Adding extract systems is now typically done directly on the main app. Make sure the `RenderingAppExtension` trait is in scope, then call `app.add_extract_system(my_system)`. - the `calculate_bounds` system, with the `CalculateBounds` label, is now in `CoreSet::Update`, rather than in `CoreSet::PostUpdate` before commands are applied. You may need to order your movement systems to occur before this system in order to avoid system order ambiguities in culling behavior. - the `RenderLabel` `AppLabel` was renamed to `RenderApp` for clarity - `App::add_state` now takes 0 arguments: the starting state is set based on the `Default` impl. - Instead of creating `SystemSet` containers for systems that run in stages, simply use `.on_enter::<State::Variant>()` or its `on_exit` or `on_update` siblings. - `SystemLabel` derives should be replaced with `SystemSet`. You will also need to add the `Debug`, `PartialEq`, `Eq`, and `Hash` traits to satisfy the new trait bounds. - `with_run_criteria` has been renamed to `run_if`. Run criteria have been renamed to run conditions for clarity, and should now simply return a bool. - States have been dramatically simplified: there is no longer a "state stack". To queue a transition to the next state, call `NextState::set` ## TODO - [x] remove dead methods on App and World - [x] add `App::add_system_to_schedule` and `App::add_systems_to_schedule` - [x] avoid adding the default system set at inappropriate times - [x] remove any accidental cycles in the default plugins schedule - [x] migrate benchmarks - [x] expose explicit labels for the built-in command flush points - [x] migrate engine code - [x] remove all mentions of stages from the docs - [x] verify docs for States - [x] fix uses of exclusive systems that use .end / .at_start / .before_commands - [x] migrate RenderStage and AssetStage - [x] migrate examples - [x] ensure that transform propagation is exported in a sufficiently public way (the systems are already pub) - [x] ensure that on_enter schedules are run at least once before the main app - [x] re-enable opt-in to execution order ambiguities - [x] revert change to `update_bounds` to ensure it runs in `PostUpdate` - [x] test all examples - [x] unbreak directional lights - [x] unbreak shadows (see 3d_scene, 3d_shape, lighting, transparaency_3d examples) - [x] game menu example shows loading screen and menu simultaneously - [x] display settings menu is a blank screen - [x] `without_winit` example panics - [x] ensure all tests pass - [x] SubApp doc test fails - [x] runs_spawn_local tasks fails - [x] [Fix panic_when_hierachy_cycle test hanging](alice-i-cecile#120) ## Points of Difficulty and Controversy **Reviewers, please give feedback on these and look closely** 1. Default sets, from the RFC, have been removed. These added a tremendous amount of implicit complexity and result in hard to debug scheduling errors. They're going to be tackled in the form of "base sets" by @cart in a followup. 2. The outer schedule controls which schedule is run when `App::update` is called. 3. I implemented `Label for `Box<dyn Label>` for our label types. This enables us to store schedule labels in concrete form, and then later run them. I ran into the same set of problems when working with one-shot systems. We've previously investigated this pattern in depth, and it does not appear to lead to extra indirection with nested boxes. 4. `SubApp::update` simply runs the default schedule once. This sucks, but this whole API is incomplete and this was the minimal changeset. 5. `time_system` and `tick_global_task_pools_on_main_thread` no longer use exclusive systems to attempt to force scheduling order 6. Implemetnation strategy for fixed timesteps 7. `AssetStage` was migrated to `AssetSet` without reintroducing command flush points. These did not appear to be used, and it's nice to remove these bottlenecks. 8. Migration of `bevy_render/lib.rs` and pipelined rendering. The logic here is unusually tricky, as we have complex scheduling requirements. ## Future Work (ideally before 0.10) - Rename schedule_v3 module to schedule or scheduling - Add a derive macro to states, and likely a `EnumIter` trait of some form - Figure out what exactly to do with the "systems added should basically work by default" problem - Improve ergonomics for working with fixed timesteps and states - Polish FixedTime API to match Time - Rebase and merge #7415 - Resolve all internal ambiguities (blocked on better tools, especially #7442) - Add "base sets" to replace the removed default sets.
bors bot
pushed a commit
to bevyengine/bevy-website
that referenced
this pull request
Mar 6, 2023
## How This Works For the Bevy 0.10 release blog post (and for the first time ever), I'm publicly opening the doors to other people writing blog post sections. Specifically, if you worked on a feature in a substantial way and are interested in presenting it, you can now ask to claim a section by leaving a comment in this PR. If you claim a section, submit a pull request to the `release-0.10.0` branch in this repo. For the next week, we will be filling in sections (the release target is Saturday March 4th). Please don't claim a section if you don't plan on completing it within that timeline. Also don't claim a section if you weren't an active participant in the design and implementation of the change (unless you are a Maintainer or SME). I will claim any unclaimed sections. Try to match the style of previous release blog posts as much as possible. 1. Show, don't tell. Don't bombard people with information. Avoid large walls of text _and_ large walls of code. Prefer the pattern "byte sized description of one thing" -> "example code/picture/video contextualizing that one thing" -> repeat. Take readers on a journey step by simple step. 2. Don't use up reader's "mental bandwidth" without good reason. We can't afford page-long descriptions of minor bug fixes. If it isn't a "headliner change", keep the description short and sweet. If a change is self describing, let it do that (ex: We now support this new mesh shape primitive ... this is what it looks like). If it is a "headliner change", still try to keep it reasonable. We always have a lot to cover. 3. In slight competition with point (2), don't omit interesting technical information when it is truly fun and engaging. A good chunk of our users are highly technical and enjoy learning how the sausage is made. Try to strike a balance between "terse and simple" and "nerdy details". 4. When relevant, briefly describe the problem being solved first, then describe the solution we chose. This contextualizes the change and gives the feature value and purpose. 5. When possible, provide visuals. They create interest / keep people hooked / break up the monotony. 6. Record images and videos at the default bevy resolution (1280x720) 7. Provide an accurate listing of authors that meaningfully contributed to the feature. Try to sort in order of "contribution scale". This is hard to define, but try to be fair. When in doubt, ask other contributors, SMEs, and/or maintainers. 8. Provide numbers and graphs where possible. If something is faster, use numbers to back it up. We don't (yet) have automated graph generation in blog post style, so send data / info to me (@cart) if you want a graph made. ## Headliners Headliners are our "big ticket high importance / high profile" changes. They are listed briefly at the beginning of the blog post, their entries are roughly sorted "to the top", and they are given priority when it comes to "space in the blog post". If you think we missed something (or didn't prioritize something appropriately), let us know. * ECS Schedule v3 (previously known as "stageless") * Partial Android Support * Depth and Normal Prepass * Environment Map Lighting * Cascaded Shadow Maps * Distance and Atmospheric Fog * Smooth Skeletal Animation Transitions * Enable Parallel Pipelined Rendering * Windows as Entities * Renderer Optimizations * ECS Optimizations ## Sections These are the sections we will cover in the blog post. If a section has been claimed, it will have `(claimed by X)` in the title. If it is unclaimed it will have `(unclaimed)` in the title. Let us know if we missed a section. We don't cover every feature, but we should cover pretty much everything that would be interesting to users. Note that what is interesting or challenging to implement is not necessarily something that is relevant to our blog post readers. And sometimes the reverse is true! If you believe a section should be split up or reorganized, just bring it up here and we can discuss it. ### ~~Schedule V3 (claimed by @alice-i-cecile)~~ * [Migrate engine to Schedule v3][7267] * [Add `bevy_ecs::schedule_v3` module][6587] * [Stageless: fix unapplied systems][7446] * [Stageless: move final apply outside of spawned executor][7445] * Sets * Base Sets * [Base Sets][7466] * Reporting * [Report sets][7756] * [beter cycle reporting][7463] * Run Conditions * [Add condition negation][7559] * [And/Or][7605] * [Add more common run conditions][7579] * States * [States derive macro][7535] * System Piping Flexibility * [Support piping exclusive systems][7023] * [Allow piping run conditions][7547] ### ~~Depth and Normal Prepass (claimed by @IceSentry)~~ * [Add depth and normal prepass][6284] * [Move prepass functions to prepass_utils][7354] ### ~~Distance and Atmospheric Fog (claimed by @coreh)~~ * [Add Distance and Atmospheric Fog support][6412] ### ~~Cascaded Shadow Maps (claimed by @cart)~~ * [Cascaded shadow maps.][7064] * [Better cascades config defaults + builder, tweak example configs][7456] ### ~~Environment Map Lighting (claimed by @cart)~~ * [EnvironmentMapLight, BRDF Improvements][7051] * [Webgl2 support][7737] ### ~~Tonemapping options (claimed by @cart)~~ * [Initial tonemapping options][7594] ### ~~Android support + unification (claimed by @mockersf)~~ * [IOS, Android... same thing][7493] ### ~~Windows as Entities (claimed by @Aceeri)~~ * [Windows as Entities][5589] * [break feedback loop when moving cursor][7298] * [Fix `Window` feedback loop between the OS and Bevy][7517] ### ~~Enable Parallel Pipelined Rendering (claimed by @james7132)~~ * [Pipelined Rendering][6503] * [Stageless: add a method to scope to always run a task on the scope thread][7415] * [Separate Extract from Sub App Schedule][7046] ### ~~Smooth Skeletal Animation Transitions (claimed by @james7132)~~ * [Smooth Transition between Animations][6922] ### ~~Spatial Audio (claimed by @harudagondi)~~ * [Spatial Audio][6028] ### ~~Shader Processor Features (claimed by @cart)~~ * [Shader defs can now have a value][5900] * [Shaders can now have #else ifdef chains][7431] * [Define shader defs in shader][7518] ### ~~Shader Flexibility Improvements (claimed by @cart)~~ * [add ambient lighting hook][5428] * [Refactor Globals and View structs into separate shaders][7512] ### ~~Renderer Optimizations (claimed by @james7132)~~ * [bevy_pbr: Avoid copying structs and using registers in shaders][7069] * [Flatten render commands][6885] * [Replace UUID based IDs with a atomic-counted ones][6988] * [improve compile time by type-erasing wgpu structs][5950] * [Shrink DrawFunctionId][6944] * [Shrink ComputedVisibility][6305] * [Reduce branching in TrackedRenderPass][7053] * [Make PipelineCache internally mutable.][7205] * [Improve `Color::hex` performance][6940] * [Support recording multiple CommandBuffers in RenderContext][7248] * [Parallelized transform propagation][4775] * [Introduce detailed_trace macro, use in TrackedRenderPass][7639] * [Optimize color computation in prepare_uinodes][7311] * [Directly extract joints into SkinnedMeshJoints][6833] * [Parallelize forward kinematics animation systems][6785] * [Move system_commands spans into apply_buffers][6900] * [Reduce the use of atomics in the render phase][7084] ### ~~ECS Optimizations (claimed by @james7132 )~~ * [Remove redundant table and sparse set component IDs from Archetype][4927] * [Immutable sparse sets for metadata storage][4928] * [Replace BlobVec's swap_scratch with a swap_nonoverlapping][4853] * [Use T::Storage::STORAGE_TYPE to optimize out unused branches][6800] * [Remove unnecessary branching from bundle insertion][6902] * [Split Component Ticks][6547] * [use bevy_utils::HashMap for better performance. TypeId is predefined …][7642] * [Extend EntityLocation with TableId and TableRow][6681] * [Basic adaptive batching for parallel quer- [Speed up `CommandQueue` by storing commands more densely][6391]y iteration][4777] ### ~~Reflect Improvements (claimed by @cart)~~ * [bevy_reflect: Add `ReflectFromReflect` (v2)][6245] * [Add reflection support for VecDeque][6831] * [reflect: add `insert` and `remove` methods to `List`][7063] * [Add `remove` method to `Map` reflection trait.][6564] * [bevy_reflect: Fix binary deserialization not working for unit structs][6722] * [Add `TypeRegistrationDeserializer` and remove `BorrowedStr`][7094] * [bevy_reflect: Add simple enum support to reflection paths][6560] * [Enable deriving Reflect on structs with generic types][7364] * [bevy_reflect: Support tuple reflection paths][7324] * [bevy_reflect: Pre-parsed paths][7321] * [bevy_ecs: ReflectComponentFns without World][7206] ### ~~AsBindGroup Improvements (claimed by @cart)~~ * [Support storage buffers in derive `AsBindGroup`][6129] * [Support raw buffers in AsBindGroup][7701] ### ~~Cylinder Shape (claimed by @cart)~~ * [Add cylinder shape][6809] ### ~~Subdividable Plane Shape (claimed by @cart)~~ * [added subdivisions to shape::Plane][7546] ### ~~StandardMaterial Blend Modes (claimed by @coreh)~~ * [Standard Material Blend Modes][6644] ### ~~Configurable Visibility Component (claimed by @cart)~~ * [enum `Visibility` component][6320] ### Task Improvements (claimed by @cart) * [Fix panicking on another scope][6524] * [Add thread create/destroy callbacks to TaskPool][6561] * [Thread executor for running tasks on specific threads.][7087] * [await tasks to cancel][6696] * [Stageless: move MainThreadExecutor to schedule_v3][7444] * [Stageless: close the finish channel so executor doesn't deadlock][7448] ### ~~Upgrade to wgpu 0.15 (claimed by @cart)~~ * [Wgpu 0.15][7356] ### ~~Expose Bindless / Non-uniform Indexing Support (claimed by @cart)~~ * [Request WGPU Capabilities for Non-uniform Indexing][6995] ### ~~Cubic Spline (claimed by @aevyrie)~~ * [Bezier][7653] ### ~~Revamp Bloom (claimed by @JMS55)~~ * [Revamp bloom](bevyengine/bevy#6677) ### ~~Use Prepass Shaders for Shadows (claimed by @superdump)~~ * [use prepass shaders for shadows](bevyengine/bevy#7784) ### ~~AccessKit (claimed by @alice-i-cecile)~~ * [accesskit](bevyengine/bevy#6874) ### ~~Camera Output Modes (claimed by @cart)~~ * [camera output modes](bevyengine/bevy#7671) ### ~~SystemParam Improvements (claimed by @JoJoJet)~~ * [Make the `SystemParam` derive macro more flexible][6694] * [Add a `SystemParam` primitive for deferred mutations; allow `#[derive]`ing more types of SystemParam][6817] ### ~~Gamepad Improvements (claimed by @cart)~~ * [Gamepad events refactor][6965] * [add `Axis::devices` to get all the input devices][5400] ### ~~Input Methods (claimed by @cart)~~ * [add Input Method Editor support][7325] ### ~~Color Improvements (claimed by @cart)~~ * [Add LCH(ab) color space to `bevy_render::color::Color`][7483] * [Add a more familiar hex color entry][7060] ### ~~Split Up CorePlugin (claimed by @cart)~~ * [Break `CorePlugin` into `TaskPoolPlugin`, `TypeRegistrationPlugin`, `FrameCountPlugin`.][7083] ### ~~ExtractComponent Derive (claimed by @cart)~~ * [Extract component derive][7399] ### ~~Added OpenGL and DX11 Backends By Default (claimed by @cart)~~ * [add OpenGL and DX11 backends][7481] ### ~~UnsafeWorldCell (claimed by @BoxyUwU)~~ * [Move all logic to `UnsafeWorldCell`][7381] * [Rename `UnsafeWorldCellEntityRef` to `UnsafeEntityCell`][7568] ### ~~Entity Commands (claimed by @cart)~~ * [Add a trait for commands that run for a given `Entity`][7015] * [Add an extension trait to `EntityCommands` to update hierarchy while preserving `GlobalTransform`][7024] * [Add ReplaceChildren and ClearChildren EntityCommands][6035] ### ~~Iterate EntityRef (claimed by @james7132)~~ * [Allow iterating over with EntityRef over the entire World][6843] ### ~~Ref Queries (@JoJoJet)~~ * [Added Ref to allow immutable access with change detection][7097] ### ~~Taffy Upgrade (claimed by @cart)~~ * [Upgrade to Taffy 0.2][6743] ### ~~Relative Cursor Position (claimed by @cart)~~ * [Relative cursor position][7199] ### ~~Const UI Config (claimed by @cart)~~ * [Add const to methods and const defaults to bevy_ui][5542] ### ~~Examples (claimed by @cart)~~ * [Add pixelated Bevy to assets and an example][6408] * [Organized scene_viewer into plugins for reuse and organization][6936] ### ~~CI Improvements (claimed by @cart)~~ * [add rust-version for MSRV and CI job to check][6852] * [msrv: only send a message on failure during the actual msrv part][7532] * [Make CI friendlier][7398] * [Fix CI welcome message][7428] * [add an action to ask for a migration guide when one is missing][7507] ### ~~SMEs (@cart)~~ This was already covered in another blog post. Just briefly call out what they are and that this is the first release that used them. Link to the other blog post. * [Subject Matter Experts and new Bevy Org docs][7185] [4775]: bevyengine/bevy#4775 [4777]: bevyengine/bevy#4777 [4853]: bevyengine/bevy#4853 [4927]: bevyengine/bevy#4927 [4928]: bevyengine/bevy#4928 [5400]: bevyengine/bevy#5400 [5428]: bevyengine/bevy#5428 [5542]: bevyengine/bevy#5542 [5589]: bevyengine/bevy#5589 [5900]: bevyengine/bevy#5900 [5950]: bevyengine/bevy#5950 [6028]: bevyengine/bevy#6028 [6035]: bevyengine/bevy#6035 [6129]: bevyengine/bevy#6129 [6179]: bevyengine/bevy#6179 [6245]: bevyengine/bevy#6245 [6284]: bevyengine/bevy#6284 [6305]: bevyengine/bevy#6305 [6320]: bevyengine/bevy#6320 [6391]: bevyengine/bevy#6391 [6408]: bevyengine/bevy#6408 [6412]: bevyengine/bevy#6412 [6503]: bevyengine/bevy#6503 [6524]: bevyengine/bevy#6524 [6547]: bevyengine/bevy#6547 [6557]: bevyengine/bevy#6557 [6560]: bevyengine/bevy#6560 [6561]: bevyengine/bevy#6561 [6564]: bevyengine/bevy#6564 [6587]: bevyengine/bevy#6587 [6644]: bevyengine/bevy#6644 [6649]: bevyengine/bevy#6649 [6681]: bevyengine/bevy#6681 [6694]: bevyengine/bevy#6694 [6696]: bevyengine/bevy#6696 [6722]: bevyengine/bevy#6722 [6743]: bevyengine/bevy#6743 [6785]: bevyengine/bevy#6785 [6800]: bevyengine/bevy#6800 [6802]: bevyengine/bevy#6802 [6809]: bevyengine/bevy#6809 [6817]: bevyengine/bevy#6817 [6831]: bevyengine/bevy#6831 [6833]: bevyengine/bevy#6833 [6843]: bevyengine/bevy#6843 [6852]: bevyengine/bevy#6852 [6885]: bevyengine/bevy#6885 [6900]: bevyengine/bevy#6900 [6902]: bevyengine/bevy#6902 [6922]: bevyengine/bevy#6922 [6926]: bevyengine/bevy#6926 [6936]: bevyengine/bevy#6936 [6940]: bevyengine/bevy#6940 [6944]: bevyengine/bevy#6944 [6965]: bevyengine/bevy#6965 [6988]: bevyengine/bevy#6988 [6995]: bevyengine/bevy#6995 [7015]: bevyengine/bevy#7015 [7023]: bevyengine/bevy#7023 [7024]: bevyengine/bevy#7024 [7046]: bevyengine/bevy#7046 [7051]: bevyengine/bevy#7051 [7053]: bevyengine/bevy#7053 [7060]: bevyengine/bevy#7060 [7063]: bevyengine/bevy#7063 [7064]: bevyengine/bevy#7064 [7069]: bevyengine/bevy#7069 [7083]: bevyengine/bevy#7083 [7084]: bevyengine/bevy#7084 [7087]: bevyengine/bevy#7087 [7094]: bevyengine/bevy#7094 [7097]: bevyengine/bevy#7097 [7185]: bevyengine/bevy#7185 [7199]: bevyengine/bevy#7199 [7205]: bevyengine/bevy#7205 [7206]: bevyengine/bevy#7206 [7248]: bevyengine/bevy#7248 [7267]: bevyengine/bevy#7267 [7298]: bevyengine/bevy#7298 [7311]: bevyengine/bevy#7311 [7321]: bevyengine/bevy#7321 [7324]: bevyengine/bevy#7324 [7325]: bevyengine/bevy#7325 [7354]: bevyengine/bevy#7354 [7356]: bevyengine/bevy#7356 [7364]: bevyengine/bevy#7364 [7381]: bevyengine/bevy#7381 [7398]: bevyengine/bevy#7398 [7399]: bevyengine/bevy#7399 [7415]: bevyengine/bevy#7415 [7428]: bevyengine/bevy#7428 [7431]: bevyengine/bevy#7431 [7444]: bevyengine/bevy#7444 [7445]: bevyengine/bevy#7445 [7446]: bevyengine/bevy#7446 [7448]: bevyengine/bevy#7448 [7456]: bevyengine/bevy#7456 [7463]: bevyengine/bevy#7463 [7466]: bevyengine/bevy#7466 [7481]: bevyengine/bevy#7481 [7483]: bevyengine/bevy#7483 [7493]: bevyengine/bevy#7493 [7507]: bevyengine/bevy#7507 [7510]: bevyengine/bevy#7510 [7512]: bevyengine/bevy#7512 [7517]: bevyengine/bevy#7517 [7518]: bevyengine/bevy#7518 [7532]: bevyengine/bevy#7532 [7535]: bevyengine/bevy#7535 [7546]: bevyengine/bevy#7546 [7547]: bevyengine/bevy#7547 [7559]: bevyengine/bevy#7559 [7568]: bevyengine/bevy#7568 [7579]: bevyengine/bevy#7579 [7594]: bevyengine/bevy#7594 [7605]: bevyengine/bevy#7605 [7639]: bevyengine/bevy#7639 [7642]: bevyengine/bevy#7642 [7653]: bevyengine/bevy#7653 [7701]: bevyengine/bevy#7701 [7737]: bevyengine/bevy#7737 [7756]: bevyengine/bevy#7756 Co-authored-by: François <mockersf@gmail.com> Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Mike <mike.hsu@gmail.com> Co-authored-by: Boxy <supbscripter@gmail.com> Co-authored-by: IceSentry <c.giguere42@gmail.com> Co-authored-by: JoJoJet <21144246+JoJoJet@users.noreply.github.com> Co-authored-by: Aevyrie <aevyrie@gmail.com> Co-authored-by: James Liu <contact@jamessliu.com> Co-authored-by: Marco Buono <thecoreh@gmail.com> Co-authored-by: Aceeri <conmcclusk@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
spawn_on_scopeto run these. For the render thread this is incorrect as callingspawn_on_scopethere runs tasks on the main thread. It should instead run these on the render thread and only run nonsend systems on the main thread.Solution
Scopefor spawning tasks on the scope.spawn_on_scopenow always runs the task on the thread the scope is running on.spawn_on_externalspawns onto the external executor than is optionally passed in. If None is passedspawn_on_externalwill spawn onto the scope executor.Changelog
Migration Guide