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]
[FYI] zach.bethel
First Original CL Desc
-----------------------------------------------------------------
Moved volumetric volume to RHICmdList.
[CL 27054300 by bob tellez in ue5-main branch]
[FYI] zach.bethel
Original CL Desc
-----------------------------------------------------------------
Render Command Pipe Implementation and API
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 27054009 by bob tellez 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 27042459 by zach bethel in ue5-main branch]
Depending on target platform shading path one or the other SVT will be used
This is required for projects that has a significantly different landscape materials for each shading path
#rb jeremy.moore
[CL 24376462 by dmitriy dyomin in ue5-main branch]
[FYI] Dmitriy.Dyomin
Original CL Desc
-----------------------------------------------------------------
Added a separate entry in a RuntimeVirtualTexture component for a streaming VT that is specific to mobile rendering
Depending on target platform shading path one or the other SVT will be used
This is required for projects that has a significantly different landscape materials for each shading path
#rb jeremy.moore
[CL 24343407 by dmitriy dyomin in ue5-main branch]
[FYI] Dmitriy.Dyomin
Original CL Desc
-----------------------------------------------------------------
Fixed: interface for backward compat from CL# 24335980
[CL 24343402 by dmitriy dyomin in ue5-main branch]
Depending on target platform shading path one or the other SVT will be used
This is required for projects that has a significantly different landscape materials for each shading path
#rb jeremy.moore
[CL 24336769 by dmitriy dyomin in ue5-main branch]
- Replaced uses of these functions in the engine with the global scope equivalents.
- Added some missing global scope RHI...() functions.
- LLM scopes have been moved into the global scope function, where necessary.
Removed several _RenderThread() RHICmdList functions
- These were previously provided for the automatic RHI thread stall / flush mechanism, but now provide no benefit
- Removing these also helps prevent use of FRHICommandListExecutor::GetImmediateCommandList() on threads other than the rendering thread.
Remove RHIExecuteCommandList
- Unused, legacy code path. No platform RHIs provide an implementation. No need to deprecate since there's no way anyone would be calling it already.
#jira none
#rb Zach.Bethel
#preflight 63c86e2dfb1a8cf245f44469
[CL 23771476 by Luke Thatcher in ue5-main branch]
- Removing MaterialAttributeDefinitionMap and MaterialRenderProxy from MaterialShared.h
- Removing MaterialShared from Material.h
#preflight 639cbb35776b61ba3b82f03e
[CL 23541603 by christopher waters in ue5-main branch]
Editor - Upgrading the Texture AssetTypeActions to be AssetDefinitions.
#jira UE-169989
#jira UE-165574
[CL 23121796 by nick darnell in ue5-main branch]
