This represents UE4/Main @18073326, Release-5.0 @18081140 and Dev-PerfTest @18045971
[CL 18081471 by aurel cordonnier in ue5-release-engine-test branch]
This represents UE4/Main @17774255, Release-5.0 @17791557 and Dev-PerfTest @17789485
[CL 17794212 by aurel cordonnier in ue5-release-engine-test branch]
#rb cm
#rnx
#ROBOMERGE-SOURCE: CL 17048347 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v850-17047176)
[CL 17048351 by martin ridgers in ue5-release-engine-test branch]
- This makes the output of memreport much easier to read:
812.081MB - StaticMesh Total Memory - STAT_StaticMeshTotalMemory2 - STATGROUP_MemoryStaticMesh - STATCAT_Advanced
#rb Dave.Jones2
#ROBOMERGE-SOURCE: CL 16926919 via CL 16927028
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v836-16769935)
[CL 16927051 by jason nadro in ue5-release-engine-test branch]
The following code would call the int overload rather than the name overload when passed an EName constant, which could easily lead to confusion and bugs:
using FMyId = uint8;
void DoThing(FName);
void DoThing(FMyId);
DoThing(NAME_Actor);
The change to use enum class requires that any code that actually deals with EName as an int (mostly internal name code and serialisation) be updated to explicitly cast, but prevents the implicit conversion that causes the issue above.
In order to preserve the NAME_X aliases that the old-style enum added to the global scope, new aliases have been added that point to the EName scoped versions. Unfortunately these can cause shadowing warnings if NAME_X is defined in the local scope, as the old-style enum used to allow that without shadowing, however there is no way to prevent this so we'll just need to fix any warnings that occur.
#rb Johan.Torp
#preflight 6087e06349a9840001414708
[CL 16126708 by Jamie Dale in ue5-main branch]
* the thread was removed and its surrounding was cleaned up a bit
* ENamedThreads::StatsThread (and relatives) deprecated
* support for single-threaded execution looks a bit messy because it still have to be based on the old TaskGraph API until we convert the game thread to the new API (which will be one of the very last things)
* despite the direct usage of ENamedThreads::StatsThread from an external code is highly unlikely, to preserve backward compatiblity internally TaskGraph redirects all remaining stats tasks to StatsPipe
#rb martin.ridgers
[CL 15794122 by Andriy Tylychko in ue5-main branch]
