Replace `RenderGraph` with systems #22144

tychedelia · 2025-12-15T23:09:30Z

render-graph-as-systems

This PR removes the RenderGraph in favor of using systems.

Motivation

The RenderGraph API was originally created when the ECS was significantly more immature. It was also created with the intention of supporting an input/output based slot system for managing resources that has never been used. While resource management is an important potential use of a render graph, current rendering code doesn't make use of any patterns relating to it.

Since the ECS has improved, the functionality of Schedule has basically become co-extensive with what the RenderGraph API is doing, i.e. ordering bits of system-like logic relative to one another and executing them in a big chunk. Additionally, while there's still desire for more advanced techniques like resource management in the graph, it's desirable to implement those in ECS terms rather than creating more RenderGraph specific abstraction.

In short, this sets us up to iterate on a more ECS based approach, while deleting ~3k lines of mostly unused code.

Implementation

At a high level: We use Schedule as our "sub-graph." Rather than running the graph, we run a schedule. Systems can be ordered relative to one another.

The render system uses a RenderGraph schedule to define the "root" of the graph. core_pipeline adds a camera_driver system that runs the per-camera schedules. This top level schedule provides an extension point for apps that may want to do custom rendering, or non-camera rendering.

`CurrentView` / `ViewQuery`

When running schedules per-camera in the camera_driver system, we insert a CurrentView resource that's used to mark the currently iterating view. We also add a new param ViewQuery that internally uses this resource to execute the query and skip the system if it doesn't match as a convenience.

`RenderContext`

The RenderContext is now a system param that wraps a Deferred for tracking the state of the current command encoder and queued buffers.

TODO:

Make sure 100% of everything still works.
Benchmark to make sure we don't regress performance
Re-add docs

github-actions · 2025-12-15T23:19:57Z

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes.

github-actions · 2025-12-15T23:20:00Z

It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

cart · 2025-12-15T23:51:09Z

crates/bevy_core_pipeline/src/schedule.rs

+            )
+            .entered();
+
+            world.run_schedule(schedule);


One of the "big" reasons I've pushed back against RenderGraph -> Systems in the past is that it prevents us from parallelizing command encoding in cases like this where we need to run specific, potentially very expensive "subgraphs" in a loop.

The ownership and access patterns in the current system allow for that sort of thing (and were explicitly chosen to enable it).

A few things that I'd like to note:

With the exception of one caveat I'll note in the PR description, this isn't worse than the existing solution in terms of overall parallelism.

In the context of cameras, we effectively currently need to be serial because we re-use ViewTarget textures. Without a higher level resource tracking system, we have to pessimistically assume that cameras need to run in terms of the order they are given due to implicit dependencies.

Something like a "read only" schedule marker has been proposed before to allow running schedules on &World. ECS devs have suggested to me this is feasible.

We do do mutation in the current graph in many places, but have to resort to hack-y atomics usage. It's not crazy that you want to mutate world sometimes (i.e. to insert some gpu resource to be used by the next frame).

I'd like to solve issues around parallelism in the context of more generalized ECS patterns. I have a number of more speculative ideas here, but I think there are a few different directions we could go.

But yeah, we obviously need to make sure we don't regress current state performance.

I think we also need to keep in mind maintenance. This PR manages to remove a lot of code and makes the render graph much more approachable for people that already know bevy's ECS. It's 3.8k less lines of code to maintain. Of course, line of code isn't a super useful metric for many things but I think it's significant enough that it can't just be ignored. With the current render graph, we almost never see PRs to it and I wouldn't be surprised if a big reason for that is that it looks so foreign in bevy and because it's also a lot of very complex code.

atlv24 · 2025-12-16T13:40:08Z

crates/bevy_anti_alias/src/contrast_adaptive_sharpening/mod.rs

+            .add_systems(Render, prepare_cas_pipelines.in_set(RenderSystems::Prepare))
+            .add_systems(
+                Core3d,
+                cas.after(fxaa)


reviewer note: fxaa is ordered after tonemapping, so the .after tonemapping here is redundant thus removed

atlv24 · 2025-12-16T13:49:20Z

crates/bevy_anti_alias/src/taa/mod.rs

+            Core3d,
+            temporal_anti_alias
+                .after(Core3dSystems::StartMainPassPostProcessing)
+                .before(Core3dSystems::PostProcessing),


some ordering constraints were lost here

atlv24

Remember to check Hide whitespace in diff view options!

Some notes:

should we be using fallible systems to more closely match the Result behavior of the original nodes?
some ordering constraints were removed but i think many were redundant. i noted these
tracing infra probably is redundant with system traces now (followup)
can probably use run conditions in a bunch of places too now (followup)
render_context -> ctx could have been a different pr (and is a matter of taste but i agree with it anyways) its just noise here
one of the solari files is jumbled and unreviewable

This is an absolutely colossal amount of work with incredible attention to detail
fantastic job, excited to see this merge. Lots of small fixes bundled here and its pretty much all good. There's some comments that were removed but i dont feel very strongly about them.

Very in favor of this merging, approval will come after comments addressed and pr exits draft status.

I'm going to dig into the CI failures soon

atlv24 · 2025-12-16T14:00:39Z

crates/bevy_core_pipeline/src/core_3d/main_transmissive_pass_3d_node.rs

        start = end;
        result
    })
 }


lets punt this back down to the bottom of the file

atlv24 · 2025-12-16T14:01:45Z

crates/bevy_anti_alias/src/smaa/mod.rs

+            SmaaPreset::Ultra => "SMAA_PRESET_ULTRA".into(),
+        }
+    }
+}


lets punt this back down to the bottom of the file

atlv24 · 2025-12-16T14:12:09Z

crates/bevy_core_pipeline/src/experimental/mip_generation/mod.rs

+    mut ctx: RenderContext,
+) {
+    run_downsample_depth_system(
+        "late_downsample_depth",


the late and early seem to be identical aside from debug string, perhaps we can introduce a const generic and swap the string with it to collapse them into one function

atlv24 · 2025-12-16T14:31:47Z

crates/bevy_pbr/src/meshlet/mod.rs

+                    meshlet_prepass
+                        .after(early_shadow_pass)
+                        .before(Core3dSystems::EndPrepasses),
+                    meshlet_deferred_gbuffer_prepass
+                        .after(meshlet_prepass)
+                        .before(Core3dSystems::EndPrepasses),
+                    meshlet_main_opaque_pass
+                        .after(Core3dSystems::StartMainPass)
+                        .before(Core3dSystems::EndMainPass),


this is not a faithful transcription of the orderings, not sure why its different or if it matters though

atlv24 · 2025-12-16T14:37:03Z

crates/bevy_pbr/src/render/gpu_preprocess.rs

+                    // Early GPU preprocess runs before early prepasses
+                    early_gpu_preprocess
+                        .after(clear_indirect_parameters_metadata)
+                        .before(early_prepass),


this before is redundant, but its fine to leave it for consistency i guess

atlv24 · 2025-12-16T14:55:14Z

crates/bevy_pbr/src/atmosphere/node.rs

+        render_sky_pass.set_viewport(
+            viewport.physical_position.x as f32,
+            viewport.physical_position.y as f32,
+            viewport.physical_size.x as f32,
+            viewport.physical_size.y as f32,
+            viewport.depth.start,
+            viewport.depth.end,
        );


not sure why this is like this now

atlv24 · 2025-12-16T14:57:25Z

crates/bevy_core_pipeline/src/fullscreen_material.rs

    let vertex_state = fullscreen_shader.to_vertex_state();
    let mut desc = RenderPipelineDescriptor {
-        label: Some("post_process_pipeline".into()),
+        label: Some(format!("fullscreen_material_pipeline<{}>", type_name::<T>()).into()),


thank you this is so much better 😭

atlv24 · 2025-12-16T14:59:02Z

crates/bevy_post_process/src/msaa_writeback.rs

-                )
-                .add_render_graph_edge(Core3d, Node3d::MsaaWriteback, Node3d::StartMainPass);
-        }
+        render_app.add_systems(Core3d, msaa_writeback.before(Core3dSystems::EndPrepasses));


why is this before EndPrepasses now? it used to e before StartMainPass

atlv24 · 2025-12-16T15:01:17Z

crates/bevy_solari/src/realtime/node.rs

    prepare::{SolariLightingResources, LIGHT_TILE_BLOCKS, WORLD_CACHE_SIZE},
    SolariLighting,
 };
 use crate::scene::RaytracingSceneBindings;


the diff in this file is horrifying, can you reorder the bits to be closer to the order they used to be in so its easier to review?

We shouldn't have two different solari_lighting systems for dlss/no-dlss.

atlv24 · 2025-12-16T15:01:59Z

crates/bevy_core_pipeline/src/schedule.rs

+        let mut schedule = Schedule::new(Self);
+
+        schedule.set_build_settings(ScheduleBuildSettings {
+            ..Default::default()


why doesnt 2d get auto_insert_apply_deferred: false,?

ci

tychedelia added 2 commits December 15, 2025 15:06

Rewrite RenderGraph to use Schedule.

fa703f0

Merge branch 'main' into render-graph-as-systems

7ac2277

github-actions bot mentioned this pull request Dec 15, 2025

22144 bevyengine/bevy-example-runner#189

Closed

github-project-automation bot added this to Rendering Dec 15, 2025

cart reviewed Dec 15, 2025

View reviewed changes

tychedelia added 2 commits December 15, 2025 16:30

Fmt.

2e0c5a6

Ci.

8ea6a02

IceSentry self-requested a review December 16, 2025 00:36

Insert apply deferred automatically.

e5ca7e2

github-actions bot mentioned this pull request Dec 16, 2025

22144 bevyengine/bevy-example-runner#190

Closed

tychedelia added 4 commits December 15, 2025 19:03

Try pushing command encoders.

63388ed

Tracing.

c6a6706

Don't parallelize.

57d84be

Fix shadow ordering.

f5c54e0

atlv24 reviewed Dec 16, 2025

View reviewed changes

ci

8c01b32

atlv24 and others added 6 commits December 16, 2025 11:20

examples

ff8f43f

example imports

6342c31

fix

b83663b

fix guides

790a86d

tweaks

1958963

Merge pull request #4 from atlv24/ad/render-graph-systems

1a7a9f4

ci

Uh oh!

Replace RenderGraph with systems #22144

Are you sure you want to change the base?

Replace RenderGraph with systems #22144

Conversation

tychedelia commented Dec 15, 2025

render-graph-as-systems

Motivation

Implementation

CurrentView / ViewQuery

RenderContext

TODO:

Uh oh!

github-actions bot commented Dec 15, 2025

Uh oh!

github-actions bot commented Dec 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tychedelia Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

IceSentry Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

atlv24 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Replace `RenderGraph` with systems #22144

Replace `RenderGraph` with systems #22144

`CurrentView` / `ViewQuery`

`RenderContext`

tychedelia Dec 16, 2025 •

edited

Loading

IceSentry Dec 16, 2025 •

edited

Loading