Cannot easily specialize the specialization's config settings, so a different approach is required.
#jira UE-115613
#rb none
#rnx
[CL 16382731 by David Harvey in ue5-main branch]
- In a complex material, compiler may not be able to see through the code to discover all unused inputs.
E.g. first pass compilation says that input A is unused, but B and C are used. After we rewrite the code to remove A, the code is simpler and compiler is now able to see that B is also unused.
Since we pass the "used attributes" to the next stage, this creates a mismatch where vertex shader outputs only C, but pixel shader (rewritten based on the first pass results) expects B and C.
- The fixed code will check if the unused inputs changed, and if so, will go back and rewrite the code based on a more complete info.
- This fixes a bug that JonL ran into for which I haven't yet created a JIRA (will do before checkin).
#rb Ben.Ingram, Rolando.Caloca, Jason.Nadro
#review @Lukas.Hermanns, @Rolando.Caloca, @Ben.Ingram, @Jason.Nadro, @Kevin.Ortegren
#jira UE-115083
[CL 16312596 by Arciel Rekman in ue5-main branch]
Example usage in a shader:
PLATFORM_ASSERT4(GroupThread > 4321, 0xDF7DC903, GroupThread, GroupIndex, GroupBase, asuint(123.456f));
Example GPU crash report output:
LogD3D12RHI: Error: [GPUBreadCrumb] Last tracked GPU operations:
LogD3D12RHI: Error: [GPUBreadCrumb] 3D Queue 0 - Begin: Frame 348 - Scene - ReflectionIndirect - RayTracingReflections - RayTracingDeferredReflectionsShade 957x466
LogD3D12RHI: Error: [GPUBreadCrumb] Shader assertion failed! ID: 0xDF7DC903
LogD3D12RHI: Error: [GPUBreadCrumb] Payload [int32]: 416 42 172032 1123477881
LogD3D12RHI: Error: [GPUBreadCrumb] Payload [uint32]: 416 42 172032 1123477881
LogD3D12RHI: Error: [GPUBreadCrumb] Payload [hex]: 0x000001A0 0x0000002A 0x0002A000 0x42F6E979
LogD3D12RHI: Error: [GPUBreadCrumb] Payload [float]: 0.000000 0.000000 0.000000 123.456001
This works through automatic diagnostic buffer binding in D3D12 RHI, which becomes available in *any* shader as a UAV.
Opens the door for arbitrary human-readable message output from any shader in the future.
PLATFORM_ASSERT macro is always enabled and available on supported platforms. It is intended to be a low-level mechanism for a higher-level check() that would be controlled via CVars.
#rb Christopher.Waters
[CL 16167404 by Yuriy ODonnell in ue5-main branch]
1) Changed the pre/post compile notifications from module notifications to process commands.
2) Added server command to notify that we want re-instance patching (two phase)
3) Added support for two phase patching to enable re-instancing without all the limitations.
4) Added a null CDO check for old blueprint classes (approved by Phillip)
#rb ben.marsh
#rnx
#preflight 6086e3481046fb000183c2d4
[CL 16115620 by Tim Smith in ue5-main branch]
Disabled by default (guarded by USE_SHADER_MODEL_6_6).
Includes work done by Yuriy.
#rb yuriy.odonnell
#fyi brian.karis, christopher.waters, lukas.hermanns
[CL 15914077 by graham wihlidal in ue5-main branch]
#rb none
#jira UE-111726
#ROBOMERGE-SOURCE: CL 15852110 in //UE5/Release-5.0-EarlyAccess/...
#ROBOMERGE-BOT: STARSHIP (Release-5.0-EarlyAccess -> Main) (v786-15839533)
[CL 15852982 by tim smith in ue5-main branch]
#rb none
#jira UE-111710
#ROBOMERGE-SOURCE: CL 15852066 in //UE5/Release-5.0-EarlyAccess/...
#ROBOMERGE-BOT: STARSHIP (Release-5.0-EarlyAccess -> Main) (v786-15839533)
[CL 15852981 by tim smith in ue5-main branch]
LIMITATIONS:
1) Re-instancing will only update UClass instance data.
2) Adding and removing properties should only be done towards the end of a class or structure and can not be followed by complex data types.
3) Adding and removing properties from a base class should not be done if a derived class contains complex data types.
KNOWN ISSUES:
1) Changes to enumerations and structures will not be reflected in existing blueprints. However, adding new nodes to the blueprint will show the updated enumeration or structure.
2) If a class contains an enumeration or structure as a member, the class will not be re-instanced if enumeration or structure is changed.
CHANGES:
1) LiveCodingServer
1a) Modified to always execute certain static instances during load.
1b) Modified to exclude the _Statics static structures to avoid patching to old copies.
2) Added support for LiveCoding reinstancing
2a) Refactored deferred registration system for UClass, UEnum, and UScriptStruct to use a common system that works for normal game, hot reload and live coding.
2b) Type specific version check data is possible (i.e. enum doesn't have a size)
2c) Single registration static for UClass
2d) Single registration class for all types that is just a blind forward to API.
2e) Static and dynamic registrations use different API entry points to avoid having overloaded argument lists that just apply to one or the other.
2f) Shims for older API
3) New common "Reload" system to avoid using HotReload code.
3a) Support common delegates regardless of who is reloading/reinstancing.
3b) Re-instancing code moved from HotReload to Kismet2 (where the bulk of the re-instance code already existed).
3c) Modified PyWrapper to use new helper class instead of depending on HotRelaod
3d) Added WITH_RELOAD which is defined if HotReload or LiveCoding is enabled.
3e) Modifed existing code to use new #define and delegates.
Robert did the review on the changes covered by Part 2. Remaining changes are all straightforward.
#rb robert.manuszewski
#jira UE-74493
[CL 15736777 by Tim Smith in ue5-main branch]
