Solari v7 by JMS55 · Pull Request #24767 · bevyengine/bevy

JMS55 · 2026-06-26T18:17:46Z

This is a major rewrite of Solari.

The old version did DI, diffuse GI, and specular GI / mirror DI in 3 separate passes. Only diffuse rays were resampled, and no rays were traced for cross-domain MIS weight, leading to bias.

This new version is one unified algorithm that handles diffuse and specular DI and GI all in one reservoir. Resampling takes the full BRDF into account, as well as cross-domain visibility in MIS weights.

Advantages:

Much less biased
Much less prone to GI light-leaks
Improved specular GI quality
Improved DI quality for nearby lights thanks to BRDF sampling for DI
Less memory usage

Disadvantages:

A bit slower due to the extra rays traced

Showcase

Reference

This PR (with DLSS)

Main (with DLSS)

This PR

Main

github-actions · 2026-06-28T03:22:47Z

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.

SparkyPotato · 2026-06-28T12:34:04Z

+        // throughput_past_x1 drops the primary brdf*cos, so multiply it back by primary_brdf_at_x2 to
+        // recover the bounded throughput.
+        let full_throughput = path.throughput_past_x1 * max(path.primary_brdf_at_x2, vec3(0.0001));
+        let rr = saturate(luminance(full_throughput));


Saturation shouldn't be required, RR will fail anyways without

Don't think this is true - because otherwise when you divide throughput by rr, you could divide by a value >1, even though the path will always be kept.

I fixed this just now in pathtracer.wgsl to make it consistent though.

stuartparmenter

The math looks right, but given the complexity and to double check it all I ran a small simulation against using your math to check for bias and it looks good after your fixes. I also wired it in to a number of example scenes (bistro, etc) and it looks better / don't see any visual regressions.

TomClabault · 2026-07-01T16:53:20Z

+    let merge_result = merge_reservoirs(initial_reservoir, surface.world_position, surface.world_normal, surface.material,
+        temporal.reservoir, temporal.world_position, temporal.world_normal, temporal.material, previous_camera_world_position, false, &rng);
+
+    reservoirs_b[pixel_index] = merge_result.merged_reservoir;


Have you tried storing only the pixel index of the sample (either of the temporal neighbor or center pixel, whichever is selected) here instead of the full reservoir? Because when reusing you basically just move samples between pixels so instead of rewriting the whole sample from one pixel to another you could just keep track of the pixel index.

In the spatial pass you would read from reservoirs_b[temporal_output_pixels_indices[pixel_index]]

This can save a bit of bandwith by not writing out full reservoirs in the temporal pass

And you wouldn't have to keep the sample of the merged_reservoir in registers either

TomClabault · 2026-07-01T16:57:23Z

+    reservoirs_b[pixel_index] = initial.reservoir;
+}
+
+@compute @workgroup_size(8, 8, 1)


Pretty much everywhere you dispatch your kernels in (8, 8) 2D blocks
Then you compute your pixel index as let pixel_index = global_id.x + global_id.y * u32(view.main_pass_viewport.z);

Visualizing one 44 workgroup, with warps size 8 (which, for demonstrating my point, is equivalent to your 88 with warps size 32, but 4*4 is easier to draw below), this means that your warps look like this on your framebuffer:

[ w0 w0 w0 w0]
[ w0 w0 w0 w0]
[ w1 w1 w1 w1]
[ w1 w1 w1 w1]

This halves coalescing in the 44 scenario, and divides by 4 coalescing in the real-usecase 88 + warps 32, so that's 2x or 4x more memory transactions to send respectively. Maybe thread swizzling could help here such that 32 consecutive threads read 32 consecutive addresses in the gbuffer, instead of jumping entire rows because of the 2D workgroups

I've read somewhere in another path tracer (iirc it was this one) that dropping textures for the gbuffers and using raw buffers + coalesced accesses was faster

TomClabault · 2026-07-01T17:22:07Z

-    weight_sum: f32,
+    unbiased_contribution_weight: f32,
    radiance: vec3<f32>,
    confidence_weight: f32,


Does the confidence have to be a f32? could be a u8?

TomClabault · 2026-07-01T17:36:40Z

+        // MIS weight against the bounce-0 BRDF-emissive strategy, recomputed from this surface's
+        // brdf and material rather than baked into the unbiased contribution weight at generation. Mirrors the bounce-0
+        // nee_mis_weight in generate_initial_reservoir, which puts the same factor in the target.
+        var nee_mis_weight = 1.0;


Why is there NEE MIS stuff here?

TomClabault · 2026-07-01T17:40:58Z

+        let delta = reservoir.sample_point_world_position - (world_position + world_normal * RAY_T_MIN);
+        let sample_distance = length(delta);
+        let wi = delta / sample_distance;
+        var brdf_radiance = reservoir.radiance * evaluate_brdf(wo, wi, world_normal, material, F_ab);


This is re-evaluating the target function as if the BSDF at vertex x2 didn't change. For specular this is not going to be great as you'll potentially be reconnecting to mirror (or very specular) x2 surfaces.

Maybe storing some sort of "x2_rough_enough" flag in the reservoir at initial candidate generation time could help reject bad reconnections like that

TomClabault · 2026-07-01T18:24:30Z

+}
+
+fn load_spatial_reservoir(pixel_id: vec2<u32>, depth: f32, world_position: vec3<f32>, world_normal: vec3<f32>, rng: ptr<function, u32>) -> NeighborInfo {
+    for (var i = 0u; i < 5u; i++) {


Have you tried the 2026 compatibility guided ReSTIR paper? It should be a fairly simple addition in here and could be good for quality, idk about the perf, have to try

TomClabault · 2026-07-01T18:26:21Z

+
+fn load_spatial_reservoir(pixel_id: vec2<u32>, depth: f32, world_position: vec3<f32>, world_normal: vec3<f32>, rng: ptr<function, u32>) -> NeighborInfo {
+    for (var i = 0u; i < 5u; i++) {
+        let spatial_pixel_id = get_neighbor_pixel_id(pixel_id, SPATIAL_REUSE_RADIUS_PIXELS, rng);


Have you tried using the same rng for all threads of the warp to improve memory coalescing?

If correlations are too bad, using the same rng only for half the warp (so 2 different rng seeds per warp) could help the correlations, or 4 seeds per warp, etc... trading perf for correlations.

Unified ReSTIR

447a9ac

JMS55 added this to the 0.20 milestone Jun 26, 2026

github-project-automation Bot added this to Rendering Jun 26, 2026

github-project-automation Bot moved this to Needs SME Triage in Rendering Jun 26, 2026

JMS55 requested a review from SparkyPotato June 26, 2026 18:36

JMS55 added 4 commits June 27, 2026 21:43

Small bias fix

d7ae1fe

Fmt

f180633

Fmt

e591cee

Allow users to control settings

0852733

JMS55 requested a review from IceSentry June 28, 2026 02:56

Merge branch 'main' into solari7-unified-restir

6b79dc4

SparkyPotato reviewed Jun 28, 2026

View reviewed changes

JMS55 added 8 commits June 28, 2026 11:36

Simplify CAS check

71862cf

Misc rename

ec81568

Consistent russian roulette

44d3073

Cleanup

9a7a808

Cleanup

9d9d550

DI cleanup, also ensure we resample using visibility everywhere

fef0a23

Cleanup

5af041c

Misc

8a7b2f7

JMS55 requested a review from SparkyPotato June 28, 2026 17:39

JMS55 added 2 commits June 28, 2026 14:38

Relax reconnection heuristic on longer paths

fff2966

Merge branch 'main' into solari7-unified-restir

7abad9e

stuartparmenter approved these changes Jun 29, 2026

View reviewed changes

TomClabault reviewed Jul 1, 2026

View reviewed changes

Uh oh!

Uh oh!

Conversation

JMS55 commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Showcase

Uh oh!

github-actions Bot commented Jun 28, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stuartparmenter 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

JMS55 commented Jun 26, 2026 •

edited

Loading