This allows to define a new dynamic scaling in the renderer with low amount of boiler plate:
DynamicRenderScaling::FHeuristicSettings GetDynamicTranslucencyResolutionSettings()
{
RenderingDynamicScaling::FHeuristicSettings BucketSetting;
BucketSetting.Model = RenderingDynamicScaling::EHeuristicModel::Quadratic;
BucketSetting.bModelScalesWithPrimaryScreenPercentage = true;
BucketSetting.MinResolutionFraction = ...
...
return BucketSetting;
}
DynamicRenderScaling::FBudget GDynamicTranslucencyResolution(TEXT("DynamicTranslucencyResolution"), &GetDynamicTranslucencyResolutionSettings);
And then simply define a scope to measure the GPU timing as such:
{
DynamicRenderScaling::FRDGScope DynamicTranslucencyResolutionScope(GraphBuilder, GDynamicTranslucencyResolution);
// add passes to GraphBuilder
}
#rb zach.bethel
#jira UE-152561
#preflight 628f1219bb14235aa38c904c
[CL 20376428 by Guillaume Abadie in ue5-main branch]
Support velocity for WPO on static objects.
Support Optimized WPO on all actors, not just nanite.
Optimized WPO now also affects WPO velocity.
Moved logic for forcing velocity output to proxy init and removed from view.
Update all proxies when force velocity output CVar changes.
Used nicer mechanism to update all proxies when CVar changes for r.Velocity.EnableVertexDeformation.
Disable bEvaluateWorldPositionOffset UI unless Optimized WPO is enabled.
#preflight 6284e958925bbe69dfd26af2
#fyi graham.wihlidal
[CL 20268399 by Jeremy Moore in ue5-main branch]
* Fence wait for cross GPU resource transfers can now be deferred. Moved the wait for view family render target transfers to the end of all view family rendering. Saves a few ms GPU in stalls in the Valley project. The fence wait is marked with a different GPU stat scope, so it can be differentiated from the transfer workload.
* Ray tracing scene update now runs once, for the first view family only. Saves around 1.2 ms GPU when three views are present.
* Added logic to sort the largest view families to run first, which tend to be the inner frustum, and are usually the bottleneck for the entire frame. This improves scheduling, saving around 1.0 ms GPU.
* Avoid CPU stalls where Render Thread waits on RHI Thread, by only running "SetFlushResourcesRHI()" on the first view family. Can save multiple ms when CPU bound.
This is part of ongoing multi-view-family scene render refactor work, where these improvements were made possible by the refactor.
#jira none
#rnx
#rb zach.bethel jason.nadro
#preflight 6272cef4ec1566a7062f20c4
[CL 20059593 by jason hoerner in ue5-main branch]
- Updated places accessing TLAS SRV to use ERayTracingSceneLayer::Base
#rb yuriy.odonnell
#preflight 62728a70ec1566a70616ac9a
[CL 20041705 by tiago costa in ue5-main branch]
* Existing calls to CreateSceneTextureShaderParameters and similar functions use "GetSceneTexturesChecked", which allows for the possibility that they are reached in a code path where scene textures haven't been initialized, and nullptr is returned instead of asserting. The shader parameter setup functions then fill in dummy defaults for that case. The goal was to precisely match the original behavior, which queried the RDG blackboard, and gracefully handled null if scene textures weren't there. This definitely appears to occur in FNiagaraGpuComputeDispatch::ProcessPendingTicksFlush, which can be called with a dummy scene with no scene textures. In the future, I may change this so dummy defaults are filled in for FSceneTextures at construction time, so the structure is never in an uninitialized state, but I would like to set up a test case for the Niagara code path before doing that, and the checks aren't harmful in the meantime.
* I marked as deprecated global functions which query values from FSceneTexturesConfig, but they'll still work with the caveat that if you use multi-view-family rendering, the results will be indeterminate (whatever view family rendered last). There was only one case outside the scene renderer that accessed the globals (depth clear value), which I removed, noting that there is nowhere in the code where we modify the depth clear value from its global default. I would like to permanently deprecate or remove these at some point. Display Cluster is the only code that's currently using the multi-view-family code path, and as a new (still incomplete) feature, third party code can't be using it, and won't be affected.
#jira NONE
#rb chris.kulla zach.bethel mihnea.balta
#preflight 6261aca76119a1a496bd2644
[CL 19873983 by jason hoerner in ue5-main branch]
As a part of the LWC work, this change primarily focues on updating FGameTime and UWorld to use doubles for accumulated time. Note that time deltas will remain as floats.
Additionally:
* A few time-related BP functions were updated to use doubles where appropriate. as well as the FRenderThreadUpdateContext struct for the Slate renderer.
* Some compilation errors were also fixed due to the change.
* Minor changes of float literals to drop the 'f' suffix.
#rb andrew.davidson
#jira UE-148463
#preflight 62603748e30cb43e8cbf2aa7
[CL 19866207 by dave jones2 in ue5-main branch]
InstancedStereoWidth is already a view property, but is currently simply set to the widest pair.
This CL properly computes InstancedStereoWidth for each pair individually.
#rb arciel.rekman
#jira UE-149773
#preflight 62608172dd47b4ad218b7584
#preflight 626094ba886befa9a5d09c6e
[CL 19841467 by Jules Blok in ue5-main branch]
* Added "BeginRenderingViewFamilies" render interface call that accepts multiple view families. Original "BeginRenderingViewFamily" falls through to this.
* FSceneRenderer modified to include an array of view families, plus an active view family and the Views for that family.
* Swap ViewFamily to ActiveViewFamily.
* Swap Views array from TArray<FViewInfo> to TArrayView<FViewInfo>, including where the Views array is passed to functions.
* FSceneRenderer iterates over the view families, rendering each one at a time, as separate render graph executions.
* Some frame setup and cleanup logic outside the render graph runs once.
* Moved stateful FSceneRenderer members to FViewFamilyInfo, to preserve existing one-at-a-time view family rendering behavior.
* Display Cluster (Virtual Production) uses new API.
Next step will push everything into one render graph, which requires handling per-family external resources and cleaning up singletons (like FSceneTextures and FSceneTexturesConfig). Once that's done, we'll be in a position to further interleave rendering, properly handle once per frame work, and solve artifacts in various systems.
#jira none
#rnx
#rb zach.bethel
#preflight 625df821b21bb49791d377c9
[CL 19813996 by jason hoerner in ue5-main branch]
