Conversation
|
Can't we just nuke the render world, and then re-run the RenderStartup schedule? |
|
We can, but there's stuff in the render world which should be preserved IMO. We'd have to re-extract a lot of stuff unnecessarily, reprocess all shaders, and we'd also lose any user modifications/data on Render World. It also couples us more strongly to having a Render World. I would rather these become tied to the Render Device via relations or something in that line of thinking |
|
This PR adds a few (14074) ambiguities to the render app 😄 |
crates/bevy_render/src/lib.rs
Outdated
| struct InitGpuResources; | ||
|
|
||
| /// Constructs a `T` resource with `from_world` and inserts it. | ||
| pub fn init_gpu_resource<T: Resource + FromWorld>(world: &mut World) { |
There was a problem hiding this comment.
Reviewers: this is the bit that actually matters!
alice-i-cecile
left a comment
There was a problem hiding this comment.
We can do better with docs and we should probably change the executor type for the schedule you added, but this is a nice and simple approach. We can easily change the strategy to something else later, because there's just a single extension method to update.
# Objective - Fallback image samplers need to be recreated on RenderDevice reset. - Continue Render Recovery efforts #23350 #22761 - Part of goal #23029 ## Solution - They have a bit more involved ordering requirements, thats why I split them out to this PR. ## Testing - ran some examples, and ambiguity detection
# Objective - Continue Render Recovery efforts #23350 #22761 #23433 #23458 - Part of goal #23029 - make indirect parameter buffers and batched instance buffers reinitalize on recovery ## Solution - split out the stuff that shouldnt be reinitialized from them - use init_gpu_resource ## Testing - examples run - in combination with the rest of the fixes and a couple other local changes i havent PRd yet, render_recovery example works.
# Objective - Continue Render Recovery efforts #23350 #22761 #23433 - Part of goal #23029 ## Solution - Clear view upscaling pipelines on reload ## Testing - existing examples run fine. render_recovery example does not work yet, but in combination with the other fixes and some not-yet-PR'd fixes this is a load bearing change needed for it to work --------- Co-authored-by: IceSentry <IceSentry@users.noreply.github.com>
# Objective - Continue Render Recovery efforts #23350 #22761 #23433 #23458 #23459 - Part of goal #23029 - Make shaders work after reload ## Solution - This is a kinda ugly hack. I explored like 5 different ways of doing this, none of them are satisfying and they are all much larger diffs than this. The crux of the problem is that the composer's capabilities may differ on the new device, due to switching from dedicated to integrated GPU. This means that we cannot even retain the composed modules. The ShaderCache and PipelineCache are quite annoyingly tangled, and I have some glimpses of how to fix it in the future but I dont want to block render recovery on it. - For now, we just do the kinda brute force thing and reinsert all the shaders, recompose etc ## Testing - examples run - in combination with the rest of the fixes and a couple other local changes i havent PRd yet, render_recovery example works.
# Objective - Continue Render Recovery efforts #23350 #22761 #23433 #23458 #23459 #23461 - Part of goal #23029 - Make render assets exist again after reload ## Solution - We re-extract everything from the main world. This assumes things *exist* on the main world, which is not actually always true. This is enough for most examples and simple usage to be recoverable, but it's really butting up against bevy_asset deficiencies. The next step to making this truly production grade is asset streaming, which will probably be my next goal. ## Testing - examples run - in combination with the rest of the fixes, render_recovery example works.
# Objective - Completes goal and closes #23029 - Culmination of #22761, #23350, #23349, #23433, #23458, #23444, #23459, #23461, #23463, #22714, #22759, #16481 ## Solution - Add a release note. - Re-export a wgpu type that you need to match on to handle errors. ## Testing - cargo run --example render_recovery with all the other PRs merged in. Press 5 and then V, the app will not crash. Note that D for "destroy device" will still crash: this is a WGPU problem resolved by gfx-rs/wgpu#9281. # Note I opted not to change the default recovery behavior yet. I believe we need testing in user projects and just general trodding of this code path before committing to a new default. It works in a simple example, it might not work in a complex project. We need to field test this and likely iterate to really call this ready IMO.
# Objective - Continue render recovery effort bevyengine#22761 - Part of goal bevyengine#23029 - Reload gpu resources easily ## Solution - Add an extension trait to insert resources on RenderStartup using from_world - replace almost every usage of init_resource that holds anything derived from a RenderDevice with init_gpu_resource so that it may be reinitialized on recovery - Note: "almost every" because there is a handful of slightly more involved cases I will leave to a follow ups. ## Testing - render recovery example still crashes, i have a branch with it working that i am just pulling out reviewable bits from - we should also verify that this doesnt break examples, as it does slightly modify behavior: gpu resources are initialized slightly later than they used to be, because they wait until RenderStartup instead of doing it immediately. - i mostly want to get the largest part of the change out of the way first
# Objective - Fallback image samplers need to be recreated on RenderDevice reset. - Continue Render Recovery efforts bevyengine#23350 bevyengine#22761 - Part of goal bevyengine#23029 ## Solution - They have a bit more involved ordering requirements, thats why I split them out to this PR. ## Testing - ran some examples, and ambiguity detection
# Objective - Continue Render Recovery efforts bevyengine#23350 bevyengine#22761 bevyengine#23433 bevyengine#23458 - Part of goal bevyengine#23029 - make indirect parameter buffers and batched instance buffers reinitalize on recovery ## Solution - split out the stuff that shouldnt be reinitialized from them - use init_gpu_resource ## Testing - examples run - in combination with the rest of the fixes and a couple other local changes i havent PRd yet, render_recovery example works.
# Objective - Continue Render Recovery efforts bevyengine#23350 bevyengine#22761 bevyengine#23433 - Part of goal bevyengine#23029 ## Solution - Clear view upscaling pipelines on reload ## Testing - existing examples run fine. render_recovery example does not work yet, but in combination with the other fixes and some not-yet-PR'd fixes this is a load bearing change needed for it to work --------- Co-authored-by: IceSentry <IceSentry@users.noreply.github.com>
# Objective - Continue Render Recovery efforts bevyengine#23350 bevyengine#22761 bevyengine#23433 bevyengine#23458 bevyengine#23459 - Part of goal bevyengine#23029 - Make shaders work after reload ## Solution - This is a kinda ugly hack. I explored like 5 different ways of doing this, none of them are satisfying and they are all much larger diffs than this. The crux of the problem is that the composer's capabilities may differ on the new device, due to switching from dedicated to integrated GPU. This means that we cannot even retain the composed modules. The ShaderCache and PipelineCache are quite annoyingly tangled, and I have some glimpses of how to fix it in the future but I dont want to block render recovery on it. - For now, we just do the kinda brute force thing and reinsert all the shaders, recompose etc ## Testing - examples run - in combination with the rest of the fixes and a couple other local changes i havent PRd yet, render_recovery example works.
# Objective - Continue Render Recovery efforts bevyengine#23350 bevyengine#22761 bevyengine#23433 bevyengine#23458 bevyengine#23459 bevyengine#23461 - Part of goal bevyengine#23029 - Make render assets exist again after reload ## Solution - We re-extract everything from the main world. This assumes things *exist* on the main world, which is not actually always true. This is enough for most examples and simple usage to be recoverable, but it's really butting up against bevy_asset deficiencies. The next step to making this truly production grade is asset streaming, which will probably be my next goal. ## Testing - examples run - in combination with the rest of the fixes, render_recovery example works.
# Objective - Completes goal and closes bevyengine#23029 - Culmination of bevyengine#22761, bevyengine#23350, bevyengine#23349, bevyengine#23433, bevyengine#23458, bevyengine#23444, bevyengine#23459, bevyengine#23461, bevyengine#23463, bevyengine#22714, bevyengine#22759, bevyengine#16481 ## Solution - Add a release note. - Re-export a wgpu type that you need to match on to handle errors. ## Testing - cargo run --example render_recovery with all the other PRs merged in. Press 5 and then V, the app will not crash. Note that D for "destroy device" will still crash: this is a WGPU problem resolved by gfx-rs/wgpu#9281. # Note I opted not to change the default recovery behavior yet. I believe we need testing in user projects and just general trodding of this code path before committing to a new default. It works in a simple example, it might not work in a complex project. We need to field test this and likely iterate to really call this ready IMO.
Objective
Solution
Testing