[10.x.x HDRP] Fix issue with raytracing resources not properly initialize #4268
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sebastienlagarde
requested review from
RSlysz,
anisunity,
jenniferd-unity and
remi-chapelain
|
It appears that you made a non-draft PR! |
sebastienlagarde
changed the title
RSlysz
approved these changes
Apr 22, 2021
| if (HDRenderPipeline.defaultAsset.renderPipelineRayTracingResources == null) | ||
| return; | ||
|
|
||
| foreach (var fieldInfo in HDRenderPipeline.defaultAsset.renderPipelineRayTracingResources.GetType().GetFields(BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance | BindingFlags.Static)) |
There was a problem hiding this comment.
You should not need BindingFlags.Static. There will never have static field in resources as they are not serialized.
Comment on lines
+615
to
+618
| bool requiresRayTracingResources = false; | ||
| // Make sure to include ray-tracing resources if at least one of the defaultAsset or quality levels needs it | ||
| if (defaultAsset.currentPlatformRenderPipelineSettings.supportRayTracing) | ||
| requiresRayTracingResources = true; |
There was a problem hiding this comment.
Can be simplified as
bool requiresRayTracingResources = defaultAsset.currentPlatformRenderPipelineSettings.supportRayTracing;
Does former GatherRayTracingSupport also check if hardware is compatible? Should we check it here?
There was a problem hiding this comment.
indeed, will make the change on master. We must not check hardware support as you can build with a GPU not supporting it
|
After quick check with Remi we will merge the PR so it can be tested in 10.5.0 |
|
already tested on the branch with 2020.3.6f1.
Will make another quick pass on new 10.5.0 package version tomorow. |
sebastienlagarde
added a commit
that referenced
this pull request
Apr 30, 2021
…lize (#4268) * draft * Fix build DXR * Match behavior with the one in master
sebastienlagarde
added a commit
that referenced
this pull request
May 1, 2021
* [10.x.x HDRP] Fix issue with raytracing resources not properly initialize (#4268) * draft * Fix build DXR * Match behavior with the one in master * Updated ray tracing settings and added it to the table of contents (#4279) * Updated ray tracing settings and added it to the toc * Removed hyphens from rtss toc entry * Fix shader warning when using Lanczos upsampling (#4280) * Added DOTS_INSTANCING_ON variants to the "HDRP/Decal" shader #4284 * [HDRP] Fp16_PPAlpha Panini projection, Motion Blur test and moved other Fp16Alpha scenes to one #4290 * [HDRP] Fix undo of some properties on light editor #4293 * Opt-out of builtin auto baking of ambient/reflection probe. #4324 * Revert "Opt-out of builtin auto baking of ambient/reflection probe. #4324" This reverts commit 719e835. * Hd/redo fix inputregistering domainreload (#4358) * Update InputRegistering.cs * Remove asset modification if InputSystem package is in use * Prevent missuse of InputRegistering while InputSystem package is in use * cleaning * more cleaning * Update code to use Next instead of GetArrayElementAtIndex * Fix strange out of range error Co-authored-by: Lewis Jordan <lewis.jordan@hotmail.co.uk> Co-authored-by: Pavlos Mavridis <pavlos.mavridis@unity3d.com> Co-authored-by: Andrew Saraev <67020478+AndrewSaraevUnity@users.noreply.github.com> Co-authored-by: TomasKiniulis <50582134+TomasKiniulis@users.noreply.github.com> Co-authored-by: Adrien de Tocqueville <adrien.tocqueville@unity3d.com> Co-authored-by: JulienIgnace-Unity <julien@unity3d.com> Co-authored-by: Remi Slysz <40034005+RSlysz@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose of this PR
This PR correctly fix the issue attempted to be fixed in this PR:
#3894
and this fogbugzz:
https://fogbugz.unity3d.com/f/cases/1320304/
We are changing the behavior.
Previously, the raytracing resources was re-loaded and init only if the option Real-time raytracing was enabled on the current use asset and reset to null otherwise. This is causing issue in case of multiple configuration with mismatch on this property (i.e some true, some false).
The PR #3894 is an attempt to fix this problem but wasn't the correct solution and the issue was remaining.
The correct solution is to always initialize the raytracing resources, as they are located in the Default settings and must be embed in the build if any of the configuration required it. So the users could switch at runtime between raytracing and non raytracing.
This is what this PR is doing. It now always init and reload the raytracing resources like the regular one if any of the quality level of graphicssettings RP have raytracing - this is what is done on master - BUT it use the stripper to remove the unused compute shader from it. However there is not stripper yet for raytrace shader so they can't be removed. Fortunately, on platform which don't support raytrace shader (so all of them except DX12), those shader will not be compile anyway.
The downside is that for platform which support DX12 the raytrace resources will always been embed even if raytracing is not used. As of today the usage of DX12 is related to raytracing as otherwise it is less performant it is not really a problem.
Testing status
I have tested the template on windows with a RTX card. I was able to build a player with and without raytracing and checked in the compute shader compilation list with verbose mode that compute shader used for raytracing were correctly used.
Comments to reviewers
For QA, can you please test this PR on metal and console to see if the player build works correctly? I want to check that a non null raytrace resource have no impact on those platform. Thanks
Note : I don't add a changelog as I am reusing the one in #3894 as it have been backported "Fixed HDRPAsset loosing its reference to the ray tracing resources when clicking on a different quality level that doesn't have ray tracing (case 1320304)."