Unity Shader 变体处理与预加载流程

一、什么是Shader变体,它是怎么出现的

当我们写完一个shader以后,unity需要加载和编译,这个过程由着色器的构建管线来完成,它的输入是着色器,而它的输出就是今天的主角---着色器变体;每一个着色器进入构建管线后会被解析,然后提取着色器片段(顶点着色器和片元着色器等),收集预处理指令,然后每一个着色器变体会有一个参数表;

为什么会有变体这个概念呢,其实它和我们使用宏的概念是一致的,就是一个全局的控制,同一个shader的变体之间的着色器代码功能类似,只是有一些微小的差距,而如果我们为每一种情况都写一个shader,那可能有上千种情况就要上千个shader,这肯定是违反了设计原则的;但是shader变体的增加也会带来一些问题,你需要知道的是,shader的构建过程是需要时间的,而且这个时间是和shader的变体数量呈正相关;

以下两张图截取自Unity Connect:Unity 2018.2新功能:可编程着色器变体移除,帮助我们更好的了解着色器构建管线的流程,想要仔细了解的,可以进去看一下;

二、着色器变体的使用

参考:Unity-Manual-制作多个着色器变体

#pragma multi_compile key_word1 key_word2

每一个pragma至少要有两个变体的关键字,并且有且只有一个关键字被启用;

#pragma shader_feature key_word1 key_word2

它和multi_compile类似,唯一区别在于shader_feature在最终版本中不包括未使用的着色器变体;

数量的计算

我们在一个subshader里面,添加了如下代码

 

着色器关键字的设置

shader_feature,最好使用Material.EnableKeyWord和Material.DisableKeyWord来完成,这个是针对某个材质来控制关键字使用的,范围更小的,只针对某个材质的,它是一个public方法;

multi_compile,最好使用Shader.EnableKeyWord和Material.DisableKeysWord来完成,这个是做全局设置的,它是一个static方法;

关键字数量的限制

使用shader变体时,unity将关键字的数量限制为256个,而unity内部已经使用了大约60个,所以开发者实际可用量更少,所以要注意不要超过限制;(unity对关键字的限制应该是防止开发者滥用关键字造成变体过多而制定的一个规范)

本地关键字

multi_compile和shader_feature声明的关键字都会影响可用数量,unity提供了本地关键字来处理,也就是multi_compile_local与shader_feature_local,这样着色器定义的关键字作用域将保留在该着色器内,而不是整个project;因此,我们应该尽可能使用local而非全局的声明;

unity提供的常用内置的multi_compile

以下几种都会产生相应的变体,如果可以确定不需要它们,就可以使用#pragma skip_variants来跳过;

三、优化Shader加载时间

首先,在Unity中Shader是如何加载的:

  • Editor中:修改shader并保存时立即编译。
  • Runtime下,无论哪个平台,都是在进入场景时加载shader object内容到内存,但是首次实际调用渲染时才编译,编译完成之后会cache下来。

我们所说的优化Shader加载时间指的通常是runtime下的加载;

1.优化shader加载时间

Shader程序是需要在GPU中的,将其从磁盘加载到显存中当然需要一些时间,单个的GPU程序一般不会花费太多的加载时间,但是一个Shader通常会有大量的变体,也就是一个Shader可能会有很多个GPU程序,从而引起了加载时间过长的问题;

超着色器(Uber shader):超着色器是个可以生成多个着色器变体的着色器来源

在Unity中,超着色器由多个部分管理,包括ShaderLab子着色器、通道、着色器类型,以及#pragma multi_compile和#pragma shader_feature这两个预处理指令。

举个Standard Shader的例子,如果它被完全编译,该Shader将会生成上千个有细微不同的着色器程序,它主要会产生两个问题:

  • 从打包的角度考虑时间和空间:大量的着色器变体会增加游戏的构建时间以及游戏的包体数据
  • 从游戏运行的角度考虑时间和空间:在游戏中加载大量的着色器变体会导致游戏卡顿而且会占用大量内存

2.减少Shader构建时间

当构建游戏时,Unity会检测到一些游戏中不会用到的内置着色器变体,然后在构建数据的时候跳过它们,这一选项称为Build-time stripping:

  • 单独的Shader features,针对那些使用了#pragma shader_feature的着色器,如果没有材质使用专门的变体,它就不会被构建;
  • 用于处理Fog和LightMapping模式的变体,如果它不被任何场景使用,它也不会被构建到游戏数据中;这个可以在图形设置中自己设置用于覆盖默认选项;

3.默认的Shader加载过程

在默认设置下,Unity只会将ShaderLab程序资源加载到内存中,但并不会创建内置的着色器变体直到它们需要被使用;也就意味着这些包含在游戏构建数据中的着色器变体不会占用游戏内存和加载时间,直到它们需要被使用;举个例子:着色器使用一个变体来处理带阴影的点光源,但是如果在游戏中从来都没有过带阴影的点光源,那么这个专门的变体永远不会被加载到内存;

这种处理方式的一个缺点是:一些Shader变体在第一次需要使用时的加载问题,因为一个新的GPU程序必须要加载到显卡驱动中,这通常发生在unity运行时,而这也是我们不想看到的事情;Unity使用ShaderVariantCollection资源来解决该问题;

4.Shader Variant Collections

着色器变体收集是一种基于着色器列表的资源,而且包括对于每一个着色器,一系列的通道类型和需要加载的关键字组合;

为了能够帮助创建需要的asset,unity编辑器能够自动追踪这些实际使用的shader和相关变体,在图形窗口我们可以创建一个新的ShaderVariantCollections资源来收集当前追踪到的着色器或者清除当前追踪的着色器列表;

一旦创建好一些SVC资源后,你可以在程序加载时将这些变体自动预加载或者可以通过脚本来加载单独的变体;

我们倾向于预加载shader列表内包含的是频繁使用的shader,因为在预加载Shader列表中着色器变体将会被加载到内存中,而且生命周期将持续整个应用程序,也就是说这些预加载列表中的内容将会一直占用大量的内存资源;为了避免这种消耗,SVC资源需要被分隔成更小的个体,然后通过脚本来根据场景等按需加载;

四、Shader变体的移除

1.变体过多的弊端

shader变体过多,会不仅会造成加载时间的问题,它会导致包体过大,构建时间过长,以及内存占用过多,加载时间变长等主要问题;

2.移除方式

基于项目设置:也就是可以在Project Settings去设置对一些功能是否支持,从而系统会决定是否剔除相关变体;

基于图形设置:可以在图形设置中的shader stripping来设置;

需要注意的是,unity对变体的自动移除会受到构建时间的约束,也就是它只会在构建时间内来判断是否需要剔除,比如我们如果需要一个着色器变体来做光源着色,但是构建时并没有光源,而是运行时脚本添加,这个时候就可能会出现变体被移除掉;

提升着色器代码的设计

  • 首先要确定所有的关键字都是正在使用的,对于不用的关键字,一定要及时清理;
  • 之后要尽可能保证关键字的各种组合都是用到的,有可能产生了12中组合,但是只能用到6种,这个时候就需要优化代码了,要保证尽可能高效的代码路径

脚本移除着色器变体

Unity提供了IPreprocessShaders接口,我们只需要实现这个接口,unity在构建管线中会查找所有该接口的实现进行调用,从而移除相应的着色器变体(在unity的editor模式下是没有用的,因为不走构建流程);

如果要使用多个变体移除脚本,那么需要将脚本按照用例分开,并且需要使用callbackOrder来设置脚本的执行顺序,值越小越先执行;

编写着色器变体移除功能的步骤如下

foreach shader in project{

    检查shader所有的关键字,同时确定这些关键字是否需要;

    移除相应的关键字,并验证构建版本的视觉效果;

}

其它技巧

  • 去除callback

五、Shader变体收集

1.ShaderVariantCollection

着色器变体集合类,记录了每个shader中实际用到的着色器变体;它通常被用于预加载(warmup),也就是一个shader变体可以在游戏开始就被加载而不是在游戏中加载编译;

一个着色器变体集合包含多个着色器变体,它是一个结构体(见下ShaderVariant);一个着色器变体集合的流程通常是记录着色器变体然后保存成一个asset,然后手动加入一些预加载的变体,使用warmup可以完成一个着色器变体集合的预加载;

注意warmup函数的作用:加载一个着色器变体集合中所有的着色器;显卡驱动不会去处理一个着色器,直到它实际被使用;然而,一些对象如果在游戏运行中使用之前从来没有使用的shader,就会因为驱动编译和优化shader导致的问题,在移动平台上会更加严重;而warmup函数可以通过使用shader和变体渲染一个不可见的三角形来完成预加载,并且一个变体被预加载后,再调用warmup就不会再做任何工作;

2.ShaderVariant

它是一个结构体类型,有三个变量;

keywords:用于这个变体的关键字数组;

passType:用于这个变体的通道类型

shader:用于这个变体的shader

3.ShaderVariantCollection的创建和使用

一种是自己手动创建,然后手动添加变体集合;另一种是使用Unity内置功能进行创建,即在图形设置中将当前场景遍历到的变体保存;

启动时加载和代码加载,启动时加载即在图形设置内的shader preloading内设置需要预加载的shadervariantcollection;

代码加载则是像加载其它资源一样加载变体集,然后调用WarmUp()即可;

六、着色器变体的预加载流程

1.两种预热方式的比较

Shader.WarmupAllShaders

预热当前所有已经加载的着色器,以防止将来出现性能问题或其它故障;但是,一次预热过多会造成一些性能问题,最好还是需要使用更细粒度的着色器预热方案,即ShaderVariantCollection;

ShaderVariantCollection.WarmUp,更细粒度的预热方案,只会预热该变体集中的所有着色器变体;

七、踩坑

1.shader构建处理的脚本要放在Editor目录下

Editor目录为特殊文件夹,扩展IProcessShaders接口的脚本需要放置在Editor下,否则在进行构建的时候会报一堆找不到命名空间的错误;

参考

Unity Connect:Unity 2018.2新功能:可编程着色器变体移除(非常详细)

UWA问答:一种Shader变体收集打包以及编译优化的思路

Github-Unity变体剥离的编辑器工具

CatlikeCoding-Level Of Detail,以及中文翻译版

  • 15
    点赞
  • 34
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Unity中的Shader变体是指在编译阶段根据当前渲染平台和材质属性的不同而生成的多个不同的着色器程序。Shader变体会根据平台的不同动态地作出适配,以实现在不同平台下的最佳性能和视觉效果。 在编写Shader时,我们可以使用多种处理指令和变量来定义Shader变体处理指令比如#pragma multi_compile和#pragma shader_feature可以用来指示编译器在编译时根据条件来包含或排除某些代码块。通过这样的方式,我们可以根据不同情况选择不同的代码路径。 Shader变体的生成是基于Shader的特性和特定的材质属性。特性是用来定义一组可选功能的开关,可以在材质中进行开关的切换。材质属性是指材质上的一些自定义属性,比如颜色、纹理等。因此,Shader变体的生成是根据这些特性和属性的组合来确定的。 Shader变体的生成会带来一定的开销,因为每个变体都需要编译和存储。为了减少这种开销,Unity使用了渐变的方式生成变体。即在编译过程中,Unity会根据之前生成的变体生成新的变体,以便在之后的编译过程中尽可能重用已经生成的变体,从而减少重复的工作。 对于Shader变体的管理,Unity提供了几种优化的方式。首先,我们可以使用ShaderVariantCollection来存储和管理常用的变体,从而减少编译时间和内存占用。其次,可以使用ShaderKeywords来动态地切换Shader的特性,以实现更精细的控制和优化。 总之,UnityShader变体功能可以根据不同平台和材质属性生成多个不同的着色器程序,以实现最佳的性能和视觉效果。合理的使用Shader变体管理和优化可以大大提升游戏的性能和兼容性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值