Testing libpas's perf as a malloc already revealed some useful data about how the allocator performs on Windows (like that reserving and committing memory in separate syscalls is surprisingly expensive). Even if we don't use libpas as a UE malloc, running it in that mode is likely to reveal opportunities for improvement in those parts of libpas that the Verse GC uses.
The biggest change to libpas is introducing the global physical page cache, which is a heap of memory that starts out committed but gets tracked by the large sharing pool - so it will get decommitted after 300ms of nonuse. This means that if you're growing the heap, we allocate committed memory (single syscall to reserve and commit), but we still have a path to decommitting alignment slop. This made a 5-10% difference in VerseTestVMCmd's running time.
Resubmitting after making Core only depend on libpas on Windows (since for now, I only expose libpas as a malloc on Windows).
#rb andriy.tylychko
#rb andrew.scheidecker
#rb danny.couture
[CL 26811655 by phil pizlo in ue5-main branch]
[FYI] phil.pizlo
Original CL Desc
-----------------------------------------------------------------
Move libpas out of restricted and make it available as a malloc on Windows.
Testing libpas's perf as a malloc already revealed some useful data about how the allocator performs on Windows (like that reserving and committing memory in separate syscalls is surprisingly expensive). Even if we don't use libpas as a UE malloc, running it in that mode is likely to reveal opportunities for improvement in those parts of libpas that the Verse GC uses.
The biggest change to libpas is introducing the global physical page cache, which is a heap of memory that starts out committed but gets tracked by the large sharing pool - so it will get decommitted after 300ms of nonuse. This means that if you're growing the heap, we allocate committed memory (single syscall to reserve and commit), but we still have a path to decommitting alignment slop. This made a 5-10% difference in VerseTestVMCmd's running time.
#rb andriy.tylychko
#rb andrew.scheidecker
#rb danny.couture
[CL 26795519 by phil pizlo in ue5-main branch]
Testing libpas's perf as a malloc already revealed some useful data about how the allocator performs on Windows (like that reserving and committing memory in separate syscalls is surprisingly expensive). Even if we don't use libpas as a UE malloc, running it in that mode is likely to reveal opportunities for improvement in those parts of libpas that the Verse GC uses.
The biggest change to libpas is introducing the global physical page cache, which is a heap of memory that starts out committed but gets tracked by the large sharing pool - so it will get decommitted after 300ms of nonuse. This means that if you're growing the heap, we allocate committed memory (single syscall to reserve and commit), but we still have a path to decommitting alignment slop. This made a 5-10% difference in VerseTestVMCmd's running time.
#rb andriy.tylychko
#rb andrew.scheidecker
#rb danny.couture
[CL 26795044 by phil pizlo in ue5-main branch]
[FYI] keaton.stewart
Original CL Desc
-----------------------------------------------------------------
[Backout] - CL26221679 [Main CIS Issue] Errors in Incremental FortniteServer Linux and Incremental Compile Monolithics - Linux
[FYI] Josh.Adams
Original CL Desc
-----------------------------------------------------------------
- Very super early support for VisionOS (requires Xcode 15 beta2 or later).
- THIS IS NOT USABLE YET - WORK IN PROGRESS!
- It builds, links with IOS libs (warnings, not errors), can cook and it boots in Simulator, but is dying in MetalRHI
- UnrealTargetPlatform.VisionOS is currently defined in Engine code, it is not pulled out like would be correct for a full true platform extension
- Refactored a lot of Build.cs files to use UnrealPlatformGroup.IOS/Apple instead of individual platform checks, to make VisionOS integration simpler
#rb zack.neyland
[CL 26226852 by josh adams in ue5-main branch]
#fyi Josh.Adams
#jira FORT-626566 (edited)
Original CL Desc
-----------------------------------------------------------------
- Very super early support for VisionOS (requires Xcode 15 beta2 or later).
- THIS IS NOT USABLE YET - WORK IN PROGRESS!
- It builds, links with IOS libs (warnings, not errors), can cook and it boots in Simulator, but is dying in MetalRHI
- UnrealTargetPlatform.VisionOS is currently defined in Engine code, it is not pulled out like would be correct for a full true platform extension
- Refactored a lot of Build.cs files to use UnrealPlatformGroup.IOS/Apple instead of individual platform checks, to make VisionOS integration simpler
#rb zack.neyland
[CL 26223564 by keaton stewart in ue5-main branch]
- THIS IS NOT USABLE YET - WORK IN PROGRESS!
- It builds, links with IOS libs (warnings, not errors), can cook and it boots in Simulator, but is dying in MetalRHI
- UnrealTargetPlatform.VisionOS is currently defined in Engine code, it is not pulled out like would be correct for a full true platform extension
- Refactored a lot of Build.cs files to use UnrealPlatformGroup.IOS/Apple instead of individual platform checks, to make VisionOS integration simpler
#rb zack.neyland
[CL 26221679 by Josh Adams in ue5-main branch]
- Creates the UnrealArchitectures class, which wraps a list of UnrealArch objects
- UnrealArch is a single architecture, expandable enum-like struct
- There is no more concept of "no/default architecture", there is always a valid active architecture when building
- Most uses of "string Architecture" are replaced with one of the two above, depending if multiple architectures are supported or not
- UnrealArch has some platform-extensions for platform-specific naming (like Linux adds in LinuxName that turns, for instance, Arm64 -> aarch64-unknown-linux-gnueabi, which is used in folder names, etc)
- UnrealArch has bIsX64 which can be used determine intel instruction set (as opposed to arm)
- TargetRules class has an "Architecture" accessor that will return a single architecture if the active architectures is a single architecture, or throw an exception if multiple. This is useful in a majority of the cases where a paltform can only have a single architecture active in TargetRules (microsoft platforms, for instance, will create separate targets when compiling multiple architectures at once)
- Added UnrealArchitectureConfig class, which contains all the architecture information for a platform (what architectures are supported, what ones are currently active for given project, etc)
#preflight 63c81fb5b065224750a1759e
#rb mike.fricker,roman.dzieciol,joe.kirchoff,dmytro.vovk,brandon.schaefer [various parts]
#p4v-preflight-copy 23562471
[CL 23829977 by josh adams in ue5-main branch]
* Changed lots of modules to use IWYUSupport instead of bEnforceIWYU (which is being deprecated)
#preflight 63bc8486c45a2c81e0b14fe8
#rb none
[CL 23641460 by henrik karlsson in ue5-main branch]
Fixed include paths to be relative to the private or public folders.
Hid or removed includes that reached into other private module folders.
Updated PublicInclude paths when necessary.
#jira
#preflight 631a717cec45fbf3d74d4ba7
[CL 21916033 by bryan sefcik in ue5-main branch]
Initial submit, compiled out by default.
#rb Peter.Engstrom,Mattias.Hornlund,Brian.Bekich,Ryan.Gerleve,John.Barrett
#jira UE-158381
#preflight /62cd6fc7ad490b52da0515a3
[CL 21068370 by Peter Engstrom in ue5-main branch]
