企业官网建设流程全解析

如果你已经开始接触UE5一段时间，那“Compute Shader”这个词大概率没少听。Lumen、Nanite、Virtual Texture这些UE5的招牌功能，背后全离不开Compute Shader在GPU上做通用计算。说白了，它就是一段跑在GPU上的程序，不负责画三角形，而是处理“同一套逻辑要执行成千上万次”的场景：粒子位置更新、布料模拟、大规模Culling、后处理降噪，全都能用CS来做。这篇文章不是什么官方文档复述，而是我自己在项目里从0搭起一个可用CS链路、再到和RenderGraph深度集成的实战总结。适合有C++基础、却还没跨过“UE5里到底怎么写CS、怎么调度、怎么调试”这道坎的引擎开发者。

我会从并行模型讲起，到写.usf文件、注册GlobalShader、用RDG调度，再到Buffer读写、异步计算、性能Debug，最后附上我踩过的一堆坑。全文会给完整代码和可直接抄的命令行，能省下你大量翻源码的时间。

1. 先搞清楚：Compute Shader在UE5里到底是什么

1.1 用“工厂流水线”理解GPU并行模型

在开始写代码前，我一定要先说清楚计算模型，否则后面看hlsl代码会一头雾水。GPU最擅长的不是“一个超大循环”，而是“成千上万个独立小任务齐头并进”。你可以把GPU想象成一家超级工厂：Compute Shader不是一条流水线，而是同时开放几千条流水线，每条流水线都执行同一份操作手册。

这份操作手册就是你的Shader函数。所有流水线工人（线程）同时执行同一套逻辑，但手里拿到的料（线程ID）不一样，于是每个人处理的是不同数据。这就是“单指令多数据”（SIMT）的直觉理解。

在HLSL里，一个Compute Shader通过numthreads声明每个线程组里有多少线程。比如：

[numthreads(64, 1, 1)] void MainCS(uint3 DTid : SV_DispatchThreadID) { }

这句话表示：每个线程组有64个线程，它们会在一台GPU计算单元上调度。你能启动多个线程组，线程组总数由CPU侧的Dispatch调用决定。假设你要处理一万个数据点，每个线程组处理64个，那么需要ceil(10000 / 64) = 157个线程组。最后多出来的线程只需要在Shader内部做边界判断，比如：

if (DTid.x >= NumValues) { return; }

这个边界判断几乎是所有Compute Shader的标准开头，因为CPU侧Dispatch的线程组数往往不是数据长度的整数倍。

1.2 为什么UE5的现代化渲染离不开Compute Shader

很多刚入门的同学有疑问：以前没有Compute Shader，游戏不也照样跑？原因很简单：早期GPU架构里通用计算能力弱，很多逻辑不适合放到Vertex/Pixel Shader里，也没法在Draw Call之间灵活传递中间数据。随着GPU硬件迭代，通用计算单元越来越强，引擎开始把大量非光栅化工作搬进GPU。

UE5里最典型的就是Lumen。Lumen不是靠纯光追硬刚，而是用一系列Compute Shader做屏幕追踪、世界空间Radiance Cache更新、降噪和插值。你可以把每一个步骤理解成一个CS：输入上一帧的辐照度缓存、几何距离场等数据，输出当前帧的光照探针结果。Nanite也一样，大量Cluster的裁剪、排序、光栅化前的binning都依赖CS在每帧Gather数据并生成绘制指令。没有Compute Shader，这些系统只能退回CPU，性能会直接崩掉。

现在你在UE5里打开一个空白关卡，什么都不做，用ProfileGPU看一帧，仍能看到很多CS Pass，例如LumenRadianceCacheUpdate、VirtualTextureUpdate。它们就在每一个你看到的画面背后默默跑着。

2. 写Compute Shader前必须知道的几个概念

2.1 线程组、Dispatch与ID语义

我不建议一上来就写UE5封装，而是先彻底搞懂几个HLSL语义。在CS中最常用到四个ID：

这里最常用的就是SV_DispatchThreadID。假设你的线程组是[numthreads(64, 1, 1)]，Dispatch了(4, 1, 1)个线程组，那么全局线程ID范围是0到255，正好可以覆盖256个数据点。如果要处理2D纹理，通常用[numthreads(8, 8, 1)]，SV_DispatchThreadID.xy就能直接映射到像素坐标。

注意一个特别容易错的地方：SV_DispatchThreadID不等于线性数组索引的绝对位置。因为它是一个三维向量，不同维度的Dispatch会改变它的含义。如果你用1D Buffer，建议统一使用[numthreads(64,1,1)]并只读取.x，我见过不少新手把DispatchThreadID.z当成第三个数据维度导致越界的坑。

2.2 UE5的GlobalShader机制：usf文件和C++类的绑定

在UE5里写Compute Shader，你至少需要两个文件：一个.usf（Unreal Shader File）负责GPU端真正的HLSL逻辑，一个C++类负责声明Shader的参数和入口点。

.usf文件一般放在项目的Shaders文件夹下，注意不是Content文件夹，而是在工程根目录创建Shaders目录。如果你的项目名为MyProject，那么路径就是MyProject/Shaders/MyComputeShader.usf。UE5的Shader编译系统会扫描这个目录。

C++端则要用到FGlobalShader。一个最简单的GlobalShader声明长这样：

// MyComputeShader.h #pragma once #include "GlobalShader.h" #include "RenderGraphUtils.h" class FMyComputeShader : public FGlobalShader { public: DECLARE_GLOBAL_SHADER(FMyComputeShader); SHADER_USE_PARAMETER_STRUCT(FMyComputeShader, FGlobalShader); // 这里定义所有要在HLSL里用到的参数 BEGIN_SHADER_PARAMETER_STRUCT(FParameters, ) SHADER_PARAMETER(uint32, NumValues) SHADER_PARAMETER_RDG_BUFFER_UAV(RWStructuredBuffer<float>, OutputBuffer) END_SHADER_PARAMETER_STRUCT() static bool ShouldCompilePermutation(const FGlobalShaderPermutationParameters& Parameters) { return true; } };

.cpp文件里再声明实现：

// MyComputeShader.cpp #include "MyComputeShader.h" IMPLEMENT_GLOBAL_SHADER(FMyComputeShader, "/MyProject/MyComputeShader.usf", "MainCS", SF_Compute);

这里IMPLEMENT_GLOBAL_SHADER三个参数分别是C++类名、usf文件路径、入口函数名MainCS、Shader频率SF_Compute。只要这三个对得上，引擎编译时就会把C++参数结构体和HLSL里的变量绑定起来。

2.3 参数绑定的“暗号”机制

熟悉材质系统的同学应该知道，UE的Shader参数绑定不是靠字符串去“找”变量，而是通过BEGIN_SHADER_PARAMETER_STRUCT这些宏生成一份布局表，然后交给RHI去和HLSL反射信息做匹配。因此C++宏里的名字要尽可能和HLSL里的变量名一致，但不要求完全一样。

比较麻烦的是Name冲突：如果C++结构体里叫OutputBuffer，HLSL里也写RWStructuredBuffer<float> OutputBuffer;，最省心。一旦你改名，Bug排查会非常痛苦，因为编译错误往往只在日志里出现一条淡淡的bind failed。

SHADER_PARAMETER_RDG_BUFFER_UAV这个宏表示这个参数是一个RDG托管Buffer的UAV（Unordered Access View）。为什么强调RDG？因为UE5的渲染图系统负责资源的生命周期，你不应该直接分配一个FRHIUnorderedAccessView然后胡乱传递，而是通过FRDGBuilder分配和引用，这样引擎能在Pass之间自动插入Barrier并做资源复用。后面会细说。

3. 实战：从零搭建一个最简Compute Shader

3.1 先写一个能跑的.usf

这一步的任务是：写一个CS，把输Buffer里的每个元素设置成它自己的线程ID除以1000。听起来没用，但它能完整验证从CPU到GPU再到输出的链路，是排查管线问题的基准测试。

在项目根目录Shaders下新建MyComputeShader.usf：

// MyComputeShader.usf #include "/Engine/Public/Platform.ush" RWStructuredBuffer<float> OutputBuffer; uint NumValues; [numthreads(64, 1, 1)] void MainCS(uint3 DTid : SV_DispatchThreadID) { if (DTid.x < NumValues) { OutputBuffer[DTid.x] = float(DTid.x) / 1000.0f; } }

这段代码里#include "/Engine/Public/Platform.ush"是强制建议的，它能引入平台相关的宏和基础类型定义。RWStructuredBuffer<float>是可以读写的结构缓冲，既不是纹理也不是Buffer<float>，更适合通用计算。NumValues是CPU传进来的数据长度。

注意一个细节：我在判断里写的是DTid.x < NumValues，而不是直接无脑写。Dispatch的线程组数是向上取整的，如果不判断，最后一组超出数据范围的线程会写坏内存，而且这种错误在Release下极难排查，因为内存越界可能不会立刻崩溃。

3.2 创建C++Shader类

先在项目中新建一个C++类，然后写入以下头文件内容。

我习惯把Shader类和调度逻辑分开。只负责声明Shader类的头文件：

// MyComputeShader.h #pragma once #include "CoreMinimal.h" #include "GlobalShader.h" #include "RenderGraphUtils.h" #include "ShaderParameterStruct.h" class FMyComputeShader : public FGlobalShader { public: DECLARE_GLOBAL_SHADER(FMyComputeShader); SHADER_USE_PARAMETER_STRUCT(FMyComputeShader, FGlobalShader); BEGIN_SHADER_PARAMETER_STRUCT(FParameters, ) SHADER_PARAMETER(uint32, NumValues) SHADER_PARAMETER_RDG_BUFFER_UAV(RWStructuredBuffer<float>, OutputBuffer) END_SHADER_PARAMETER_STRUCT() static bool ShouldCompilePermutation(const FGlobalShaderPermutationParameters& Parameters) { return true; } };

对应cpp：

// MyComputeShader.cpp #include "MyComputeShader.h" IMPLEMENT_GLOBAL_SHADER(FMyComputeShader, "/MyProject/MyComputeShader.usf", "MainCS", SF_Compute);

如果你的项目没有正常扫描到Shaders目录，编译时会出现找不到MyComputeShader.usf的报错，或者运行时控制台输出类似Error: unable to load shader的日志。此时先检查一下项目名/Shaders目录是否存在，以及是否在工程设置里开启了Shader开发模式。DefaultEngine.ini里加上这句可避免很多麻烦：

[ShaderCompiler] bAllowCompilingThroughWorkers=True

3.3 用RenderGraph把CS丢进渲染流程

UE5里调度CS最现代的方式是FRDGBuilder配合AddPass。你不需要手动创建RHI资源，只需要用GraphBuilder.CreateBuffer创建Buffer，再通过参数结构传给CS。

下面给一个在游戏线程里触发RenderThread执行的简化封装。这个函数可以放在你的UObject或者AActor组件里，关键是用ENQUEUE_RENDER_COMMAND把渲染线程要执行的Lambda压进队列：

#include "RenderGraphBuilder.h" #include "RenderGraphUtils.h" #include "ShaderParameterStruct.h" void DispatchMyComputeShader(FRHICommandListImmediate& RHICmdList) { FRDGBuilder GraphBuilder(RHICmdList); // 1. 创建一个足够容纳1024个float的Buffer const int32 NumValues = 1024; FRDGBufferRef OutputBuffer = GraphBuilder.CreateBuffer( FRDGBufferDesc::CreateStructuredDesc(sizeof(float), NumValues), TEXT("MyOutputBuffer")); // 2. 填充Shader参数 FMyComputeShader::FParameters* Parameters = GraphBuilder.AllocParameters<FMyComputeShader::FParameters>(); Parameters->NumValues = NumValues; Parameters->OutputBuffer = GraphBuilder.CreateUAV(OutputBuffer); // 3. 添加Compute Pass auto GroupCount = FIntVector(FMath::DivideAndRoundUp(NumValues, 64), 1, 1); GraphBuilder.AddPass( RDG_EVENT_NAME("MyComputeShader_Dispatch"), Parameters, ERDGPassFlags::Compute, [Parameters, GroupCount](FRHIComputeCommandList& RHICmdList) { FMyComputeShader::FPermutationDomain PermutationVector; TShaderMapRef<FMyComputeShader> ComputeShader(GetGlobalShaderMap(GMaxRHIFeatureLevel), PermutationVector); FComputeShaderUtils::Dispatch(RHICmdList, ComputeShader, *Parameters, GroupCount); }); GraphBuilder.Execute(); }

这个代码里最关键的是FComputeShaderUtils::Dispatch。它会根据Shader的numthreads自动算出需要Dispatch多少线程组、设置UAV和常量参数，并最终调用RHI的DispatchComputeShader。

调用方式很简单——在游戏线程的某个函数里：

ENQUEUE_RENDER_COMMAND(MyComputeDispatch)( [](FRHICommandListImmediate& RHICmdList) { DispatchMyComputeShader(RHICmdList); });

如果你在游戏线程里直接调这个函数，会碰上UE的渲染线程检查崩溃。绝大多数渲染操作必须在渲染线程执行，所以这个ENQUEUE_RENDER_COMMAND封装必不可少。

3.4 怎么确认结果对不对

你第一次跑CS时，如果控制台没报错、游戏也没崩，一定不要默认它就工作了。我见过太多这种情况：其实Shader一直在跑，但Draw结果全黑。验证方式有很多种，初期我推荐用GraphBuilder.CreateShaderResourceView读回CPU，然后打日志。

实际做法是在同一帧、同一GraphBuilder里加一个CopyToResolveTarget或ReadbackBuffer。更简单的是用FRHIGPUBufferReadback在异步读回Buffer内容，然后在主线程打印。

FRHIGPUBufferReadback ReadbackBuffer(TEXT("MyOutputReadback")); ReadbackBuffer.EnqueueCopy(RHICmdList, OutputBuffer->GetRHI(), sizeof(float) * NumValues); // 一段时间后调用： float* Data = (float*)ReadbackBuffer.Lock(sizeof(float) * NumValues); for (int32 i = 0; i < 8; i++) { UE_LOG(LogTemp, Log, TEXT("CS Output[%d] = %f"), i, Data[i]); } ReadbackBuffer.Unlock();

一旦看到输出一串递增的0.000、0.001、0.002，说明整个管线已经打通。到这一步，你已经具备在UE5里写任意CS的基础能力了。

4. 数据交互：Buffer的读写与CPU数据来回

4.1 StructuredBuffer和RWStructuredBuffer的选择

在CS实战里，RWStructuredBuffer是最常用的结构。只要CPU侧把一份结构体数组上传进GPU，你就拥有了在GPU上任意读写复杂数据的能力。和Buffer<float>相比，RWStructuredBuffer不要求元素大小固定为4个字节的倍数，可以放自定义结构体：

struct FParticleData { float3 Position; float Velocity; float4 Color; }; RWStructuredBuffer<FParticleData> Particles;

C++侧声明UAV参数时，仍然用SHADER_PARAMETER_RDG_BUFFER_UAV(RWStructuredBuffer<float>, OutputBuffer)这种写法，但HLSL里的类型可以换成你的结构体。引擎不会强制C++宏里的HLSL类型必须一致，它主要检查的是“在RDG里这是一个Buffer UAV”，而HLSL端用什么类型解释这份内存完全由你自己决定。

关于StructuredBuffer和RWStructuredBuffer的区别，一句话：前者只读，后者读写。如果某个Buffer只做输入，一定使用StructuredBuffer而不是RWStructuredBuffer，因为只读Buffer在GPU驱动层可以被缓存和优化，甚至能走只读纹理路径。性能差距在某些平台可以达到一倍以上。很多导入项目的老Shader喜欢所有地方都用RW，后来能优化的地方全是iCache命中率低。

4.2 从CPU上传数据到GPU

在RDG里，如果你先在CPU侧准备了一个TArray<float>，可以使用FRDGBufferInitialData来初始化Buffer：

TArray<float> InitialData; InitialData.SetNum(NumValues); for (int32 i = 0; i < NumValues; i++) { InitialData[i] = static_cast<float>(i); } FRDGBufferRef InputBuffer = GraphBuilder.CreateBuffer( FRDGBufferDesc::CreateStructuredDesc(sizeof(float), NumValues), TEXT("InputBuffer"), FRDGBufferInitialData::MakeUint32((uint32*)InitialData.GetData(), NumValues * sizeof(float)));

这种一次性初始化适合静态数据。如果你的数据每一帧都在变，就不适合反复用MakeUint32初始化了，更合理的方案是把上传Buffer放到单独的Upload Pass里，或者用FRHIGPUBufferReadback的反向操作EnqueueCopy从CPU写一份到Staging Buffer再由RHI拷贝。

实际项目中，最稳的做法是提前创建一块StructuredBuffer作为“动态上传区”，每帧更新时调用GraphBuilder.QueueBufferUpload。这个方法内部会处理内存复用和帧同步，避免每帧都申请RHI资源。

4.3 从GPU读回结果的正确姿势

GPU读回CPU是非常昂贵的操作，因为GPU执行和CPU执行是异步的，你无法保证上一帧的数据已经写完。强行Lock结果Buffer会导致管线停顿（Stall）。因此读回数据一定要用Readback机制，也就是我前面写的FRHIGPUBufferReadback。它内部会创建一块暂存Buffer，并在GPU完成写操作后同步给CPU。

一个常见错误是：在同一个Lambda里既Dispatch CS又立刻Readback并读数据。这在DX12/RHI层往往不会直接报错，但会出现“读回的数据是上一帧旧数据”或“整个帧率掉到个位数”的问题。正确流程是要隔几帧去读。你可以把Readback对象保存为成员变量，然后等到下一帧再Lock。

针对出错的排查，我建议在开发模式下先用最笨的验证方式：把CS输出结果再通过CopyTexture写到RenderTarget，然后截屏。虽然不优雅，但能快速确认Bug是发生在Shader逻辑里，还是发生在CPU读回环节。

4.4 间接调度与GPU Driven的初体验

当你真正开始做粒子系统或大场景Culling时，会发现一个需求：某些输入条件决定了要处理多少个元素。比如一个GPU裁剪系统，裁剪完只有300个三角形需要绘制，但全场景有100万个三角形。如果你在CPU侧Dispatch，就必须以100万为基准分配线程组，浪费大量GPU时间。

这时用RWStructuredBuffer作为参数缓冲（Buffer /RWBuffer<uint>），HLSL里写入实际需要的DispatchThread数量，然后使用DispatchIndirect（对应RHI层的DispatchIndirectShader）就能让GPU根据Buffer里的Count动态决定启动多少线程组。

在UE5的RDG中，间接调度参数放在参数宏：

SHADER_PARAMETER_RDG_BUFFER_UAV(RWBuffer<uint>, DispatchIndirectBuffer) SHADER_PARAMETER_RDG_BUFFER_SRV(Buffer<uint>, IndirectArgs)

对应的.usf：

[numthreads(64, 1, 1)] void CullingMainCS(uint3 DTid : SV_DispatchThreadID) { ... if (应被绘制) { InterlockedAdd(DispatchIndirectBuffer[0], 1); } }

然后是Dispatch阶段用RWBuffer里的值决定线程组数兜底。这样就能实现典型的GPU Driven管线：上一道CS输出本道CS应该启动多少线程，管线在GPU上闭环，不再每帧同步回CPU。这也是Nanite能够在GPU上处理海量三角形的原因之一。不过要注意DispatchIndirect带来的依赖：必须确保写计数的CS完整执行完，调度CS才能执行。RDG会分析UAV依赖自动插入Barrier，但在开发者手动复用Buffer时要特别小心。

5. 高级集成：RDG、异步计算与材质编辑器的边界

5.1 理解RDG的资源生命周期

在UE5.0以前，很多团队写渲染代码还在用BeginRenderTargetPass，手动管理FRHITexture和FRHIUnorderedAccessView，传参依赖SetShaderParameters。这种做法的痛点是：GPU资源之间的同步、屏障（Barrier）和生命周期都需要开发者自己负责。稍微改错一个依赖顺序，就可能出现黑屏、花屏或莫名其妙的性能滑坡。

UE5把Render Graph（RDG）正式扶正，核心思想是：你在一帧开始时声明需要的所有资源，然后描述每个Pass读写哪些资源。引擎会分析Pass之间的资源依赖，自动在UAV之间插入屏障，并在物理资源池中复用临时资源。对于多Pass的CS链路，这是巨大的解放。

以我前面的代码为例，GraphBuilder.CreateBuffer创建的Buffer，在GraphBuilder.Execute()之前并不会真正分配物理内存。RDG要通过Pass的引用关系确定Buffer是否被使用，以及使用的先后顺序。所以你在调试时看到的“Buffer分配失败”或“资源未创建”，多半是在Pass外部使用了没有被任何Pass引用的Buffer。

Debug RDG最直接的命令：

r.RDG.Debug=1 r.RDG.DumpGraph=1

开启后，引擎会把整帧的资源依赖图和Pass顺序输出到日志甚至GraphViz格式。这对排查Pass执行顺序错误非常有帮助。如果你看到某个Pass被引擎放在了不期望的位置，多半是资源引用不对，引擎为了满足依赖自动重排了。

5.2 异步计算：让CS和图形Pass叠起来跑

异步计算（Async Compute）是很多开发者趋之若鹜的性能优化手段。其原理是GPU内部有独立的异步计算队列，能把Compute工作与图形工作并行执行——图形Pass在等待光栅化时，计算队列可以偷偷跑纹理压缩、粒子更新这类不需要深度缓冲的工作。

在RDG里启用异步计算非常简单，只需给AddPass传入ERDGPassFlags::AsyncCompute：

GraphBuilder.AddPass( RDG_EVENT_NAME("MyAsyncComputePass"), Parameters, ERDGPassFlags::AsyncCompute, [Parameters, GroupCount](FRHIComputeCommandList& RHICmdList) { FComputeShaderUtils::Dispatch(RHICmdList, ComputeShader, *Parameters, GroupCount); });

但我想郑重提醒：异步计算不是银弹。它需要GPU硬件和驱动支持，而且如果CS和图形Pass之间存在资源依赖（比如CS改写了接下来图形Pass要读取的Buffer），异步计算反而会被强制同步，把原本想省的时间全部赔进去。

我实测的经验是：通常只有“既没有依赖紧密的图形资源，又比较耗时”的后处理类CS，比如大型降噪、模糊、GPU粒子更新，才适合异步计算。而跟光照、阴影Pass紧耦合的中间步骤，别轻易标记成AsyncCompute。开启后建议用ProfileGPU看一段时间，如果GPU时间没下降反而上升，立刻关掉。

5.3 材质编辑器能取代Compute Shader吗

这个问题几乎每个月都有人问。答案很明确：材质编辑器里的Custom节点不能完全代替Compute Shader。Custom节点本质上是把一个自定义HLSL片段插入Pixel或Vertex Shader中，它不具备自主调度线程组的能力，也无法直接声明RWStructuredBuffer和跨线程通信。

但也不是完全没戏。如果你只想做一些轻量级的“逐像素计算”，比如把一张纹理做简单的公式变换，用Material的Custom节点配合SceneTexture和Opacity完全可行。这种方式优点是所见即所得，不用写C++渲染代码。不过一旦算法需要多Pass、需要共享中间数据、需要做规约，复杂度上升后材质编辑器就会痛苦万分。我通常的建议是：算法原型可以用材质Custom节点快速验证思路，真正落地到产品时迁到Compute Shader，效率和扩展性完全不同。

5.4 从CS视角看Lumen和Nanite

Lumen和Nanite是UE5时代最值得学习的两个系统。它们都不属于“必须具备的常规功能”，却能帮你理解CS在真实高性能场景下如何组合成完整管线。

Lumen的Screen Probe生成的Radiance Cache数据，依靠一批CS做密度估计、加权平均、法线锥体（Cone）滤波。它会维护一张世界空间光照探针图，每一帧都有多个Pass往同张图里累积写入。这些Pass之间的数据依赖极强，正是RDG资源分析器发挥威力的地方：每个Pass只声明自己写了哪些区块，引擎保证前序Pass完成后再执行后续Pass。

Nanite的Cluster裁剪是另一个经典示例。它先把Mesh切成很多个Cluster，再由CS判断每个Cluster在屏幕上的投影是否足够大、是否在视椎体内，将结果写进一个紧凑的索引Buffer。之后再用DispatchIndirect启动光栅化Pass。这里如果没有Indirect Dispatch，GPU就无法避免“把所有Cluster全画一边”的巨大浪费。

对一个普通开发者来说，你不需要完全读懂Lumen和Nanite源码，但如果你能独立实现一个基于CS的大规模粒子裁剪系统，回看引擎源码里的那些Pass名称和Resource引用，会有一种“这段代码我好像也能写”的感觉。

6. 性能调优与Debug：别只盯着游戏FPS

6.1 用ProfileGPU和命令行看清每道Pass的开销

刚开始调CS性能，最忌讳的是肉眼观察帧率。CS的代价有时非常隐蔽：虽然百分比不高，但它可能引发管线Stall。正确做法是打开ProfileGPU：

Ctrl+Shift+,

或者在控制台输入ProfileGPU。UE会弹出一整帧所有Pass的GPU时间统计。针对Compute，聚焦看这些字段：

• RDG下所有以CS结尾的Pass，例如MyComputeShader_Dispatch
• LumenRadianceCacheUpdate、VirtualTextureUpdate等系统级CS
• GpuSkinCacheUpdate这类动画更新

如果你看到某个CS Pass占用了超过预期的时间，下一步是在它上下各找一个Pass，对比它们的顺序和耗时。如果CS旁边的图形Pass时间暴增，很可能出现了Barrier冲突。

另外一个用的非常多的参数是r.GPUStatsEnabled=1，它能在游戏视口顶部显示每帧GPU各子模块的时间占比。但注意不要在发布版本里开着它，因为有额外开销。

6.2 影响Compute Shader性能的几个关键要素

我把经验浓缩成三个词：Occupancy、内存布局、分支。

Occupancy就是GPU上同时活跃的线程组数量。关于numthreads取值，常用64、128、256。不是越多越好。因为每个线程组占用一定数量的寄存器和共享内存，线程组太多会导致某些块的资源不够，反而降低Occupancy。一般来说，如果Shader逻辑简单、只用几个参数，numthreads(64,1,1)很容易把Occupancy跑满；如果Shader用到了大量中间变量和groupshared，可以考虑适当的减少到32, 1, 1分高占用率。

内存布局影响Bandwidth。一个常见问题是用AoS（Array of Structure）还是SoA（Structure of Array）。比如你有一个粒子系统，每个粒子有位置、速度、颜色三个属性。用AoS的结构体数组在GPU上访问时，同一线程组内相邻线程如果连续读写同一结构体，内存访问效率尚可；但如果你做的是颜色分量全局规约，AoS就会被迫把整块数据读进来再剔除，浪费带宽。改成三个独立StructuredBuffer分别存Position、Velocity、Color，反而更快。这就是SoA性能优势。

分支开销在GPU上和CPU不一样。CPU的分支预测失效代价高，GPU的分支则取决于线程组内的分叉程度。同一个线程组里的线程如果走到不同分支，编译器通常会两端都执行再Mask。因此，尽量把“需要条件跳转”的判断放到线程组入口统一处理，而不是让每个线程在循环里做随机分支。用if (DTid.x >= NumValues) return;这种提前退出是廉价的，因为它在循环入口处整组一致，不会产生太多Divergence。

6.3 渲染内存不足和CS的微妙关系

热搜词里有一个“ue5渲染内存不足”，很多团队第一反应是纹理太大、Mesh太多，却忽略了CS也可能制造隐患。CS本身不渲染三角形，但它可能创建巨大的中间Buffer。尤其是RWStructuredBuffer和AppendBuffer，如果元素数量估算错了，一次分配几百MB也不奇怪。

排查思路很简单：先开-stat memory或者MemoryProfiler2看渲染资源占比，再用rhi.DumpTransientResources=1导出瞬时资源列表。如果大量内存集中在某个CS的临时Buffer，就要考虑是不是每帧都新建了Buffer而没有释放，或者图Size过大。

RDG通常会在资源使用完后放进池子复用，但如果你在RDG之外手动持有了RHI资源并且忘记释放，内存就会一直涨。我见过一个案例：项目在每一帧都创建一个新的Compute Buffer做中间结果，却忘了在帧末释放，结果内存以每秒几十MB的速度增长，三分钟后游戏就OOM了。排查出来的线索就是Buffer尺寸恰好等于每帧Dispatch的数据量，且RHI Resource数量线性增长。

7. 踩坑记录：我从UE5 Compute Shader里学到的教训

7.1 Shader编译失败但引擎不报错

这种现象非常坑：控制台没有编译错误，但输出的画面不对，或者Pass根本没有执行。我遇到过好几次，原因基本指向同一点——.usf文件路径写错，或者IMPLEMENT_GLOBAL_SHADER里的路径与实际路径不匹配。这种情况下引擎通常会把Shader编译失败当成一个可恢复错误静默处理，表现为Pass不执行或输出无效。

遇到这种情况，先用命令行：

r.ShaderCompiler.DumpStats=1 r.ShaderCompiler.DebugDump=1

再把编译日志路径里的.ush和.ush文件翻出来，直接看你Shader文件有没有出现在编译命令里。如果根本没出现，多半是路径问题。

7.2 HLSL结构体对齐和显存布局问题

很多从Unity转过来的同学习惯在C++结构体里写float3然后直接上传给GPU，这在UE里偶尔没问题，但跨平台容易踩坑。HLSL的float3在常量缓冲中默认4个float对齐，也就是说一个float3成员后面会多出4个字节的Padding。如果你用C++的FVector3f去填，大小只有12字节，两张结构体之间可能错位。

稳妥的做法有两种：尽量把所有成员都声明成float4/uint4这种16字节对齐的形式，或者给HLSL里的float3后面补一个float _Pad0;。在C++侧也建议用FVector4f而不是FVector3f来保证字节对齐。

如果你在UAV中传自定义结构体，这个对齐问题更隐蔽。因为StructuredBuffer不像常量缓冲那么严格要求16字节步幅，但驱动对内存访问的优化逻辑仍然受对齐影响。跨平台（尤其移动端）时建议统一按16字节对齐来布局。

7.3 线程组上限和Dispatch越界

DX11和DX12的Dispatch线程组上限很大，但某些移动端/主机平台会低一些。另一个更容易踩的是：某些硬件或驱动对numthreads一维数量有限制，比如不能超过256。如果你的逻辑需要每线程组处理512个元素，不要写[numthreads(512,1,1)]，改用[numthreads(128,1,1)]然后内部循环4次。

Dispatch越界问题也很常见。比如你的数据长度不是64的倍数，用DiviveAndRoundUp后确实能覆盖所有数据，但Shader里必须有边界判断。一旦缺少，RenderDoc会看到明显的越界写，但游戏可能依然正常运行，直到某帧数据结构被写坏才爆发。

7.4 平台差异比想象中大

在Windows上跑得好好的CS，到了主机或者移动端可能完全跑不起来，或者性能天差地别。常见差异点包括：WaveSize（Wave32还是Wave64）、GroupMemoryBarrierWithGroupSync的实现开销、以及RWStructuredBuffer在移动端的支持程度。移动端有些GPU对StructuredBuffer支持比较差，建议优先使用RWTexture2D/RWBuffer这些更基础的资源。

调试平台差异时，尽量用模拟器加r.Shaders.Optimize=0关闭优化，再配合RenderDoc验证输出。这一步能确认是编译器优化搞坏还是平台驱动不支持。

7.5 Dispatch线程组数量的向上取整

最后一个小坑：很多人直接用NumValues / 64当作线程组数。如果NumValues = 1000，1000 / 64 = 15，但实际需要16个线程组才能覆盖1000个元素。这时候会有一小片数据没有被处理，而且很难发现，因为大多数数据都是对的，只有末尾约40个元素缺失。正确写法永远是：

uint32 GroupCount = FMath::DivideAndRoundUp(NumValues, 64);

这一点看起来基础，我却在不止一个朋友的项目里见过，属于那种“看代码很难发现，看结果总差一点点”的经典低级Bug。

7.6 命名空间和Include路径的坑

.usf文件里使用#include时，路径有两种典型写法：

#include "/Engine/Public/Platform.ush" #include "/MyProject/MyComputeShader.ush"

注意第二个路径的前缀必须和IMPLEMENT_GLOBAL_SHADER里声明的Virtual Shader路径匹配。如果你项目里嵌套了模块，最好把Shader文件放在项目根目录的Shaders下，统一使用/项目名/前缀。不要在Include里写相对路径，比如../Shared/xxx.ush，这在UE的Shader编译架构里很容易出问题。

另外，如果把Shader声明放在Private模块之外，引擎可能无法识别。建议在项目的Build.cs里确认模块已经依赖了RenderCore和RHI：

PublicDependencyModuleNames.AddRange(new string[] { "Core", "RenderCore", "RHI", "RenderGraph" });

缺少依赖时，最典型的现象是编译时报“FRDGBuilder未定义”或者“IMPLEMENT_GLOBAL_SHADER无法解析”，这和在游戏逻辑里忘加模块依赖是同样的症状。

算起来从第一次在UE4里用Compute Shader做粒子系统到现在，折腾这个技术也有好几年了。我的习惯仍然没变：每接触一个新版本的UE5，永远是先搭一个“输出线程ID”的最简CS，确认链路通了再去碰业务逻辑。这个方法帮我避开了无数次“看起来都在工作，实际数据全是坏的”的地狱调试。你刚开始时可以试试，把例子里那个1000个float输出改成一张2048x2048的纹理再跑一遍，感受一下子线程组和纹理坐标之间的映射关系，这比背一百遍文档都有用。CS这条路一旦跨过“能跑起来”的门槛，后面等着你的就是GPU Driven渲染、程序化生成那整片新世界。