UWA DAY 2019部分记录

性能

gpu Instancing

在低端机型表现

实验:900个相同球体 50半透明材质球
enable:红米4x drawcall 下降100,时间上升3倍
drawMeshInsanced drawcall 下降十倍,时间下降

结论:

instanced drawcall 有额外开销

  • Batch.FillInstanceProperties

半透明

  • Material.enableInsatancing 需关注排序(Unity本身严格根据深度来排序,会造成穿插)
  • 用drawMeshInsanced 耗时更低,需要关注dc和overdraw

不透明

  • 推荐Material.enableInsatancing

CommandBuffer

官方文档: https://docs.unity3d.com/Manual/GraphicsCommandBuffers.html
限制: 无Batching
用途:自定义渲染

实验:900球 50半透明
红米4\小米5S
drawing -10% culling -75%

不透明
5s
drawing + culling +
原因:setpass call 增加
unity本身对材质排序?
一旦用了commandbuffer setpass call必然不会被优化

相同材质的连续提交不会合并 setpass call

post processing stack v2

pc较多,移动较少

bloom optimized (hidden/fastbloom)

ppsv2-bloom
fastmode
diffusion 慎重

ppsv2-uber

frag复杂度?

DEFERRED RENDERING

用途: AAA效果
限制 gpu压力

forward 三角20W 无压力
换deferred

红米4X
forward 30fps
deferred 20fps

小米5S
forward 30
defer 30
gpu busy 18.8% vs 24.3%
gpu 频率 Max 624MHz 223MHz vs 423MHz
(利用率并没有提高,所以不会明显发热,但会耗电)

渲染

Drawcall

Mask
Mask 底下是Stencil材质 不能合并
看不到的东西依然参与排序

解决思路:让Mask区域独立计算Depth
挂Canvas! = -这TM都行

RectMask
Rect MAsk 2D

  • 节省dc overdraw
  • 增加cull (SendWill)
    • 持续开销脚底
    • 拖动时开销较高
  • 根据实际情况 权衡

重建

Rebuild
Canvas.SendWillRenderCanvases
OUtline Tiledsprite

问题:持续重建

减少逐帧更新的元素

Rebatch
动静分离

异常情况
Canvas.SendWillRenderCanvases中有
vh.Clear() (数组的capacity不降,使得clear耗时很长)
2018已无问题? 其实是.net 4.5才无问题

100个Image修改alpha值?
……过了 todo 待更新

位置同步?

UGUIrenering.updateBatches
48% Canvas.SendWill
43% CanvasRebder.SyncXXX self

100Image 不移动 vs 移动

总之少移动

过滤1.25屏

JobSystem 2018.2才有

适用:
主线程中复杂逻辑
高频调用

  • 子线程开销总和 高于 主线程
  • Schedule complete 时机 ??

#内存优化

##资源设置

纹理

  • 分辨率
  • 格式
  • Read/Write
  • Mipmap
  • Texture Streaming ?

网格

  • 顶点数量
  • 顶点属性数量 ?
  • Read/Write
  • Mesh Compression

动画片段

  • 片段数量
  • 压缩模式/动画精度 ?
  • 动画模式 Humanoid?

音频片段

  • 音频数据量
  • 加载方式

资源加载

同步vs异步
同步:快
异步:较快,平滑

未处理前,AB:12.9M, 内存42M,小米Mix2
292ms vs 851ms

优化后: 313.8ms ?

Async upload pipeline ?

  • 异步加载 Texture&Mesh
  • 通过渲染线程直接传到gpu
  • 2018.3才支持到 Texture&Mesh

设置

加大Upload Buffer 增加传输数据

默认4M -> 16M

加大Upload Time Slice 加快传输速度

默认4ms -> 8ms

注意点

  • 加大Upload Buffer会增加一个恒定内容,除此之外无副作用,可设置成16、32M
  • Time Slice需要控制,太大会带来卡顿 (?看下原理),合理则帧率更平滑
  • 场景切换时可将time slice调高(8-16ms),一般运行时调低(2-4ms)

BackgroundLoadingPriority

控制异步加载资源在主线程的“后加载”耗时 (?)

  • 各种资源的AwakeFromLoad
  • Shader.Parse

不同分档

  • ThreadPriority.Low - 2ms
  • ThreadPriority.BelowLow - 4ms √
  • ThreadPriority.Normal - 10ms
  • ThreadPriority.Low - 50ms

总结

  • 调整Upload Buffer和Upload Time Slice
  • 调整BackgroundLoadingPriority
  • 开启多线程渲染
  • 调整资源的加载顺序(比如shader) (?)

异步的不当操作

  • 较大量开启RW的Texture (todo: 查下rw代表什么)
  • AB异步加载
    • 每帧加载数量
    • 注意BackgroundLoadingPriority (?跟AB有什么关系)
  • 关注实例化耗时 (?)
  • 关注实例化顺序 (在某些情况 实例化A,A依赖B,B还未加载)

资源内存

纹理

memory budget、max level reduction (?)
在Memory Budget足够时

  • Scene Texture 是满Mipmap加载(?)
  • 动态加载的Go Texture是最低配Mipmap进行加载和实例化
  • 渲染时,按照距离远近和Budget进行调整
    在Memory Budget不够时
  • Scene Texture 按最低配加载,已加载Streamed Texture按照距离Remove Mipmap,越远的越先Remove高Level Mipmap
  • 动态加载的Go Texture只按最低配Mipmap进行加载、实例化、渲染
    注意
  • Mobile端: QualitySettings.streamingMipmapsActive=true
  • 对于升级项目注意,会让纹理变糊

音频片段

加载方式:

  • Streaming加载方式适合背景音乐
  • 同时播放的小音频文件,Decompressed方式

srp

官网
https://blogs.unity3d.com/2019/02/28/srp-batcher-speed-up-your-rendering

框架

lwrp
hdrp

lwrp&hdrp

  • built-in shaders srp不支持
  • 自带shaders
  • ?

lwrp

  • 关注性能
  • 单pass forward
  • 1 Directional
  • 不支持SH
  • real time shadow不支持Point
  • [Batching]
  • static bath
  • 不支持dynamic batch
  • color space linear
  • gi enligthen realtime 不支持

  • shader 支持 shadergraph

  • [postProcessing]部分支持pps 不支持motion blur
  • UI 某个模式不支持

存在频繁GC开销

https://docs.unity3d.com/Packages/com.unity.render-pipelines.lightweight@5.3/manual/lwrp-builtin-feature-comparison.html

hdrp

the heretics 视频

关注画面 渲染工具丰富

Render loop

prepare -> depth ->DBuffer -> GBuffer -> SSR/SSAO volumetric shadow
-> deffered-\
| ↓ SSSS -> Post-processing
->forward -/

Selection

Built-in

  • 高 Asset store 依赖
  • 快速原型
  • 进行中

LWRP
中、低性能\易拓展\支持shader graph

SRP
追求画面