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]
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]
-Allow the frame sync to be kicked from the render thread when using the gtsync==2 (low input latency mode). On some platforms, the RHI thread will block on present. Putting the RHI as the trigger index will block the GameThread until the present is finished (vblank). In low input latency mode, some consoles uses the RHIOffsetThread to kick of the Gamethread, so we dont want it to block on present.
-Use the present mode to submit frame tokens in low input latency mode. Using GT_wait or GT_early introduce stuttering in the frame time since the gamethread will sync on the present when its double buffered. Even if we increase the frame interval (3 or 4), the WaitFrameEventX will eventually block the gamethread when the second display buffer is in used. Note that we delay the barrier transition(RT->Display) until we really use the backbuffer, so we dont technically need to throttle on the frame token, since we are in pseudo triple buffer mode. Issuing GT_Wait/GT_early mode in double buffer mode will always produce bad frame pacing when we use the FRHIFrameOffsetThread approach.
-Set the frame offset interval to zero to sync the os input pooling with the vblank.
[REVIEW] [at]Eric.McDaniel
#ROBOMERGE-OWNER: serge.bernier
#ROBOMERGE-AUTHOR: serge.bernier
#ROBOMERGE-SOURCE: CL 20749857 via CL 20750200 via CL 20750276 via CL 20750599 via CL 20750604
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v970-20704180)
[CL 20751490 by serge bernier in ue5-main branch]
This change allows users to opt-out of the engines default crash handling. Currently only implemented on Windows where the SEH code forwards the exception to externally registered handlers.
Thanks to Kristj�n Valur J�nsson for PR.
#rb patrick.laflamme
#preflight 62977779101592b80503b809
[CL 20452469 by Johan Berg in ue5-main branch]
### Notes
The check() message and callstack is actually printed in FWindowsErrorOutputDevice::HandleError which is called in the __except block after we RaiseException() inside ReportAssert(). However, RenderingThread's __except doesn't do this, so the contents of GErrorHist are lost to everyone except for CrashReporter. This change adds this necessary logging.
Also, add Windows Launch support for -IgnoreDebugger when choosing __try/__except or not (this precedes initialization of GIgnoreDebugger). This makes debugging easier for this class of issue.
### Testing
Repro steps are in the JIRA. Tested at that change (which has a reliable RenderingThread check() failure), and at #head where no defect exists. Tests fail and pass, respectively, as expected.
#rnx
#rb francis.hurteau
#jira UE-151056
#preflight 627b0b4ac42338be653745e6
[CL 20140980 by geoff evans in ue5-main branch]
The ERenderingThread named thread tag is not removed from ActiveNamedThreads when the render thread crashes, because the stack isn't unwound; this causes the assert in FTaskTagScope to fire when the Exit() method tries to set the tag. This resulted in the assert showing up as the cause of the crash, obscuring logs, crash reports etc.
#rnx
#lockdown Juan.Canada
#jira UE-143055
#rb Andriy.Tylychko, Arne.Schober, danny.couture
#preflight 620e35768b6428e701a2098d
#ROBOMERGE-AUTHOR: mihnea.balta
#ROBOMERGE-SOURCE: CL 19068406 in //UE5/Release-5.0/... via CL 19087994
#ROBOMERGE-BOT: UE5 (Release-Engine-Staging -> Main) (v921-19075845)
[CL 19130574 by mihnea balta in ue5-main branch]
Utilize new delegate to unlock AcquireCriticalSection in PreLoadScreenManager to prevent softlocks whenever FlushRenderingCommands is called during an EarlyStartup PreLoadScreen.
Remove previous hack in PreLoadScreenManager to unlock AcquireCriticalSectoin during fontcache flushes, as this was just to prevent the ensuing FlushRenderingCommands called by the font cache flush from soft locking and is now not needed.
#rb none
#tests Test/Shipping Client
#ROBOMERGE-AUTHOR: thomas.ross
#ROBOMERGE-SOURCE: CL 18671847 via CL 18671850 via CL 18671851 via CL 18671854 via CL 18671857 via CL 18671961 via CL 18671966 via CL 18671967
#ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v901-18665521)
[CL 18671974 by thomas ross in ue5-main branch]
#ROBOMERGE-AUTHOR: arne.schober
#ROBOMERGE-SOURCE: CL 18452561 in //UE5/Release-5.0/... via CL 18452568
#ROBOMERGE-BOT: STARSHIP (Release-Engine-Staging -> Release-Engine-Test) (v898-18417669)
[CL 18452570 by arne schober in ue5-release-engine-test branch]
