Haony's Site

本篇简单介绍下UE5的虚拟几何技术Nanite。UE5的Nanite是一款革命性虚拟几何体渲染系统，依托GPU驱动渲染技术与全新网格格式，打破传统多边形预算限制，实现像素级细节与海量模型的高效渲染，核心价值在于将几何渲染从“多边形数量约束”转向“像素细节驱动”。其通过分层聚类存储网格，导入时拆解为三角形组层级簇结构，支持连续LOD无离散跳变，同时高度压缩数据，仅按需流式加载可见细节，大幅降低显存开销。渲染阶段由GPU实时完成可见性剔除、LOD动态切换与光栅化，有效规避CPU瓶颈。 网络上关于Nanite的介绍文章有很多，有些讲的非常的详细，甚至从源码级别介绍Nanite的相关优化技术，这里就主要对比下Nanite和之前文章介绍到的GPU Driven技术的一些区别和联系。 Nanite对于网格的处理和之前的方法类似，都是将原始的网格转换为一个个的cluster来表示，后续所有的culling，rendering都是基于cluster级别来进行。但是Nanite和之前的游戏所面临或者说面向的场景的三角形数量的量级是不一样的，Nanite场景中三角形能达到几亿，甚至几十亿，当三角...

【SIGGRAPH 2021】Geometry Rendering Pipeline Architecture这篇文章是动视暴雪在2021年的分享，主要介绍引擎处理场景中大量复杂的geometry的渲染，提出了一套geometry processing pipeline。 从小场景转向开放世界后，场景中需要处理的三角形数量大幅度增加，达到800多万，这意味在引擎和目标平台不变的情况下，三角形的数量翻了整整十倍。场景中不仅模型数量众多，而且网格mesh的密度也很大。 动视旗下的游戏拥有多款经过优化的不同的渲染引擎，支持包括Forward+(F+), Deferred, Visibility+(V+)等渲染管线。 Forward+ : 着色在几何绘制阶段完成，所有顶点的数据从VS阶段直接传递到PS阶段，并由PS着色器完成着色计算。 Deferred : 着色分为两个阶段，在GBUFFER阶段执行vs-ps管线，生成BRDF所需要的所有的参数并保存为GBuffer Texture；然后是计算着色阶段，读取GBUFFER完成统一的着色计算。 Visibility+: 将几何于着色...

【GDC 2019】GPU Driven Rendering and Virtual Texturing in Trials Rising这篇文章是育碧在GDC2019上的一篇演讲，主要介绍《Trials Rising》中的GUP Driven Rendering技术。 这是一款UGC的游戏，游戏场景由大量的macro block组成，场景的几何复杂度很高。而且由于是UGC，所以不同的关卡的复杂度是不一样的，而且差别可能会比较大。 目前的引擎遇到的问题是，首先场景中存在大量的可见的instance，大概有2500左右。有两个CPU的核心在为rendering服务（包括收集可见信息和发起draw command），所以CPU存在巨大的瓶颈，而且在CPU平台没有Occlusion Culling。 因此需要GPU Driven Rendering, 在GDR下，将可见性测试移动到GPU上，而且GPU上可以直接使用Culling之后的结果，可以直接在GPU上进行Batch，将不同mesh的不同instance merge到一起。在GPU端可以感知整个scene的状态（而不只是知...

【GDC 2016】Optimizing the Graphics Pipeline with Compute这篇文章是寒霜引擎在GDC2016上的分享，主要介绍了他们的GPU Driven的思路，与上一篇育碧的内容有部分相似之处，接下来详细介绍下。 在DX12的新API上可以支持海量的DrawCall，极大的提高了CPU的性能，带来CPU的low overhead，但是GPU端仍然会卡在tiny draw call上，主要是因为场景中远处的细小细节的物体会被Hi-Z Cull,从GPU性能分析图中可以看到后半段，大部分只有VS计算，而没有PS计算，这样就会导致VS和PS的分配不均，造成性能的浪费。 大部分的引擎在CPU端最粗粒度的culling，然后在GPU上做refine，由于CPU和GPU之间存在延迟，因此很多这类的优化并不合适，因为需要二者严格的同步执行。在主机上CPU的资源本来就有限，因此让一个核心来做这个事情的性价比并不高。在PC端由于需要通过PCIE总线进行数据传输，这种方式的代价会更高。因此，希望剔除操作能够适配GPU的执行节奏，所以采用的方案是基于GPGP...

GPU Driven Rendering(GPU驱动渲染)是一种现代实时的渲染架构，其核心思想是将渲染流程的控制权从CPU转移到GPU，把原本在CPU上执行的关键任务（如几何裁剪，视锥剔除，遮挡剔除，DrawCall的生成）转移到GPU端，让GPU使用Compute Shader或Mesh Shader来完成，让GPU自主决定渲染哪些内容以及如何进行渲染，从而大幅减少CPU与GPU之间的数据传输和交互开销，充分发挥现代GPU的并行计算能力。 【SIGGRAPH 2015】GPU-Driven Rendering Pipelines 上图为《刺客信条大革命》游戏中育碧提出的GPU Driven Rendering Pipeline,其中蓝色部分为CPU侧的工作内容，而红色部分为GPU侧的工作内容。 Coarse Frustum Culling 这个步骤主要是CPU端进行Instance的Culling，场景会被组织成为四叉树，八叉树或者BVH，然后可以利用这些加速结构对场景中的Instance进行快速的剔除，同时在CPU端对每个Instance的数据根据LOD,Material等...

最近在对支持的项目组进行性能优化工作，其中遇到的大量动画角色同屏渲染的问题，经过一些调研和实践，正好就大量动画渲染性能优化技术进行一些讨论。 骨骼模型由骨骼数据加骨骼动画进行驱动，每一帧动画系统会计算出当前帧的骨骼的变换矩阵，然后通过蒙皮的方式来计算每一个顶点的实时位置，最后渲染系统会根据蒙皮之后的顶点数据进行渲染。具体蒙皮的计算方法，不同的蒙皮技术会有不同的时机和实现方式。 CPU SkinCPU蒙皮指在CPU端先计算好每个顶点的蒙皮位置，然后再将顶点数据发送到GPU端进行渲染，GPU端的顶点buffer里保存的是蒙皮后的顶点数据。我们知道CPU是擅长逻辑控制而不善于大量运算的，因此CPU蒙皮会严重的影响CPU性能，特别是场景中存在大量动画模型的时候，CPU基本会被动画更新，蒙皮计算和数据传输所占满，甚至会无法运行。 GPU Skin骨骼蒙皮会逐顶点进行计算，在顶点数量比较多的时候，总的运算量是非常大的，但是我们注意到，每个顶点的计算是相互独立的，也就是说他们是并行的。这种大量的并行计算，那天然就适合在GPU端进行。这种在GPU端进行蒙皮计算的就叫做GPU蒙皮。 VS Skin...

前两章主要介绍了GPU的渲染管线和硬件架构，本文针对GPU的性能优化做一些简单的讨论。 DrawCall对于性能的影响GPU是工作在内核空间的，应用层跟GPU打交道是通过图形API和GPU的驱动来完成的，驱动的调用会有一个用户空间到内核空间的转换。以DX为例，用户程序在CPU端提交一个DrawCall, 数据的流程是：APP > DX runtime > User mode driver > Dxgknl > Kernel mode driver > GPU，经过这一连串的调用，才能到达GPU，所有GPU之前的这些流程都是在GPU端执行的。所以DrawCall数量增加，增加的往往是CPU端的时间开销。这也就是为什么最新的现代图形API，如DX12，Vulkan等，都会将驱动层做薄的原因。而主机平台因为有特殊的驱动优化，因此CPU和GPU的交互性能开销是很低的，游戏性能也就更强。 DrawCall命令的开销并不是单纯的绘制命令本身，而在于DrawCall绑定的数据（Shader，Buffer,Texture）和渲染状态（Render State）设置的...

上篇文章介绍了GPU的渲染管线，这是从渲染的流程层面介绍了GPU渲染的过程，本文的内容深入到GPU的硬件架构，从硬件层面介绍GPU的组成和工作原理。参考文献有多篇非常深入详细的文章，值得学习。 什么是GPU？GPU的全称是Graphics Processing Unit,图形处理单元。最初的GPU是专门用于绘制图形图像和处理图元数据的特定芯片。 如上图所示，展示了GPU和CPU的硬件差异： CPU的核心数量少，每个核心都有控制单元，内存设计上是大缓存，低延迟。CPU擅长分支控制和逻辑运算，而不适合海量的数据计算。 GPU则计算单元非常多，多个计算单元共享一个控制单元。内存设计上是追求高带宽，可以接受高延迟。GPU适合海量的数据并发计算的场景。 桌面GPU 物理架构GPU的微观结构因不同厂商，不同架构都会有所差异，但是核心的部件，概念以及运行机制大同小异，桌面级的GPU产商有NVIDIA，AMD，移动端的GPU包括PowerVR，Mali和Andreno。以NVIDIA的桌面级GPU为例，历代的GPU包括Tesla，Fermi, Maxwell，Kepler和Turing架构。...

纹理压缩技术游戏中重要且常用的技术，最近在做纹理压缩相关的工作，正好深入的学习下纹理压缩技术的底层原理。关于纹理压缩技术有一篇非常全面的综述论文《TEXTURE COMPRESSION TECHNIQUES》, 对应有一篇中文的翻译文章。本文是上述文章的学习总结。 纹理压缩背景游戏中使用纹理是把二维图像映射到三维表面，图像中单个像素叫做Texel。游戏中使用的贴图不仅可以存储颜色，还可以存储法线，高度等信息,贴图需要占用大量的内存，游戏中超过一半的内存被纹理占用，而且纹理大小也会对带宽造成影响，直接影响耗电，因此需要使用纹理压缩，对内存，带宽和耗电同时进行优化，尤其在移动端设备上尤为重要。 通常情况下纹理是一张二维的图像，但是传统的压缩算法（RLE,LZW等）却和流行的贴图压缩格式（JEPG,PNG等）并不适合纹理压缩，主要原因是贴图需要随机访问Texel，即只需要访问用到的纹理部分。而传统的图片压缩是需要针对整个纹理进行解压的。 因此大多数的压缩方案都会将原始的图片分割为固定大小的块，称做Tile,然后针对每个Tile进行独立的压缩。在评估一个纹理压缩方案的时候主要考虑以下几...

使用一个东西，却不明白它的道理，并不高明. 做图形学最重要的就是跟GPU打交道，利用GPU来实现各种效果。但是之前一直只停留在比较上层的使用上，对于GPU的底层和硬件架构知之甚少。借用侯捷老师的一句话“使用一个东西，却不明白它的道理，并不高明”。于是便花了些时间深入学习了GPU的相关知识，做些记录。 腾讯技术工程的官方号上有一篇详细介绍GPU的文章：《GPU 渲染管线和硬件架构浅谈》,总结的非常全面，反复看了好多遍，也是本篇文章的主要参考资料。知乎平台上讲解NVIDIA GPU架构的系列文章非常详细的介绍了各代架构的GPU及其硬件架构，非常值得一读。 RTR4开篇第一二章的内容就是介绍的GPU硬件架构和渲染管线，这里我们也按照这个顺序： 第一篇将主要介绍图形学中的GPU渲染管线，包括桌面端和移动端； 第二章主要介绍GPU的硬件架构； 第三章主要介绍GPU编程和优化方法相关。 GPU渲染管线所谓的GPU渲染管线，就是有一堆的模型数据（点，线，三角形等），经过GPU端的一系列的流水线处理，最终得到屏幕上的二维图像的流程。跟工业生产的流水线一样，GPU的管线各个部分也是并行处理...