- Moved them into SDK.json
- Fixed up some deprecation warnings when tarrgeting macOS 13
- IOS is still using old .ini project setting method
#rb adam.kinge, carl.lloyd, zack.neyland
[CL 31651333 by josh adams 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.
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]
