- The GRHIThreadId field was zeroed by StopRenderingThread(). but never set again when starting up.
- Fix only necessary for UE 5.4. This is already fixed in UE5.5/Main by the DevPR refactor.
#jira UE-197775
#rb zach.bethel
[CL 31901382 by Luke Thatcher in 5.4 branch]
In particular, it would happen when capturing GPU profiles on some platforms as it leads to the sync between the game and render threads to be very long.
Resolved by creating a custom wait task manually which ensures that we only have one instance.
#rb danny.couture, graham.wihlidal
#rnx
[CL 30318412 by wojciech krywult in ue5-main branch]
- Reimplemented render command fence bundler flushing to keep the bundler active during a GC.
- Added insights regions to track render command pipe recording and fence bundler activity when the render commands channel is active.
- Cleaned up render command pipe recording so that it works properly with the fence bundler.
#rb chrisopher.waters
[FYI] Dominic.Couture
[CL 28206922 by zach bethel in ue5-main branch]
- Fixes issue where pipes are stopped, then a sync occurs and pipes are erroneously started up again.
- Removed start / stop from end of frame updates.
#jira UE-194553
[CL 27767719 by zach bethel in ue5-main branch]
- Added flags to render command pipe definitions to allow for disabling in code.
- Release the TFunction after each command to match behavior of the render command tasks.
[CL 27412478 by zach bethel in ue5-main branch]
Render Command Pipes dedicated asynchronous task pipes for render commands. Users can easily define new pipes and enqueue commands into them. Pipes can be synchronized using a scope to run serial render commands on the render thread, but initially pipes cannot be synchronized individually with each other. Render command overhead is reduced by recording command lambdas into MPSC queues which are serviced by the task graph; both for pipes and for the render thread. This reduces the task overhead as commands are no longer 1-to-1 with tasks.
Pipe behavior is controlled with new CVars. `r.RenderCommandPipeMode` controls overall behavior:
0 - Legacy render thread tasks,
1 - Render thread MPSC queue,
2 - Render thread and async pipe MPSC queues.
To define a Render Command Pipe, use DEFINE_RENDER_COMMAND_PIPE(MyPipe), or DECLARE_RENDER_COMMAND_PIPE(MyPipe, MODULE_API) to declare an extern reference.
Enqueue a command into the pipe like so:
ENQUEUE_RENDER_COMMAND(MyCommand)(UE::RenderCommandPipe::MyPipe, [] (FRHICommandList&) {}).
Omitting a pipe will fallback to the 'general' pipe which is the render thread.
Eventually pipes need to be synced back to the general pipe for scene renders and other GPU work. On the game thread timeline, use UE::RenderCommandPipe::FSyncScope to synchronize the pipes. This waits for pipes and disables recording of new pipe commands until the scope completes, at which point pipe recording is restarted. This creates a 'sync point', so render commands issued prior to a sync scope will be waited on at the start of the scope, and render commands issued after the scope ends will not be able to start until the render thread finishes processing prior commands.
#rb christopher.waters, luke.thatcher
[CL 27074956 by zach bethel in ue5-main branch]
