This change includes significant refactor work performed in //UE5/Dev-ParallelRendering. A brief summary of the work is as follows:
Refactored RHI command lists
- Removal of the "immediate" async compute command list
- Introduced an "active pipe" on each command list, allowing RHICmdLists to record work for either graphics or async compute. Pipes can be selected using the SwitchPipeline() function, or the FRHICommandListScopedPipeline helper.
- New explicit command list submission RHI API (RHIFinalizeContext, RHISubmitCommandLists). The IRHICommandContextContainer type has been removed.
- Explicit GPU submission is automatically appended to the immediate command list when it is dispatched to the RHI thread.
Platform RHI implementations
- The new submission API has been implemented across all platforms. Some platforms required a significant refactor.
#rb Mihnea.Balta,Kenzo.Terelst
#jira UE-139550
#preflight 6332e3641003050806d802ef
[CL 22239063 by luke thatcher in ue5-main branch]
- Assume support during the cook, do the actual check in runtime and exit if not supported.
- This slightly increases the minspec for PC projects that ship ISR to D3D 11.3 (2014-2015 level hardware).
#rb Jules.Blok, Robert.Srinivasiah
#review @Jules.Blok, @Robert.Srinivasiah
#jira UE-162244
#preflight 632b4d6cb4515b7e2272620d
[CL 22207954 by Arciel Rekman in ue5-main branch]
- Also, only issue the warning if we waited at least 1ms in that call.
#rb Kenzo ter Elst, Jason Nadro
#jira UE-163502
#review @Kenzo.Terelst, @Jason.Nadro
#preflight 632b0f15b40000c8f0c4705a
[CL 22116865 by Arciel Rekman in ue5-main branch]
- Fix for some DeviceProfiles not reading in their parent TextureLODGroups
- Remove the call to UDeviceProfileManager::Get() that was being called too early, before object subsystem is ready, so it was unable to load all the other platform DeviceProfiles
[REVIEW] [at]elizabeth.bunner, [at]josh.adams
#tests preflight 631258e02b7fe03eb6d9d725
[CL 21774577 by mickael gilabert in ue5-main branch]
[FYI] Serge.Bernier
Original CL Desc
-----------------------------------------------------------------
Initialize device profile manager earlier in the pre init phase to properly set the FCoreDelegates::GatherDeviceProfileCVars.
#rb josh.adam
[CL 21707544 by serge bernier in ue5-main branch]
Check first max 10 arguments instead of just the first.
#rb Jerome.Delattre
#preflight 630e0f50e1124837754e3bde,630e0f57e352708d4416fb1e
[CL 21706201 by chris constantinescu in ue5-main branch]
* LaunchEngineLoop - Added activity scopes and moved console to show earlier
#rb Devin.Doucette
#preflight 6303fac6a45b007ea255fdea
[CL 21511745 by henrik karlsson in ue5-main branch]
#rb Per.Larsson
#jira UE-161296
#rnx
#preflight 62fe3ce73d3fb466b229bcc0
- There are some usecases that require the VA system to initialize the first time it is accessed (usually the first time we attempt to pull a virtualized payload) rather than be initialized in the program start up. This change provides three different methods to achieve this:
-- Setting the define 'UE_VIRTUALIZATION_SYSTEM_LAZY_INIT' to 1 in a programs .target.cs
-- Setting [Core.ContentVirtualization]LazyInit=true in the Engine ini file
-- Running with the commandline option -VA-LazyInit
- If we detect that the source control backend is being initialized on a background thread we do not try to run the FConnect operation. The backend will still work but this does reduce the potential error checking on initialization. This is done because the FConnect operation currently only works on the main thread and to change this would be a bigger work item than we can schedule at the moment.
- UE::Virtualization::Initialize functions now take a EInitializationFlags enum as a parameter. This enum allows the call to ignore all lazy init settings and force the initialization immediately. This is useful for programs like the Virtualization standalone tool which just needs to start the system when needed.
-- The call to ::Initialize in LaunchEngineLoop passes in None and does not ignore lazy initialization.
-- Calls to ::Initialize in the UnrealVirtualizationTool however all use EInitializationFlags::ForceInitialize and ignore lazy initialization settings.
- Fixed an odd bug in UE::Virtualization::Initialize where the error path (if the config file cannot be found) was using a different start up code path.
- Add asserts when assigning to GVirtualizationSystem to make sure that it is null. This is not 100% safe but should catch some potential threading issues, if any.
- Add an assert after lazy initialization (IVirtualizationSystem::Get) to make sure that GVirtualizationSystem was assigned a valid object.
- Improve how we check for legacy values in [Core.ContentVirtualization]. We now support multiple allowed values.
- Added a way to poll if a VA system has been initialize yet or not, this allows us to avoid initializing a VA system if one has not yet been created and we try to:
-- Dump VA profiling stats after cooking
-- Send VA stats to studio analytics
- Note that currently using lazy init loading will probably cause the VA statistics panel not to work, this will be fixed in future work where we will allow the panel to register for a callback when the system is initialized.
[CL 21467510 by paul chipchase in ue5-main branch]
Fixes warnings about calling LoadObject in PostLoad of anim sequences
#jira UE-145778
#rb Jurre.deBaare
#preflight 62fdf8540601ad050473206d
[CL 21439526 by Thomas Sarkanen in ue5-main branch]
The implementation extends the existing FThreadIdleStats to track critical path vs non-critical path waits for a thread.
The cvar r.RenderThreadTimeIncludesDependentWaits forces the main renderthread stat to use the new behavior, but this is disabled by default for historical tracking reasons.
#rb Nuno Leiria
#ROBOMERGE-AUTHOR: ben.woodhouse
#ROBOMERGE-SOURCE: CL 21386702 via CL 21387159 via CL 21387356 via CL 21391039 via CL 21391830
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v975-21357124)
[CL 21394348 by ben woodhouse in ue5-main branch]
#ROBOMERGE-AUTHOR: ben.woodhouse
#ROBOMERGE-SOURCE: CL 21359298 via CL 21359569 via CL 21359589 via CL 21359605
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v972-20964824)
[CL 21362808 by ben woodhouse in ue5-main branch]
#ROBOMERGE-AUTHOR: ben.woodhouse
#ROBOMERGE-SOURCE: CL 21357137 via CL 21357285 via CL 21357293 via CL 21357304
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v972-20964824)
[CL 21358768 by ben woodhouse in ue5-main branch]
#rb serge.bernier
#ROBOMERGE-AUTHOR: ben.woodhouse
#ROBOMERGE-SOURCE: CL 21355012 via CL 21355934 via CL 21355993 via CL 21356002
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v972-20964824)
[CL 21358177 by ben woodhouse in ue5-main branch]
