Page MenuHome

Cycles: code refactor to bake using regular render session and tiles
ClosedPublic

Authored by Brecht Van Lommel (brecht) on Mar 17 2018, 5:12 PM.

Details

Summary

There should be no user visible change from this, except that tile size
now affects performance. The goal here is to simplify bake denoising in
D3099, letting it reuse more denoising tiles and pass code.

A lot of code is now shared with regular rendering, with the two main
differences being that we read some render result passes from the bake API
when starting to render a tile, and call the bake kernel instead of the
path trace kernel.

With this kind of design where Cycles asks for tiles from the bake API,
it should eventually be easier to reduce memory usage, show tiles as
they are baked, or bake multiple passes at once, though there's still
quite some work needed for that.

Diff Detail

Repository
rB Blender

Event Timeline

Rebased to current master, still works fine as far as I can tell.

I think it makes sense to move forward with this patch - I don't think I'll have the time to look into cross-seam baking denoising anytime soon, and that way we could at least improve the code and get regular baking denoising.

Also, the register pressure optimizations seem to be independent from the other changes, maybe we should just commit those separately?

  • Rebase patch to latest master
  • Fix merge issues caused by formatting commits
  • Adapt the fix for T60973 to the new baking implementation
  • Fix two bugs in render_result_from_bake: In the case where the object_id doesn't match, the code was doing a real cast instead of a bitwise cast to -1 and didn't increment to the next pixel

Rebase to latest master.

I had to acquire the tile lock in the code that reads tiles from Blender since I sometimes got use-after-free in RE_engine_end_result.

This seems to work fine with CPU and CUDA baking. I found no regressions. Two Cycles render tests will need to be updated with new references images, due to different noise patterns.

I think this is fine to commit (I can't accept the patch through phabricator since I'm the author).

Just checked to make sure, both tests converge to the same result at 8192spp.

I can commit the patch but I don't think I have write access to the SVN, so you might have to update the tests.

One more thing to note is that this patch significantly improves CPU utilization - on my local system, baking the split_faces test at 1024spp takes 18.5sec (at 60% CPU usage) with master and 11.5sec (at 100% CPU usage) with the patch applied.

This revision is now accepted and ready to land.May 15 2020, 8:16 PM

If you have write access to the Git repository you automatically have access to the SVN as well.

SVN username and password are the same as used to login to developer.blender.org.