- Some static variables made it tricky, so added some support to make it simpler on users of the static variables
#rb David.Harvey
[CL 31431760 by josh adams in 5.4 branch]
Support wave size 64 lumen compute inline RT dispatches and enable by default on Android.
Allow use of wave ops as long as they are supported in fragment and compute shaders (Vulkan). Vulkan implementation on Android typically don't support it in vertex and geometry stage.
#jira UE-200580
#rb Krzysztof.Narkowicz
[CL 31103399 by florian penzkofer in 5.4 branch]
#rb charles.derousiers
[FYI] florin.pascu, henry.falconer, per.karefelt
#ushell-cherrypick of 30955220 by Charles.deRousiers
[CL 30955839 by charles derousiers in 5.4 branch]
- Added r.ParallelGatherDynamicMeshElements to control whether the feature is enabled. When disabled, tasks are constrained to the render thread as before.
- Added r.Visibility.DynamicMeshElements.NumTasks and r.Shadow.DynamicMeshElements.NumTasks which both default to 4. Thread contention becomes an issue at higher task counts for proxies which do a lot of uniform buffer or resource creation / updates.
Implementation Details:
The scene view visibility path typically has many dynamic elements per view, whereas there are typically more shadow views processing fewer elements each.
The main visibility path pushes dynamic primitives into a queue which is then processed by N async tasks, each with its own mesh collector and global vertex / index buffer. If a scene proxy is marked as not supporting parallel GDME, it is processed instead on the render thread in parallel with other async tasks. Niagara is currently the only proxy which is marked as unsupported by parallel GDME, as it has many potential sync points that would need to be untangled. When the async tasks complete, the task contexts are merged back to the view in an async task prior to launching dynamic mesh passes. Another important detail is that all material and GPU scene ops are deferred by the mesh collector and finalized at the end on the render thread. Deferring materials is necessary to allow the VT update task to overlap with GDME. The GPU scene updates are not thread safe and must be deferred.
The shadow path instead creates a queue of FProjectedShadowInfo's which is processed in parallel by async gather tasks (each with its own collector context). If a particular shadow has proxies that do not support parallel GDME, then a second pass is done over that FProjectedShadowInfo on the render thread to process the render thread only proxies. The dynamic mesh passes are launched asynchronously as well and are waited on by the shadow depth rendering passes later in the frame.
#rb krzysztof.narkowicz, christopher.waters
[CL 29289633 by zach bethel in ue5-main branch]
OpenGL ES and Metal use framebuffer fetch.
Vulkan uses dual source blending.
For Vulkan and OpenGL ES there is a fallback shader permutation for drivers that don't support this. The fallback is the same as the existing solution that uses regular blending (i.e. looks different).
Others uses dual source blending and we force use of DXC for those shaders.
#rb Dmitriy.Dyomin, Florin.Pascu
[CL 29245271 by florian penzkofer in ue5-main branch]
Platforms that do support uniform buffer objects can now provide batched primitive data through UBO. There is a limit UBO range that can be accessed in shaders, so we group instances into batches that fit into this limit. Switch uses 64KB views, other platfroms16KB views. For each primitive we allocate 512Bytes and 256Bytes for instance. Mobile platforms that do not support UBO will use a desktop version of GPUScene.
There are a few things that still missing: Dynamic mesh passes, static lighting
#rb ola.olsson, benjamin.rouveyrol
[CL 26354848 by marc audy in ue5-main branch]
* This should be used to guard any features that require explicitly accessing buffer or textures SRVs in vertex shaders
#rb Dmitriy.Dyomin
#rb Kenzo.Terelst
[CL 26207274 by yuriy odonnell in ue5-main branch]
- Allow for per-project override in a project's platform's config folder (this is merging with my other work on per-project SDKs and validation of multi-target builds)
- More versions will move over after this
#rb david.harvey
[CL 26150552 by josh adams in ue5-main branch]
r.ShaderPipelines
r.Material.ExcludeNonPipelinedShaders
Both cvars are currently disable on WindowsEngine.ini which make them also disable when we cook for consoles. ExcludeNonPipelinedShaderTypes is currently used only at cooking time when we compile shaders which is currently returning false, since the value is disabled on windows. Making those cvars use FShaderPlatformCachedIniValue, will allow to have specific platform value when cooking for a specific target. Moving r.Material.ExcludeNonPipelinedShaders to the defaultengine.ini file to keep it disable for the moment and not affecting shader key string. Will enable it progressively on console later.
r.Shaders.RemoveUnusedInterpolators
Make that cvar platform agnostic, since it will be used in on other consoles eventually. Platforms supporting the stripping of unused interpolators will check the same flag (CFLAG_ForceRemoveUnusedInterpolators) to enable it. Since windows can run opengl, and stripping is not supported on that shader platform, add extra logic to exclude the flag.
-Make the RHISupportsShaderPipelines function access a real DDPI attribute and not just test if we are not on mobile. Will need this to be able to have stripping unused shader interpolators on Switch.
[REVIEW] Laura.Hermanns
[CL 26018371 by serge bernier in ue5-main branch]
