Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improving the denoiser for RTGI (case 1346383) #5078

Merged
merged 9 commits into from Jul 26, 2021

Conversation

anisunity
Copy link
Contributor

@anisunity anisunity commented Jul 6, 2021

This PR improves the upscaling process as well as the denoising of RTGI (and RTAO), it is one of the two PRs to solve this bug
https://fogbugz.unity3d.com/f/cases/1346383/

Removes the upscaling parameter for RTGI (forced to 3 for half res, 4 for full res).
Reduces signficantly the cost of the upscaling pass.
Resolves bleeding (and ghosting artifacts) that come from the upscale.
Change the default parameters for quality settings for RTGI.
Fix edges issues with the half resolution denoiser.
Deduce automatically the world space denoiser radius for surfaces (instead of fixed for the whole scene)

https://youtu.be/J5UJRT5fF6E
https://youtu.be/GZwg9ditAzk

Testing status
DXR Tests are green after updating the screenshots.

@github-actions
Copy link

github-actions bot commented Jul 6, 2021

Hi! This comment will help you figure out which jobs to run before merging your PR. The suggestions are dynamic based on what files you have changed.
Link to Yamato: https://yamato.cds.internal.unity3d.com/jobs/902-Graphics
Search for your PR branch using the sidebar on the left, then add the following segment(s) to the end of the URL (you may need multiple tabs depending on how many packages you change)

HDRP
/.yamato%252Fall-hdrp.yml%2523PR_HDRP_2021.2

Depending on the scope of your PR, you may need to run more jobs than what has been suggested. Please speak to your lead or a Graphics SDET (#devs-graphics-automation) if you are unsure.

@anisunity
Copy link
Contributor Author

@anisunity anisunity changed the title [Draft] Improving the denoiser for RTGI Improving the denoiser for RTGI (case 1346383) Jul 7, 2021
@anisunity anisunity marked this pull request as ready for review July 7, 2021 18:27
@anisunity
Copy link
Contributor Author

After running the test a thousand times, all green

@remi-chapelain remi-chapelain requested a review from a team July 12, 2021 12:02
Copy link
Contributor

@remi-chapelain remi-chapelain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I quickly tested performance on the ray tracing apartment scene in quality mode and in performance medium mode and -surprisingly, I found performance a bit worse than the current master. Needs to be discussed later.

  • I honestly don't know how we can solve this but since values are serialized in the HDRP asset, the only way to get the new values from the quality settings is to create a new HDRP Asset, which is a terrible pain for upgrading. It should at least be mentionned in the upgrade guide or something.

Also, only managed to repro those issues on those specifics projects, but they didn't repro on master so they must be linked with the improvement in a way.

Hit me up when you are getting back on this to either pair debug it or for me to send you repros.

@anisunity
Copy link
Contributor Author

@remi-chapelain The counters for the perf are not working properly and cannot be trusted. I'll check the perf comparison using a GPU capture to make sure that there is no major regression.

Let's sync for the issues that you found, so that you give me a repro.

RTGIDenoiserRadius[(int)ScalableSettingLevelParameter.Level.Low] = 0.75f;
RTGIDenoiserRadius[(int)ScalableSettingLevelParameter.Level.Medium] = 0.5f;
RTGIDenoiserRadius[(int)ScalableSettingLevelParameter.Level.High] = 0.25f;
RTGIDenoiserRadius[(int)ScalableSettingLevelParameter.Level.Low] = 1.0f;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given it is all the same value, does it make sense to keep as a scalability setting? (is it beneficial if user change this defaults or should they always be the same value?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Users can chose to lower it for lower perf modes it as it can affect performance a lot

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it has an high impact, shouldn't this have different values by default too though? Out of the box the scalability does nothing here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be disccused

@anisunity
Copy link
Contributor Author

image
The perf is equal at worst (full res, but higher visual quality), much better at best (half res)

{
// Compute the tap coordinate in the 8x8 grid
uint2 tapAddress = (uint2)((int2)(groupThreadId) + offset);
return clamp((uint)(tapAddress.x) + tapAddress.y * GATHER_REGION_SIZE, 0, GATHER_REGION_SIZE_2 - 1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for cast here, tapAddress.x is already a uint

uint2 cornerGroupThread = corner - groupId * DIFFUSE_DENOISER_TILE_SIZE;

// Grab the indices of the sub-region to use
int ldsIdx0 = OffsetToLDSAdress(cornerGroupThread, int2(0, 0));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I see you don't load a safety border so it is clamp at group border which I guess can give problems if we have signficiant depth discontinuities happening at the edge of the group? Might be ok, but leaving comment here to see if needs further discussion or not.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure to get what you are describing, let's chat


// If the normals of both pixels are too different, we cannot use it
if(dot(neighborData.normalWS, normalWS) < NORMAL_REJECTION_THRESHOLD)
weight *= 0.1f;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to soft reject this? Lerping towards 0.1 (or close to) multiplier as we approach the threshold?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we can have a transition region. But the idea here is to not use these unless there are not better samples

@anisunity anisunity force-pushed the HDRP/rtgi-denoise-improv branch 3 times, most recently from 597a548 to 1062c75 Compare July 23, 2021 21:15
@anisunity
Copy link
Contributor Author

Everything is green

@anisunity
Copy link
Contributor Author

Conflits, need to merge

@anisunity
Copy link
Contributor Author

Everything is green @remi-chapelain depends on your review

Copy link
Contributor

@remi-chapelain remi-chapelain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't repro any of the issues I reported above. ✔️

For the rest, I could only see improvements, couldn't find any more regression on the scenes I tested. ✔️

Also tested animation because we don't have coverage for moving objects. ✔️

Pushed the changes regarding the upscale filter to make the documentation match.

@anisunity anisunity merged commit 09e1584 into master Jul 26, 2021
@anisunity anisunity deleted the HDRP/rtgi-denoise-improv branch July 26, 2021 12:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants