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.

[IceSentry]

I'm not sure I understand why a new schedule is needed here? What's wrong with using Render?

[atlv24]

this schedule runs Render, if it was Render it would infinite loop. the point is to gate running Render. notice RenderRecovery is private, also, so it cannot be circumvented. its an impl detail

[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