Render Recovery

[atlv24]

Objective

• Recover from rendering errors.
• Another step towards render recovery after RenderCreation refactor #22714 Minor Render init refactor #22759 and cleanup bevy_render/lib.rs #16481

Solution

• Use wgpu::Device::set_device_lost_callback and wgpu::Device::on_uncaptured_error to listen for errors.
• Add a state machine for the renderer
• Update it on error
• Add a RenderErrorHandler to let users specify behavior on error by returning a specific RenderErrorPolicy
• This lets us for example ignore validation errors, delete responsible entities, or reload the renderer if the device was lost.

Testing

• Add example for triggering and recovering from rendering errors #22757 with any of

    .insert_resource(bevy_render::error_handler::RenderErrorHandler(|_, _, _| {
        bevy_render::error_handler::RenderErrorPolicy::StopRendering
    }))

    .insert_resource(bevy_render::error_handler::RenderErrorHandler(|_, _, _| {
        bevy_render::error_handler::RenderErrorPolicy::Recover(default())
    }))

Note: no release note yet, as recovery does not exactly work well: this PR gets us to the point of being able to care about it, but we currently instantly crash on recover due to gpu resources not existing anymore. We need to build more resilience before publicizing imo.

[IQuick143]

Can we really just instantly transition from Initializing into Ready?

[IQuick143]

Maybe the transition into Ready should be done by RenderStartup itself (in case it has its own fallibility).

[atlv24]

I think its better to keep all the state-machine-y things in the function together

[alice-i-cecile]

I'm fine with keeping this together for now, but I suspect we may need to refactor this later.

[valaphee]

This should also solve #21407

[IQuick143]

It's not quite solving it yet, but it gets us close.

[alice-i-cecile]

The naming of update_state makes it quite hard to understand what this method call is doing. I would prefer a rename, but would accept a comment.

[atlv24]

it used to be called update and i asked for a bikeshed and thats what we came up with, but im open to better name suggestions. it updates the state machine that handles the renderer and device lifecycle. i'll add a comment for now saying as much

[alice-i-cecile]

Maybe something like check_render_device_lifecycle? IMO we should try and capture a) renderer / device b) lifecycle and c) some form of check or "should run" or something to indicate that it returns a bool that should be used.

[alice-i-cecile]

No blocking feedback, and wgpu maintainers were reasonably happy with this. I'm not equipped to give a full approval here though; I don't know the domain well enough.

[IceSentry]

So, the logic of everything is great and it does what it's supposed to.

I don't like how it feels like it does 4 different things at once but I haven't managed to untangle it.

I think it might feel mildly better to name the new module render_state and error handling just happens to be part of handling the state instead of the state being managed by something called error_handler. I would also just move the RenderStartup to be inside the state machine itself because that state machine is already aware of it so it feels a bit unnecessary to keep them separate. The update_state function already does a bunch of things and mutates the world so it seems appropriate for it to just run the schedule when it needs to. Especially if we start running it on recovery.

With that said, I think the current state of things works and we can rename it later. I don't want to block work on naming things.

[atlv24]

I've done the renames requested, although im not sure i agree with them. The point of calling it error_handler was more for the user facing api:

bevy::render::error_handler::{RenderErrorHandler, RenderErrorPolicy}

vs

bevy::render::render_state::{RenderErrorHandler, RenderErrorPolicy}

[atlv24]

Im just gonna make the mod private and re-export from the top level instead

[atlv24]

nah... it was just better before im gonna keep error_handler for now my bad