[HDRP] Fix Invalid Texture Handle Issue in Shadow Atlas

[gmitrano-unity]

Purpose of this PR

This change fixes an issue where the shadow atlas could end up with an
invalid texture handle after the render pipeline asset is modified and
reloaded.

The previous code was invalidating the output texture handle in some
particular cases, but a new handle was recently added to the atlas
code without updating the invalidation logic. This change simply adds
the new handle to the existing invalidation logic.

The new handle was added as part of #6030 and merged into master as:
c83cb31

This fix may need to be backported to other branches.

---

Testing status

Tested locally on Spaceship by dragging the "Max Local Fog on Screen" slider on the pipeline asset around. Before this change, errors would be written to the console. After the change, there's no errors.

---

Comments to reviewers

Some feedback on the correctness of this change would be appreciated since I'm not 100% sure that fixing this issue is as simple as adding the new handle to the invalidation logic. I ran into this issue when working on another change so fixing this is technically a prerequisite for me.

Items to address

• Backporting
• Changelog

[github-actions]

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://unity-ci.cds.internal.unity3d.com/project/902/
Search for your PR branch using the search bar at the top, 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
/jobDefinition/.yamato%2Fall-hdrp.yml%23PR_HDRP_trunk
With changes to HDRP packages, you should also run
/jobDefinition/.yamato%2Fall-lightmapping.yml%23PR_Lightmapping_trunk

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.

[gmitrano-unity]

@FrancescoC-unity Could you review this please? The new handle was added during one of your recent changes so you might be able to tell if this fix is appropriate or not?

[JulienIgnace-Unity]

Is this supposed to fix the issue that happens randomly after a while in the editor?
If so then the proper fix is in flight: #6329

[gmitrano-unity]

Is this supposed to fix the issue that happens randomly after a while in the editor? If so then the proper fix is in flight: #6329

Took a look at the bug related to that PR and yes this seems to be the same or a similar issue. In my case though, I've been able to reproduce the problem by scrubbing the "Max Local Fog on Screen" slider quickly while Spaceship is running rather than leaving the editor open for a long time:

I tested out the branch (hd/fix-rg-error) and my issue no longer reproduces with that so it looks like my fix isn't necessary/correct. :) I can discard this PR and wait for #6329 to be merged instead as long as we understand why m_ShadowMapOutput doesn't need to be invalidated like m_Output in the shadow atlas code?

[JulienIgnace-Unity]

Given the current logic m_ShadowMapOutput should always be updated every frame before being used so it should never become invalid and therefore should not need to be reset.
The issue here is that the CreateIfInvalid thought the handle valid even though it wasn't. The reason is that the system that checks if a handle comes from a previous frame (and thus is invalid) reached a corner case which I fixed in my PR.
Without the fix to this system, the same pattern elsewhere could have resulted in the same issue.
So I think it's safe to close this PR as it was fixing the cause rather than the consequence in this particular case.

[gmitrano-unity]

Given the current logic m_ShadowMapOutput should always be updated every frame before being used so it should never become invalid and therefore should not need to be reset. The issue here is that the CreateIfInvalid thought the handle valid even though it wasn't. The reason is that the system that checks if a handle comes from a previous frame (and thus is invalid) reached a corner case which I fixed in my PR. Without the fix to this system, the same pattern elsewhere could have resulted in the same issue. So I think it's safe to close this PR as it was fixing the cause rather than the consequence in this particular case.

Oh ok, that makes perfect sense! Thanks for the explanation. :) I'll close this PR.