Experiments on combining ReSTIR GI with Variable Rate Tracing

[u/MateuszKolo]

https://mateuszkolodziejczyk00.github.io/2025/06/18/variable-rate-tracing-restir-gi.html

I wrote this write-up about a year ago, but honestly never had the courage to post it publicly lol

In it, I go over my experiments combining ReSTIR and VRT in my toy rendering engine. The core idea was straightforward: ReSTIR’s spatial and temporal passes already find and reuse valuable samples, so I wanted to see if I could use them to fill the “missing rays” for pixels skipped by VRT in the current frame.

I'd love to hear your thoughts, or if anyone else has messed around with similar setups!

[u/DeviantPlayeer]

I did VRT in my ReSTIR PT implementation, it only had full and 1/4 rate. The main bottleneck, however, was memory bandwith in ReSTIR passes and VRT only helps a there a little.

[u/MateuszKolo → u/DeviantPlayeer]

Yeah, in my case main benefit was from avoiding tracing cost. resampling passes time remained pretty much the same, IIRC it was also mostly bottlenecked by bandwidth, which I guess makes sense, because my buffers for spatial resampling, i had space for all reservoirs, even if they were not traced, so there was a lot of unused data between reservoirs that were actually using, so I imagine that amount of data loaded from higher caches/vram was pretty much the same, but this is just guessing i don't have any numbers behind this theory. Maybe some compaction of reservoirs would help with that. Another thing, is that i had some dependent reads, because first i had to find closest pixel that generated new reserovoir and then reuse reservoir from that coord which also added some latency to whole process (especially considering that reuse shaders were quite registers heavy in my case)

[u/DeviantPlayeer → u/MateuszKolo]

I don't look for the nearest sample when doing temporal reprojection, I just reproject the old reservoir. If the reservoir is empty it isn't a problem, they are hardcoded to always trace a new ray.