add (optional) SER to mega_path integrator#53
Conversation
- modest performance gains (~5%)
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the mega_path integrator by adding an optional Shader Execution Reordering (SER) feature. This optimization aims to improve performance by reordering shader execution based on coherence hints derived from scene properties and path characteristics. The changes include adding a new boolean property to control the use of SER and implementing the coherence hint logic within the integrator. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces an optional Shader Execution Reordering (SER) optimization to the megakernel path tracer, aiming for performance improvements through better thread coherence. The implementation correctly structures the coherence hint. However, I've identified a critical bug involving the use of an uninitialized variable which would prevent compilation. Additionally, there are opportunities to improve maintainability by making hardcoded values configurable and enhancing code clarity. Addressing these points will ensure the new feature is robust and maintainable.
| coherence_hint |= (UInt(has_surface) << (surface_tag_bits + 1)); | ||
| coherence_hint |= (surface_tag << 1u); | ||
|
|
||
| Float rr_survive_prob = max(beta.max() * eta_scale, .05f) * 0.8f; |
There was a problem hiding this comment.
The variable eta_scale is used here to predict path termination, but it is not in scope. It is declared later in the loop at line 167, which will cause a compilation error.
To fix this, eta_scale should be declared before the loop so its state can be managed across iterations. It should hold the eta_scale from the previous bounce when used for the SER prediction.
I recommend the following changes:
- Add
auto eta_scale = def(1.f);before the$forloop (e.g., after line 65). - Remove the declaration
auto eta_scale = def(1.f);from line 167. - Add a
$defaultcase to the$switchat line 194 to reseteta_scaleto1.ffor non-transmissive bounces, like so:
$switch(surface_sample.event) {
$case(Surface::event_enter) { eta_scale = sqr(eta); };
$case(Surface::event_exit) { eta_scale = sqr(1.f / eta); };
$default { eta_scale = 1.f; };
};| // actually used number of tag bits is available at kernel compile time | ||
| size_t surface_tag_count = pipeline().surfaces().size(); | ||
| LUISA_ASSERT(surface_tag_count > 0u, "SER requires at least one surface."); | ||
| size_t surface_tag_bits = std::bit_width(next_pow2(surface_tag_count)) - 1u; |
There was a problem hiding this comment.
The calculation for surface_tag_bits is correct, but can be expressed more simply. The number of bits required to store N values (from 0 to N-1) is ceil(log2(N)), which can be computed with std::bit_width(N - 1) for N > 0 since C++20. Given the assertion on the previous line, this simplification is safe to apply and improves readability.
size_t surface_tag_bits = std::bit_width(surface_tag_count - 1);| Float rr_survive_prob = max(beta.max() * eta_scale, .05f) * 0.8f; | ||
| Bool terminate = | ||
| depth == node<MegakernelPathTracing>()->max_depth() - 1u | | ||
| (depth + 1u >= node<MegakernelPathTracing>()->rr_depth() & rr_survive_prob < 0.3f); |
There was a problem hiding this comment.
The values 0.8f and 0.3f used for guessing the Russian Roulette survival probability are hardcoded. As noted in the pull request description, this heuristic could be improved. To improve maintainability and allow for easier tuning, these magic numbers should be replaced with named constants, or ideally, configurable properties on the MegakernelPathTracing node.
Float rr_survive_prob = max(beta.max() * eta_scale, .05f) * 0.8f; // TODO: use a configurable parameter instead of 0.8f
Bool terminate =
depth == node<MegakernelPathTracing>()->max_depth() - 1u |
(depth + 1u >= node<MegakernelPathTracing>()->rr_depth() & rr_survive_prob < 0.3f); // TODO: use a configurable parameter instead of 0.3f
Uh oh!
There was an error while loading. Please reload this page.