Skip to content

init_gpu_resource#23350

Merged
alice-i-cecile merged 3 commits intobevyengine:mainfrom
atlv24:ad/rr-gpu-res
Mar 20, 2026
Merged

init_gpu_resource#23350
alice-i-cecile merged 3 commits intobevyengine:mainfrom
atlv24:ad/rr-gpu-res

Conversation

@atlv24
Copy link
Copy Markdown
Contributor

@atlv24 atlv24 commented Mar 13, 2026

Objective

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

@IQuick143 IQuick143 added A-Rendering Drawing game state to the screen D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Needs-Review Needs reviewer attention (from anyone!) to move forward S-Needs-Testing Testing must be done before this is safe to merge labels Mar 13, 2026
@github-project-automation github-project-automation bot moved this to Needs SME Triage in Rendering Mar 13, 2026
@IQuick143 IQuick143 self-requested a review March 13, 2026 08:47
@jasmine-nominal
Copy link
Copy Markdown
Contributor

Can't we just nuke the render world, and then re-run the RenderStartup schedule?

@atlv24
Copy link
Copy Markdown
Contributor Author

atlv24 commented Mar 13, 2026

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

@mockersf
Copy link
Copy Markdown
Member

This PR adds a few (14074) ambiguities to the render app 😄

struct InitGpuResources;

/// Constructs a `T` resource with `from_world` and inserts it.
pub fn init_gpu_resource<T: Resource + FromWorld>(world: &mut World) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewers: this is the bit that actually matters!

Copy link
Copy Markdown
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@alice-i-cecile alice-i-cecile removed the S-Needs-Review Needs reviewer attention (from anyone!) to move forward label Mar 20, 2026
@alice-i-cecile alice-i-cecile added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Needs-Testing Testing must be done before this is safe to merge labels Mar 20, 2026
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Mar 20, 2026
Merged via the queue into bevyengine:main with commit fd7603f Mar 20, 2026
38 checks passed
@github-project-automation github-project-automation bot moved this from Needs SME Triage to Done in Rendering Mar 20, 2026
github-merge-queue bot pushed a commit that referenced this pull request Mar 22, 2026
# 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
github-merge-queue bot pushed a commit that referenced this pull request Mar 22, 2026
# 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.
github-merge-queue bot pushed a commit that referenced this pull request Mar 22, 2026
# 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>
github-merge-queue bot pushed a commit that referenced this pull request Mar 22, 2026
# 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.
github-merge-queue bot pushed a commit that referenced this pull request Mar 22, 2026
# 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.
github-merge-queue bot pushed a commit that referenced this pull request Mar 23, 2026
# 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.
splo pushed a commit to splo/bevy that referenced this pull request Mar 31, 2026
# 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
splo pushed a commit to splo/bevy that referenced this pull request Mar 31, 2026
# 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
splo pushed a commit to splo/bevy that referenced this pull request Mar 31, 2026
# 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.
splo pushed a commit to splo/bevy that referenced this pull request Mar 31, 2026
# 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>
splo pushed a commit to splo/bevy that referenced this pull request Mar 31, 2026
# 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.
splo pushed a commit to splo/bevy that referenced this pull request Mar 31, 2026
# 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.
splo pushed a commit to splo/bevy that referenced this pull request Mar 31, 2026
# 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Rendering Drawing game state to the screen D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

7 participants