Added support for writing fixed color when baking SVT. This replaces the fixed "debug" function and allows us to use the feature outside of debug usage.
Fixed path that creates an SVT for displacement map. Here the fixed color can be used to effectively set a zero displacement for the low resolution mips.
Added r.VT.RVT.MipColors cvar which uses the fixed color support to generate RVT using debug mip colors. This is useful for debugging issues with materials sampling higher resolution mips than expected, putting pressure on the physical pools.
Removed r.VT.RVT.EnableVolumes cvar which is no longer required now that volumes can be enabled/disabled per platform without triggering page table or physical texture allocations.
Added support for custom expanding of bounds for RVT volume.
Tidied naming of categories and sections for the RVT components.
[CL 30550025 by jeremy moore in ue5-main branch]
When calculating RVT bounds, if the bounds align actor is a landscape, then include all of its landscape components.
[CL 30091367 by jeremy moore in ue5-main branch]
Texture IsPowerOfTwo check was confusingly only checking first block
most call sites want to check AreAllBlocksPowerOfTwo
deprecate the old problematic function name
#rb dan.thompson
#rnx
[CL 29820923 by charles bloom in ue5-main branch]
shrinks sources above threshold size to make uassets smaller
tries to change LODBias to keep output size the same, but that is in no way guaranteed
#rb dan.thompson
#rnx
[CL 29527423 by charles bloom 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]
[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]
