# Objective

- Reduce panics in bevy renderer
- Continuation of Render Recovery efforts #22761 (can't reinitialize if
we panic. I hit every single one of these on the device lost path.)

## Solution

- Use early outs and error!s instead of hard panics.
- If the panics are needed to maintain some kind of invariant, that
should be documented. I don't see any comment saying they do, so I am
assuming they do not. Correct me if I am wrong.

## Testing

- CI

---------

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Brennan Paciorek <50780403+BrennanPaciorek@users.noreply.github.com>
Co-authored-by: IceSentry <IceSentry@users.noreply.github.com>

# Objective

- Continue render recovery effort #22761
- Part of goal #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 #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.

…gine#23349)

# Objective

- Reduce panics in bevy renderer
- Continuation of Render Recovery efforts bevyengine#22761 (can't reinitialize if
we panic. I hit every single one of these on the device lost path.)

## Solution

- Use early outs and error!s instead of hard panics.
- If the panics are needed to maintain some kind of invariant, that
should be documented. I don't see any comment saying they do, so I am
assuming they do not. Correct me if I am wrong.

## Testing

- CI

---------

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Brennan Paciorek <50780403+BrennanPaciorek@users.noreply.github.com>
Co-authored-by: IceSentry <IceSentry@users.noreply.github.com>

# 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.