阿基de一亩三分地啦

UE4 材质翻译HLSL流程简析

Fri, 25 Aug 2023 00:00:00 GMT

大体流程

从FHLSLMaterialTranslator::Translate() 出发，我们看一下流程概况，开头即讲述了由于normal可能以节点PixelNormalWS 的形式被其他property的计算用到,因此先得到normal的计算代码。

在此之前，本身材质编译是在Pixel层面去做，有一些操作希望放到Vertex层面做，那这一部分也需要先计算出来，同理还有一些自定义的表达式（CustomExpression)。

接下来，可以看到每个材质属性（Material Property）均是通过一个Material->CompilePropertyAndSetMaterialProperty(MP_XX,this) 的入口生成各自的代码，其中细节略后再提。

但此处并不是真正生成代码的地方，这里仅仅是将该材质属性相关联的代码段（FShaderCodeChunk）生成，并没有做拼接。

代码段的拼接核心在GetFixedParameterCode 中，

拼接已生成的HLSL，仍然是先生成normal的部分，再生成其他属性的部分。（HLSLMaterialTranslator.cpp）

再往后看，则没有更多稀奇的代码了，不在本文的关注范畴内。打开GetFixedParameterCode 一看，更加不稀奇，主要使用了GetDefinitions() 来获得所有代码段拼接的结果。。。一看，好家伙，就全从头到尾直接连起来是吧

当然，这么做是对的，正确的原因来自于它的核心翻译规则：递归翻译。

在这里，其实已经有很多的疑问了：

频繁出现的FShaderCodeChunk说是代码段，但具体倒底是啥，怎么起作用的

这些ShaderdXXX的变量是干啥用的,就说SharedPropertyCodeChunks好了

递归翻译是怎么具体体现的？为什么直接线性拼接是对的？

FShaderCodeChunk的构成

感恩UE在此处仍然留有一定的注释。

Hash不必多说，其计算来自于const uint64 Hash = CityHash64((char*)FormattedCode, Result * sizeof(TCHAR)); FormattedCode其实就是Definition 。

SymbolName是一个变量名字，以“Local_N”的形式由FHLSLMaterialTranslator::CreateSymbolName 创建

Definition 可以被总结为两种情况：

UniformExpression或者bInline：

常数比如 0.1，0.5，Material3(0,0,0)
UniformExpression，通常是由于我们在材质上设置的非布尔参数构成，翻译后会变成MaterialScalar(Vector)Expressions[i].x/y/z/w
bInline, 比如Local_0.rgb,false,true这类并不需要赋值和计算的

非Constant以及非UniformExpression：

Type Local_N = Func(Local_0,Local_1,...,Local_{N-1})

Type 是这个CodeChunk的结果的数据类型，一般通过FHLSLMaterialTranslator::GetArithmeticResultType 进行运算得到

总结，FShaderCodeChunk可以是一段简单的变量\常量的读取截断，也可以是一个完整的变量声明+赋值，根据代码内容有对应的Hash。

从`CompilePropertyAndSetMaterialProperty` 开始的翻译细节

映入眼帘的是

进去FHLSLMaterialTranslator::SetMaterialProperty一看，主要是配置了翻译时当前是在哪个ShaderFrequency(SF_Vertex?SF_Pixel?SF_Compute?):

这里把将符合InShaderFrequency 的CodeChunks作为当前编译时用到CodeChunks ，可见这个Shared 其实是在ShaderFrequency 上Share翻译出来的CodeChunk。

返回来继续看，主要是调用了 MaterialInterface->CompileProperty ，后续会跳转到有

FHLSLMaterialTranslator::CallExpression(FMaterialExpressionKey ExpressionKey,FMaterialCompiler* Compiler)

作为编译某个材质节点的切入口。

此处微微一品~（虽然我确实品了老长一会）可以知道通过FunctionStacks[ShaderFrequency]->ExpressionCodeMap 存储已经翻译过的Expression结果（无论失败与否），避免重复翻译同一Expression, Expresssion即UMaterialExpression是材质蓝图里面的一个个节点。

核心的切入点在这一段：

递归翻译

此时您切入Compile()可以发现来到了MaterialExpressions.cpp,总而言之，基本都是Compile内部会调用输入节点的Compile，这也就是所谓的递归翻译。可以脑补出一个流程，水流从材质属性往深深的材质蓝图向下流去，由深入浅的返回时一条条翻译出来，由此，语句之间的依赖关系自动解决，因此最后直接线性拼接即可得到正确的翻译结果。

此时，还想补充一下一些Compile中的细节，FShaderCodeChunk 和FShaderCodeChunk::Definition是如何生成的。

`FShaderCodeChunk` 的生成

我们可以简单从一个UMaterialExpressionAdd::Compile::Compile进行解读

注意两个函数AddCodeChunkWithHash 和GetParameterCode

GetParameterCode 的作用是返回此处用到的CodeChunk的符号，我愿统称为变量名，与前文的Definition基本是一个含义。

AddCodeChunkWithHash 内部调用了AddCodeChunkInner 生成codechunk并塞入到当前工作的CurrentScopeChunks中：

返回新生成的CodeChunk在数组中的位置，也是这个原因，大多数时候看到的Chunk[]数组里面存的都是int32，而不是FShaderCodeChunk这样的数据。

Texture Streaming中的LOD计算路径

Fri, 28 Jul 2023 00:00:00 GMT

引子

UTextureLODSettings::CalculateLODBias(const UTexture* Texture, bool bIncCinematicMips) const

这个函数的作用是根据group设置的最大最小lodsize，以及当前贴图的最大尺寸，计算出两者差值，得到bias

代码

这个streaming最高的mip计算

正常来说这里的ResouceLODBias是0，因为AssetLODBias也是约等于CachedLODBias

我们看一下CachedCombinedLODBias的计算，平平无奇：

关注FStreamableRenderResourceState::AssetLODBias的计算：

之所以说约等于的原因，在于AssetLODBias消除了NumCinematicMipLevels的影响（UTexture::GetResourcePostInitState）

AssetLODBias = AssetMipIdxForResourceFirstMip = GetCachedLODBias()-NumCinematicMipLevels

紧接着知道了实际上Streaming时的最大LOD数目，MaxNumLODs=NumMips-AssetLODBias ，合情合理。

接下来算运行streaming时允许的最大最小mip数目时，就考虑到了这个局部变量LODBias，即这节开头的引子

最终，Streaming时计算需要的mips时需要考虑MaxAllowedNumMips 和MinAllowedNumMips 。

总结

总而言之，FStreamingRenderAsset::MaxAllowedNumMips 以及FStreamingRenderAsset::MinAllowedNumMips 决定了可以StremIn/Out的贴图Mip范围。这两个值实际上受到了FStreamableRenderResourceState::MaxNumLODs 的直接影响，而这个MaxNumLODs本身即是减去LODBias之后的值。

在切画质(切换ActiveDeviceProfile)时并不会更新每个texture的CachedCombinedLODBias ,因此导致MaxNumLODs以及MaxAllowedNumMips实际上并不会有效更新，进而streaming的结果保持原有值。

在切画质时，我组项目能看到贴图发生肉眼可见的原因，主要是独门秘技InGameLODBias在其中发挥作用，它会在计算MinAllowedNumMips 和MaxAllowedNumMips 时参与作用。目前该变量的设定是对战场景中贴图的最小LODBias（实际LODBias至少大于等于InGameLODBias）。

这意味着当InGameLODBias对所有画质为0时，贴图的画质只取决于它被创建时的画质，而不受后续画质切换改变，如果真是这个现状，我的评价是非常恐怖。得确认确认

得再品品，看看哪里是不是能在切画质时搞点mip的计算数据更新，更新CachedLODBias,更新FStreamableRenderResourceState 。

一种可能的修复路径

这是目前我自己看下来觉得最安全的修复位置和修复方法，由于系统的复杂性，还是不踩屎坑了

UE4 PSO的载入和保存规则

Fri, 05 Nov 2021 00:00:00 GMT

UE项目优化：PSO Caching

UE中具有PSO Caching机制，全称Pipeline State Object Caching，用于预先记录和构建出运行时所使用的材质依赖的Shader信息，当项目首次使用这些Shader时，该列表可以加速Shader的加载/编译过程。PSO Caching会把渲染状态、顶点声明、Primitive类型、RenderTarget像素格式等数据保存到文件中，提升Shader的加载效率。本篇文章主要介绍PSO Caching的启用及构建流程，并会分析PSO Cache在引擎中的加载流程以及实现热更PSO方式、错误处理等，PSO Caching的原理有时间再进行详细分析。 PSO Caching的官方文档： PSO Caching 。 PSO Cache构建流程概览： PSO Caching的部署和使用大致分为以下几个步骤：为项目开启PSO Cahche和ShaderStableKeys，打包后可以从Metadata/PipelineCaches目录下获得ShaderStableInfo*.scl.csv 添加logPSO参数启动游戏，用于在运行时记录PSO数据（*.rec.upipelinecache）通过ShaderStableInfo*.scl.csv和*.rec.upipelinecache生成*.stablepc.csv 再次执行Cook，通过*.stablepc.csv生成upipelinecache文件，打至包内；启动游戏，引擎自动加载*.stable.upipelinecache，编译Shader时使用PSO Caching 本篇文章的内容顺序也遵循着几个步骤。首先需要为项目开启 ShaderStableKeys ，在执行Cook时生成稳定的ShaderKey，作为记录Shader的凭据。在 DefaultEngine.ini （或平台相关如AndroidEngine.ini）中添加以下值：添加之后再执行打包（Cook），会创建以下目录：并且会在该目录下生成两个文件（分别对应项目、引擎）： Cook过程中会有以下log，表明生成了这两个文件：可以使用它们通过-run=ShaderPipelineCacheTools这个Commandlet来生成*.stablepc.csv 。 *.scl.csv 文件的内容：启动游戏时加入-logPSO参数或者在 DefaultEngine.ini 中加入以下配置：也可以在 Devices Profile中设置：这两个参数在以下代码中使用：运行游戏时会有log: 并会在 Saved/CoolectedPSOs 中创建以下文件：使用以下commandlet：以上命令会在引擎的Binaries/Win64下生成 Client_GLSL_ES3_1_ANDROID.stablepc.csv文件，注意一定要匹配{PROJECTNAME}_{SHADER_FORMART_NAME}.stablepc.csv 这个命名规则。 Android的命名为：Client_GLSL_ES3_1_ANDROID.stablepc.csvIOS的命名为：Client_SF_METAL.stablepc.csv 生成时具有以下Log：最终PSO所需要的所有文件：我把测试工程生成的文件备份了一份： PSOCache.7z ，可以查看每个文件中的内容。把生成的*stablepc.csv放到 Build/Android/PipelineCaches目录下，注意 Build/PLATFORM这个Platform是编译平台，不是Cook的资源平台，Android的包就是 Android而不是 Android_ASTC等。之后重新打包即可。引擎在Cook时通过 stavlepc.csv 创建PipelineCache的代码：实际使用 stablepc.csv的地方就是用它来执行 ShaderPipelineCacheTools 这个commandlet生成upipelinecache文件并打至包内。 ShaderPipelineCacheToolsCommandlet的执行命令为：生成*.stable.upipelinecache文件的包内路径为 Content\PipelineCaches\Android ：因为它是位于Content下并会打包进pak的文件，我们也可以对其进行热更。当安装了包含 upipelinecache 的包，在运行时就会有以下log：与 ShaderCode类似，引擎在启动时也是会自动加载PSO Cache的，在 FEngineLoop中通过调用 ...

https://imzlp.com/posts/24336/

PSO总结.txt

2.0KB

载入

载入是在FEngineLoop::PreInitPostStartupScreen中发生OpenPipelineFileCache

逻辑是先从 \Content\PipelineCaches\Windows载入\Content\PipelineCaches\Windows\XXX_PCD3D_SM5.stable.upipelinecache

接着，检测是否需要ShouldLoadUserCache() ，这一步说的UserCache就是\Saved\xxx_PCD3D_SM5.upipelinecache 。判断条件是，是否能够开启r.ShaderPipelineCache.LogPSO ,以及r.ShaderPipelineCache.SaveUserCache 这两个flag。

SaveUserCache这个flag默认在mac的shipping版本是开的。对于这两个Flag,在Windows的Shipping版本也有强制开启。

但我个人觉得还是PSOFileCacheSaveUserCacheCVar.Set(1); 这种方式比较容易不产生怀疑吧。。

经过检测，这一调用的源头RHIInit()发生在FEngineLoop::PreInitPreStartupScreen()第2592行，而PreInitPostStartupScreen() 发生在FEngineLoop::PreInit3648行,在PreInitPreStartupScreen() 之后。说明变量赋值在变量调用之前。

所以在shipping版本中，它100%是_PCD3D_SM5.stable.upipelinecache +\Saved\xxx_PCD3D_SM5.upipelinecache 组合的结果。

退出及保存

保存在\Saved\xxx_PCD3D_SM5.upipelinecache 。

可以看到调用FShaderPipelineCache::Close()时会保存：

在析构时保存：

除此之外，运行时也会自动保存：

同样需要开启r.ShaderPipelineCache.SaveUserCache 这个flag,当然它默认在shipping中是打开的。

结论

结论是，载入时，一定会载入\Content\PipelineCaches\Windows\XXX_PCD3D_SM5.stable.upipelinecache 如果存在的话。

如果开了r.ShaderPipelineCache.LogPSO和r.ShaderPipelineCache.SaveUserCache，则还会载入本地缓存的\Saved\xxx_PCD3D_SM5.upipelinecache 。

关于保存，如果开启了r.ShaderPipelineCache.SaveUserCache ，会尝试去保存，是否能保存还取决于 r.ShaderPipelineCache.Enabled r.ShaderPipelineCache.LogPSO ，结果会保存在\Saved\XXX_PCD3D_SM5.upipelinecache 。触发保存的时机分别在FShaderPipelineCache::Tick()FShaderPipelineCache::Close() ,FShaderPipelineCache::~FShaderPipelineCache() 以及PipelineStateCacheOnAppDeactivate()。

总结而言，默认是一定会载入XXX_PCD3D_SM5.stable.upipelinecache ，运行时产生的新PSO会保存在\Saved\XXX_PCD3D_SM5.upipelinecache ，但条件是开启了 r.ShaderPipelineCache.Enabled，r.ShaderPipelineCache.LogPSO 以及r.ShaderPipelineCache.SaveUserCache 。

我认为UE预期shipping版本开启这项保存PSO的功能，同时开发者应该尽量收集更多到PSO到stable.upipelinecache 中，玩家再帮忙收集一部分做到本地缓存更新\Saved\XXX_PCD3D_SM5.upipelinecache，就会越来越不卡顿。除此之外，也可以把XXX_PCD3D_SM5.upipelinecache发给开发者进行合并。

那么目前这些功能在Shipping版本可以看到代码里是开的。

验证

Test Build

在Test Build中默认r.ShaderPipelineCache.LogPSO 和r.ShaderPipelineCache.SaveUserCache 没开，导致在运行时无法存储/生成\Saved\XXX_PCD3D_SM5.upipelinecache 。

所以的content里的文件都被加密打包成.pak 文件，XXX_PCD3D_SM5.stable.upipelinecache 同样在其中，能被成功读入(可从本地log验证）。

单纯增加-logpso并不会触发保存。

一个可行的方案是增加如下命令行参数：

可以在登陆界面通过console检查到对应变量的开启。

然而这一命令却无法触发打开游戏时本地cache的加载，并没有预期之中的LogRHI: Opened FPipelineCacheFile: ../../../xxx/Saved/XXX_PCD3D_SM5.upipelinecache 。

这是因为，由于UE_SHIPPING=0导致两个flag被赋值为0（>FEngineLoop::PreInitPreStartupScreen()），紧接着发生了OpenPipelineCache()(PreInitPostStartupScreen())，此时自然无法读取，推测后面才发生了命令行的flag赋值。

结论是，Test Build在代码不做改动的情况下，可以通过增加命令行参数收集PSO，但无法正常载入本地PSO缓存。

Shipping Build

Jenkins上的太慢，本地先build了一个只有登录界面的shipping.

第一次打开客户端，经检查，默认开启两个flag.

检查log,没有发现类似LogRHI: Opened FPipelineCacheFile: ../../../xxx/Saved/XXX_PCD3D_SM5.upipelinecache 的信息。

符合预期，因为全新版本并没有这个本地缓存文件，会生成。

同时在Saved 文件夹中可发现有新创建的xxx_PCD3D_SM5.upipelinecache 。

第二次打开客户端，发现读取本地缓存的Log:

符合预期。

虽然有console可以用很诡异，但我很确定编译时选的是shipping.

接下来直接看看服务器做出的版本吧。。

第一次打开客户端

试图打开本地缓存，间接说明了LogPSO和SaveUserCache是开启的。

也新创建了本地缓存

在Haven里逛该之后，准备退出了，看一下目前PSO的情况：

第二次打开客户端，发现读取本地缓存的Log:

在登录界面看PSO的情况：

数目对的上，说明读取成功，没有新增的PSO。

接下来去haven逛该看看涨不涨

只有很微小的两个，主要是因为登陆时碰到了7日礼包界面，真的服咯，再开一遍。

OK，没有新增，证明Shipping版本的PSO载入和保存机制如上所言。注意编版本时一定要选shipping,虽然出来的也有命令行，但Test的PSO是没法读入本地缓存的。

UE4中通过代码创建贴图

Fri, 15 Sep 2023 00:00:00 GMT