剖析虚幻渲染体系（01）- 综述和基础

• 待分配内存的大小处于(0, 32k)，使用MemSizeToPoolTable的PoolTable分配和存储。
  
• 待分配内存的大小处于[32k, 48K]或者[64k, 96k]，使用PagePoolTable的PoolTable分配和存储。
  
• 其它待分配内存的大小直接使用系统分配，且放入HashBuckets中。
  为什么UE要将大小在(48k, 64k)的内存直接交给系统分配，而不用装箱方式呢？
  由于FMallocBinned的内存池是等分切割的，如果(48k, 64k)之间的内存用装箱的方式分配，必须放入到64k的内存池，由此将带来(0, 16k)之间的内存浪费。也就是说，在最坏情况下，这个区间里的每次内存分配，都会浪费16k内存，内存浪费比例达到了惊人的33.33%。这对于讲究高性能的UE官方团队来说，明显是不容许的。两害相权取其轻，利害权衡之后，才有了此策略。
  当然，这里存在优化空间，那就是处于(48k, 64k)之间的内存可由更小的Block拼装起来。比如，50k的内存可放进BlockSize为2k的内存池里，占用25个Block即可（但同时会加重内存池和内存池表的管理复杂度）。
  

• FMallocBinned2
  新的箱装内存分配方式，从源码上分析可知，FMallocBinned2比FMallocBinned的分配方式会简单一些，会根据小块内存、对齐大小和是否开启线程缓存（默认开启）选择对应分配器和策略。
  
• FMallocBinned3
  仅64位系统可用的新型箱装内存分配方式。实现方式和FMallocBinned2类似，支持线程缓存。
  
• FMallocTBB
  FMallocTBB采纳的是第三方内存分配器TBB中的scalable_allocator分配器，scalable_allocator提供的接口如下：
  ```c++ // Engine\Source\ThirdParty\IntelTBB\IntelTBB-2019u8\include\tbb\scalable_allocator.h
  void * TBB_EXPORTED_FUNC scalable_malloc (size_t size); void   TBB_EXPORTED_FUNC scalable_free (void ptr); void * TBB_EXPORTED_FUNC scalable_realloc (void* ptr, size_t size); void * TBB_EXPORTED_FUNC scalable_calloc (size_t nobj, size_t size); int TBB_EXPORTED_FUNC scalable_posix_memalign (void** memptr, size_t alignment, size_t size); void * TBB_EXPORTED_FUNC scalable_aligned_malloc (size_t size, size_t alignment); void * TBB_EXPORTED_FUNC scalable_aligned_realloc (void* ptr, size_t size, size_t alignment); void TBB_EXPORTED_FUNC scalable_aligned_free (void ptr); size_t __TBB_EXPORTED_FUNC scalable_msize (void* ptr); ```
  FMallocTBB正是使用了以上的scalable_aligned_malloc接口实现内存操作，其中分配代码如下：
  ```c++ // Engine\Source\Runtime\Core\Private\HAL\MallocTBB.cpp
  void* FMallocTBB::TryMalloc( SIZE_T Size, uint32 Alignment ) {     (......)
  void* NewPtr = nullptr;  if( Alignment != DEFAULT_ALIGNMENT ) {     Alignment = FMath::Max(Size >= 16 ? (uint32)16 : (uint32)8, Alignment);     NewPtr = scalable_aligned_malloc( Size, Alignment ); } else {     // Fulfill the promise of DEFAULT_ALIGNMENT, which aligns 16-byte or larger structures to 16 bytes,     // while TBB aligns to 8 by default.     NewPtr = scalable_aligned_malloc( Size, Size >= 16 ? (uint32)16 : (uint32)8); }   (......)  return NewPtr;
  } ```
  TBB（Threading Building Blocks) 由Intel研发并提供SDK，它的特性有：
  
  
  
  • 提供tbb_allocator、scalable_allocator和cache_aligned_allocator三种分配方式。
    
  • 并行的算法和数据结构。
    
  • 基于任务的内存调度器。
    
  • 对多线程友好，同时支持多个线程操作内存。scalable_allocator不在同一个内存池中分配内存，可以避免多线程竞争导致的消耗。
    
  • 缓存处理效率比其它方式高，cache_aligned_allocator通过缓存对齐，解决假共享的问题。
    
  
  

• 其它内存分配器
  除了以上常用的基础内存分配器之外，UE还附带了FMallocDebug（调试内存）、FMallocStomp（调试非法内存操作）、FMallocJemalloc（适合多线程下的内存分配管理）以及GPU显存相关的分配（FMallocBinnedGPU）等等。这些内存分配方式比较特殊，这里就不详述了，有兴趣的读者自行研读源码。
  

• GMalloc：GMalloc是全局的内存分配器，在UE启动之初就通过FPlatformMemory被创建：
  ```c++ // Engine\Source\Runtime\Core\Private\HAL\UnrealMemory.cpp
  static int FMemory_GCreateMalloc_ThreadUnsafe() {     (......)
  GMalloc = FPlatformMemory::BaseAllocator();  (......)
  } ```
  FPlatformMemory在不同的操作系统对应不同的类型，比如在Windows系统下，实际上是FWindowsPlatformMemory：
  ```c++ // Engine\Source\Runtime\Core\Public\Windows\WindowsPlatformMemory.h
  struct CORE_API FWindowsPlatformMemory : public FGenericPlatformMemory {     (......)
  static class FMalloc* BaseAllocator();  (......)
  };
  typedef FWindowsPlatformMemory FPlatformMemory; ```
  从上面代码可以看出，GMalloc实际上就是FMalloc的实例，在不同的操作系统用FPlatformMemory创建不同的FMalloc子类，从而应用不同的内存分配策略。下面分析FWindowsPlatformMemory::BaseAllocator的代码：
  ```c++ // Engine\Source\Runtime\Core\Private\Windows\WindowsPlatformMemory.cpp
  FMalloc* FWindowsPlatformMemory::BaseAllocator() {
  if ENABLE_WIN_ALLOC_TRACKING
  // This allows tracking of allocations that don't happen within the engine's wrappers. // This actually won't be compiled unless bDebugBuildsActuallyUseDebugCRT is set in the // build configuration for UBT. _CrtSetAllocHook(WindowsAllocHook);
  endif // ENABLE_WIN_ALLOC_TRACKING
  // 根据宏定义采纳不同的内存分配策略 if (FORCE_ANSI_ALLOCATOR) //-V517 {     AllocatorToUse = EMemoryAllocatorToUse::Ansi; } else if ((WITH_EDITORONLY_DATA || IS_PROGRAM) && TBB_ALLOCATOR_ALLOWED) //-V517 {     AllocatorToUse = EMemoryAllocatorToUse::TBB; }
  if PLATFORM_64BITS
  else if ((WITH_EDITORONLY_DATA || IS_PROGRAM) && MIMALLOC_ALLOCATOR_ALLOWED) //-V517 {     AllocatorToUse = EMemoryAllocatorToUse::Mimalloc; } else if (USE_MALLOC_BINNED3) {     AllocatorToUse = EMemoryAllocatorToUse::Binned3; }
  endif
  else if (USE_MALLOC_BINNED2) {     AllocatorToUse = EMemoryAllocatorToUse::Binned2; } else {     AllocatorToUse = EMemoryAllocatorToUse::Binned; }
  if !UE_BUILD_SHIPPING
  // If not shipping, allow overriding with command line options, this happens very early so we need to use windows functions const TCHAR* CommandLine = ::GetCommandLineW();  // 根据命令行调整内存分配策略 if (FCString::Stristr(CommandLine, TEXT("-ansimalloc"))) {     AllocatorToUse = EMemoryAllocatorToUse::Ansi; }
  if TBB_ALLOCATOR_ALLOWED
  else if (FCString::Stristr(CommandLine, TEXT("-tbbmalloc"))) {     AllocatorToUse = EMemoryAllocatorToUse::TBB; }
  endif
  if MIMALLOC_ALLOCATOR_ALLOWED
  else if (FCString::Stristr(CommandLine, TEXT("-mimalloc"))) {     AllocatorToUse = EMemoryAllocatorToUse::Mimalloc; }
  endif
  if PLATFORM_64BITS
  else if (FCString::Stristr(CommandLine, TEXT("-binnedmalloc3"))) {     AllocatorToUse = EMemoryAllocatorToUse::Binned3; }
  endif
  else if (FCString::Stristr(CommandLine, TEXT("-binnedmalloc2"))) {     AllocatorToUse = EMemoryAllocatorToUse::Binned2; } else if (FCString::Stristr(CommandLine, TEXT("-binnedmalloc"))) {     AllocatorToUse = EMemoryAllocatorToUse::Binned; }
  if WITH_MALLOC_STOMP
  else if (FCString::Stristr(CommandLine, TEXT("-stompmalloc"))) {     AllocatorToUse = EMemoryAllocatorToUse::Stomp; }
  endif // WITH_MALLOC_STOMP
  endif // !UE_BUILD_SHIPPING
  // 根据不同的类型创建FMalloc的子类对象。 switch (AllocatorToUse) { case EMemoryAllocatorToUse::Ansi:     return new FMallocAnsi();
  if WITH_MALLOC_STOMP
  case EMemoryAllocatorToUse::Stomp:     return new FMallocStomp();
  endif
  if TBB_ALLOCATOR_ALLOWED
  case EMemoryAllocatorToUse::TBB:     return new FMallocTBB();
  endif
  if MIMALLOC_ALLOCATOR_ALLOWED && PLATFORM_SUPPORTS_MIMALLOC
  case EMemoryAllocatorToUse::Mimalloc:     return new FMallocMimalloc();
  endif
  case EMemoryAllocatorToUse::Binned2:     return new FMallocBinned2();
  if PLATFORM_64BITS
  case EMemoryAllocatorToUse::Binned3:     return new FMallocBinned3();
  endif
  default:    // intentional fall-through case EMemoryAllocatorToUse::Binned:     return new FMallocBinned((uint32)(GetConstants().BinnedPageSize&MAX_uint32), (uint64)MAX_uint32 + 1); }
  } ```
  由此可知，GMalloc是通过FMalloc的子类来操作内存。下表是不同的操作系统支持及默认的内存分配方式：
  

• FMemory：FMemory是UE的静态工具类，它提供了很多静态方法，用于操作内存，常见的api如下：
  ```c++ // Engine\Source\Runtime\Core\Public\HAL\UnrealMemory.h
  struct CORE_API FMemory {     // 直接调用c的内存分配和释放接口.     static void SystemMalloc(SIZE_T Size);     static void SystemFree(void Ptr);
  // 通过GMalloc对象操作内存 static void* Malloc(SIZE_T Count, uint32 Alignment = DEFAULT_ALIGNMENT); static void* Realloc(void* Original, SIZE_T Count, uint32 Alignment = DEFAULT_ALIGNMENT); static void Free(void* Original); static void* MallocZeroed(SIZE_T Count, uint32 Alignment = DEFAULT_ALIGNMENT);  // 内存辅助接口 static void* Memmove( void* Dest, const void* Src, SIZE_T Count ); static int32 Memcmp( const void* Buf1, const void* Buf2, SIZE_T Count ); static void* Memset(void* Dest, uint8 Char, SIZE_T Count); static void* Memzero(void* Dest, SIZE_T Count); static void* Memcpy(void* Dest, const void* Src, SIZE_T Count); static void* BigBlockMemcpy(void* Dest, const void* Src, SIZE_T Count); static void* StreamingMemcpy(void* Dest, const void* Src, SIZE_T Count); static void Memswap( void* Ptr1, void* Ptr2, SIZE_T Size );  (......)
  }; ```
  从上面代码可知，FMemory既支持GMalloc也支持C风格的内存操作。
  
• new/delete操作符：除了部分类重载了new和delete操作符之外，其它全局的new和delete使用的是以下声明：
  ```c++ // Engine\Source\Runtime\Core\Public\Modules\Boilerplate\ModuleBoilerplate.h
  define REPLACEMENT_OPERATOR_NEW_AND_DELETE \
  OPERATOR_NEW_MSVC_PRAGMA void* operator new  ( size_t Size                        ) OPERATOR_NEW_THROW_SPEC      { return FMemory::Malloc( Size ); } \ OPERATOR_NEW_MSVC_PRAGMA void* operator new[]( size_t Size                        ) OPERATOR_NEW_THROW_SPEC      { return FMemory::Malloc( Size ); } \ OPERATOR_NEW_MSVC_PRAGMA void* operator new  ( size_t Size, const std::nothrow_t& ) OPERATOR_NEW_NOTHROW_SPEC    { return FMemory::Malloc( Size ); } \ OPERATOR_NEW_MSVC_PRAGMA void* operator new[]( size_t Size, const std::nothrow_t& ) OPERATOR_NEW_NOTHROW_SPEC    { return FMemory::Malloc( Size ); } \ void operator delete  ( void* Ptr )                                                 OPERATOR_DELETE_THROW_SPEC   { FMemory::Free( Ptr ); } \ void operator delete[]( void* Ptr )                                                 OPERATOR_DELETE_THROW_SPEC   { FMemory::Free( Ptr ); } \ void operator delete  ( void* Ptr, const std::nothrow_t& )                          OPERATOR_DELETE_NOTHROW_SPEC { FMemory::Free( Ptr ); } \ void operator delete[]( void* Ptr, const std::nothrow_t& )                          OPERATOR_DELETE_NOTHROW_SPEC { FMemory::Free( Ptr ); } \ void operator delete  ( void* Ptr, size_t Size )                                    OPERATOR_DELETE_THROW_SPEC   { FMemory::Free( Ptr ); } \ void operator delete[]( void* Ptr, size_t Size )                                    OPERATOR_DELETE_THROW_SPEC   { FMemory::Free( Ptr ); } \ void operator delete  ( void* Ptr, size_t Size, const std::nothrow_t& )             OPERATOR_DELETE_NOTHROW_SPEC { FMemory::Free( Ptr ); } \ void operator delete[]( void* Ptr, size_t Size, const std::nothrow_t& )             OPERATOR_DELETE_NOTHROW_SPEC { FMemory::Free( Ptr ); }
  ```
  从源码可以看出，全局的内存操作符也是通过调用FMemory完成内存操作。
  
• 特定API：除了以上三种内存操作方式，UE还提供了各类创建、销毁特定内存的接口，它们通常是成对出现，例如：
  ```c++ struct FPooledVirtualMemoryAllocator {     void Allocate(SIZE_T Size);     void Free(void Ptr, SIZE_T Size); };
  class CORE_API FAnsiAllocator {     class CORE_API ForAnyElementType     {         void ResizeAllocation(SizeType PreviousNumElements, SizeType NumElements, SIZE_T NumBytesPerElement);     }; };
  class FVirtualAllocator {     void AllocateVirtualPages(uint32 NumPages, size_t AlignmentForCheck);     void FreeVirtual(void Ptr, uint32 NumPages); };
  class RENDERER_API FVirtualTextureAllocator {     uint32 Alloc(FAllocatedVirtualTexture VT );     void Free(FAllocatedVirtualTexture VT ); };
  template class TMemoryPool {     void Allocate(SIZE_T Size);     void Free(void Ptr, SIZE_T Size); }; ```
  

• Mark-Sweep。即标记-清理算法，算法分两个阶段：
  第一阶段是标记（Mark）阶段，过程是遍历根的活动对象列表，将所有活动对象指向的堆对象标记为TRUE。
  

• BiBOP。全称是Big Bag Of Pages，它的做法是将大小相近的对象整理成固定大小的块进行管理，跟UE的FMallocBinned分配器的策略如出一辙。
  

• Conservative GC。保守式GC，的特点是不能识别指针和非指针。由于在GC层面，单凭一个变量的内存值无法判断它是否指针，由此引申出很多方法来判断，需要付出一定的成本。与之相反的是准确式GC（Exact GC），它能通过标签（tag）来明确标识是否指针。
  
• Generational GC。分代垃圾回收，该方法在对象中引入年龄的概念，通过优先回收容易成为垃圾的对象，提高垃圾回收的效率。
  
• Incremental GC。增量式垃圾回收，通过逐渐推进垃圾回收来控制mutator最大暂停时间的方法。
  

• Reference Counting Immix。简称RC Immix算法，即合并引用型GC算法。目的是通过某种策略改善引用计数的行为，以达到提升GC吞吐量的目的。
  

• 主要算法是Mark-Sweep。但不同于传统Mark-Sweep算法只有2个步骤，UE的GC有3个步骤：
  1、索引可达对象。
  2、收集待清理对象。
  3、清理步骤2收集到的对象。
  
• 在游戏线程上对UObject进行清理。
  
• 线程安全，支持多线程并行(Parallel)和群簇(Cluster)处理，以提升吞吐率。
  
• 支持全量清理，编辑器模式下强制此模式；也支持增量清理，防止GC处理线程卡顿太久。
  
• 可指定某些标记的物体不被清理。
  

MESI协议是一个基于失效的缓存一致性协议，是支持回写（write-back）缓存的最常用协议。常用于多核CPU的高速缓存和主内存的同步。
MESI协议的基础状态：Modified、Exclusive、Shared、Invalid。
MESI协议的消息：Read、Read Response、Invalidate、Invalidate Acknowledge、Read Invalidate、Writeback。
MESI协议的基础状态的转换如下图：

• MESI protocol
  
• Memory Barriers: a Hardware View for Software Hackers
  

• LoadLoad：可以防止重新排序（reorder）导致的在屏障前后的读取操作的乱序问题。
  

• StoreStore：可以防止重排序导致的在屏障前后的写入操作的乱序问题。
  

• LoadStore：可以防止屏障前的加载操作和屏障后存储操作的重排序。应用举例：
  c++ if (IsValid)            // 加载并检测IsValid {     LOADSTORE_FENCE();  // LoadStore屏障防止加载和写入之间的重排序，在Value及后续写入操作被刷出前，保证IsValid要读取的数据被读取完毕。     Value = x;          // 写入Value }
  
• StoreLoad：可以防止屏障前的写入操作和屏障后加载操作的重排序。在大多数CPU架构中，它是个万能屏障，兼具其它三种内存屏障的功能，但开销也是最大的。应用举例：
  c++ Value = x;          // 写入Value STORELOAD_FENCE();  // 在IsValid及后续所有读取操作执行前，保证Value的写入对所有处理器可见。 if (IsValid)        // 加载并检测IsValid {     return 1; }
  

• Sequential consistency：顺序一致，所有的读取和写入操作都是顺序的。
  
• Relaxed consistency：松散一致（或理解成部分一致性），Load之后的Load、Store之后的Store、Load之后的Store、Store之后的Load都会引起重新排序。
  
• Weak consistency：弱一致，所有的读取和写入操作都可能引起重排序，除非有显式的内存屏障。
  

• Memory ordering
  
• Memory Barriers Are Like Source Control Operations
  
• 从硬件层面理解Memory Barrier
  

Compiler support for hardware memory barriers
Some compilers support builtins that emit hardware memory barrier instructions:

• GCC, version 4.4.0 and later, has __sync_synchronize.
  
• Since C11 and C++11 an atomic_thread_fence() command was added.
  
• The Microsoft Visual C++ compiler has MemoryBarrier().
  
• Sun Studio Compiler Suite has __machine_r_barrier, __machine_w_barrier and __machine_rw_barrier.
  

• 根据配置文件创建对应的游戏引擎实例并存储到GEngine， 后面会大量使用到GEngine实例。
  
• 根据是否支持多线程判断是否需要创建EngineService实例。
  
• 执行GEngine->Start()。
  
• 加载Media、AutomationWorker、AutomationController、ProfilerClient、SequenceRecorder、SequenceRecorderSections模块。
  
• 开启线程心跳FThreadHeartBeat。
  
• 注册外部分析器FExternalProfiler。
  

• 开启线程和线程钩子心跳。
  
• 更新渲染模块可每帧更新的物体（FTickableObjectRenderThread实例）。
  
• 分析器（FExternalProfiler）帧同步。
  
• 执行控制台的回调接口。
  
• 刷新渲染命令（FlushRenderingCommands）。如果未开启单独的渲染线程，会在游戏线程执行渲染指令，随后调用ImmediateFlush确保命令队列提交绘制。在末尾会添加渲染栅栏（FRenderCommandFence）。
  ```c++ // Engine\Source\Runtime\RenderCore\Private\RenderingThread.cpp
  void FlushRenderingCommands(bool bFlushDeferredDeletes) {     (......)
  if (!GIsThreadedRendering     && !FTaskGraphInterface::Get().IsThreadProcessingTasks(ENamedThreads::GameThread)     && !FTaskGraphInterface::Get().IsThreadProcessingTasks(ENamedThreads::GameThread_Local)) {     FTaskGraphInterface::Get().ProcessThreadUntilIdle(ENamedThreads::GameThread);     FTaskGraphInterface::Get().ProcessThreadUntilIdle(ENamedThreads::GameThread_Local); }  ENQUEUE_RENDER_COMMAND(FlushPendingDeleteRHIResourcesCmd)(     [bFlushDeferredDeletes](FRHICommandListImmediate& RHICmdList) {     RHICmdList.ImmediateFlush(         bFlushDeferredDeletes ?         EImmediateFlushType::FlushRHIThreadFlushResourcesFlushDeferredDeletes :         EImmediateFlushType::FlushRHIThreadFlushResources); });  AdvanceFrameRenderPrerequisite();  FPendingCleanupObjects* PendingCleanupObjects = GetPendingCleanupObjects();  FRenderCommandFence Fence; Fence.BeginFence(); Fence.Wait();  (......)
  } ```
  
• 触发OnBeginFrame事件。
  
• 刷新线程日志。
  
• 用GEngine刷新时间和处理最大帧率。
  
• 遍历所有WorlContext的当前World，更新World内的场景的PrimitiveSceneInfo。这里直接贴代码可能更容易理解：
  C++ for (const FWorldContext& Context : GEngine->GetWorldContexts()) {     UWorld* CurrentWorld = Context.World();     if (CurrentWorld)     {         FSceneInterface* Scene = CurrentWorld->Scene;         ENQUEUE_RENDER_COMMAND(UpdateScenePrimitives)(             [Scene](FRHICommandListImmediate& RHICmdList)             {                 Scene->UpdateAllPrimitiveSceneInfos(RHICmdList);             });     } }
  
• 处理RHI帧开头。
  
• 调用所有场景的StartFrame。
  
• 处理性能分析和数据统计。
  
• 处理渲染线程的每帧任务。
  
• 处理世界标尺缩放（WorldToMetersScale）。
  
• 更新活动平台的文件。
  
• 处理Slate模块输入。
  
• GEngine的Tick事件。这个是主要的帧更新，很多逻辑都将在此处理。下面是UGameEngine::Tick的主要流程：
  
  
  
  • 如果时间间隔够了，刷新Log。
    
  • 清理已经关闭的游戏视图（Viewport）。
    
  • 更新子系统（subsystem）。
    
  • 更新FEngineAnalytics、FStudioAnalytics模块。
    
  • （如果开启Chaos）更新ChaosModule。
    
  • 处理WorldTravel的帧更新。
    
  • 处理所有World的帧更新。
    
  • 更新天空光组件（USkyLightComponent）和反射球组件（UReflectionCaptureComponent）。说明这两个组件比较特殊，需要hard code。
    
  • 处理玩家对象（ULocalPlayer）。
    
  • 处理关卡流式加载。
    
  • 更新所有可更新的物体。此处更新的是FTickableGameObject。
    
  • 更新GameViewport。
    
  • 处理窗口模式下的窗口。
    
  • 绘制Viewport。
    
  • 更新IStreamingManager、FAudioDeviceManager模块。
    
  • 更新渲染相关的GRenderingRealtimeClock、GRenderTargetPool、FRDGBuilder等模块。
    
  
  

• 处理GShaderCompilingManager的异步编译结果。
  
• 处理GDistanceFieldAsyncQueue（距离场异步队列）的异步任务。
  
• 并行处理Slate相关的任务逻辑。
  
• 处理可复制属性（ReplicatedProperties）。
  
• 利用FTaskGraphInterface处理存储于ConcurrentTask的并行任务。
  
• 等待渲染队列未解决的渲染任务。可能理解的不准确，还是贴代码：
  c++ ENQUEUE_RENDER_COMMAND(WaitForOutstandingTasksOnly_for_DelaySceneRenderCompletion)(     [](FRHICommandList& RHICmdList)     {         QUICK_SCOPE_CYCLE_COUNTER(STAT_DelaySceneRenderCompletion_TaskWait);         FRHICommandListExecutor::GetImmediateCommandList().ImmediateFlush(EImmediateFlushType::WaitForOutstandingTasksOnly);     });
  
• 更新AutomationWorker模块。
  
• 更新RHI模块。
  
• 处理帧计数（GFrameCounter）和总的帧更新时间（TotalTickTime）。
  
• 收集需要在下一帧被清理的物体。
  
• 处理帧结束同步事件（FFrameEndSync）。
  
• 更新Ticker、FThreadManager和GEngine的TickDeferredCommands。
  
• 在游戏线程触发OnEndFrame。
  
• 在渲染模块触发EndFrame事件。
  

• 感谢所有参考文献的作者，部分图片来自参考文献和网络，侵删。
  
• 本系列文章为笔者原创，只发表在博客园上，欢迎分享本文链接，但未经同意，不允许转载！
  
• 系列文章，未完待续，完整目录请戳内容纲目。
  
• 系列文章，未完待续，完整目录请戳内容纲目。
  
• 系列文章，未完待续，完整目录请戳内容纲目。
  

• Unreal Engine 4 Sources
  
• Unreal Engine 4 Documentation
  
• Rendering and Graphics
  
• Materials
  
• Graphics Programming
  
• Unreal Engine
  
• Unreal Engine 4 Rendering
  
• 虚幻引擎游戏列表
  
• 剖析Unreal Engine超真实人类的渲染技术Part 1 - 概述和皮肤渲染
  
• 探究光线追踪技术及UE4的实现
  
• 深入GPU硬件架构及运行机制
  
• 初探虚幻引擎5
  
• 《大象无形-虚幻引擎程序设计浅析》
  
• 《房燕良-虚幻4渲染系统架构解析》
  
• UE4 Render System Sheet
  
• The End of Moore’s Law and the Return of Cleverness
  
• FrameGraph Extensible Rendering Architecture in Frostbite
  
• 为Unity开发者准备的虚幻引擎4指南
  
• Unreal Engine Math
  
• Neon
  
• Streaming SIMD Extensions
  
• Floating-point unit
  
• Inside UE4
  
• Exploring in UE4
  
• c++ lambda
  
• 为什么要有切线空间？
  
• Survey of Efficient Representations for Independent Unit Vectors
  
• UE4内存管理(1)
  
• UE4源码剖析：MallocBinned
  
• UE4内存优化知识点整理
  
• 游戏设计模式——内存池管理
  
• 《垃圾回收的算法与实现》
  
• 《游戏引擎架构》
  
• Memory stomp allocator for Unreal Engine 4
  
• Intel Threading Building Blocks
  
• 给虚幻4添加内存跟踪功能
  
• Memory ordering
  
• Memory barrier
  
• Memory barrier 简介
  
• 从硬件层面理解Memory Barrier
  
• Using JDK 9 Memory Order Modes
  
• Memory Barriers Are Like Source Control Operations
  
• 内存屏障
  
• Memory Barriers: a Hardware View for Software Hackers
  
• MESI protocol
  
• User mode and kernel mode
  
• UE4 垃圾回收
  
• UE4 垃圾回收（二）GC Cluster
  
• 虚幻4垃圾回收剖析