译自aras的博客，总共3篇文章，讲述unity5优化自己渲染器的过程
吸取大神调试与优化经验，了解unity5内部渲染器的优化方法

前篇：Unity5内部渲染的优化1：介绍

介绍过去后，让我们来进行实际工作

 
在以前的文章已经提到的,首先我尝试想起/找出现有代码,做一些分析并且写下突出的地方。    
分析多个项目主要揭示了两件事:
1.    渲染代码使用多线程真的比使用我们现有的“一个主线程和一个渲染线程” 更广阔。这里有一个从unity5的timeline profiler的截屏：
 
在这种特殊情况下, CPU的瓶颈是渲染线程，大部分的时间都花费在了 glDrawElements（这在MacBookPro; 在蝴蝶效应这个demoGPU简化场景处理了6000drawcall）。主线程只是结束等待渲染线程之后再追上。依靠硬件，平台，图形API等。瓶颈能在任何地方出现，比如 相同的程序在更快的PC在DX11下 主线程和渲染相比消耗的时间相同。
culling sliver在似乎不错，最终我们希望我们所有渲染代码都能那样不错。这里放大剔除部分：
 
2.没有“优化这一个函数，使所有事情都两倍快”的地方：（   重排数据将是一个漫长的旅程，移除多余的决策，移除这里和那里的小的事情，直到我们能达到“每个线程两倍快”。如果。
渲染线程分析的数据并不是特别有趣。大部分的时间(下面突出加亮显示的一切) 是OpenGL运行运行时间/驱动。添加一些注释关于我们做了什么蠢事情而导致驱动做了太多多余的事情(我不知道, 没有好的原因切换不同的顶点布局等)，但是另外在我们的方面没有看太多。大部分剩余时间都消耗在动态批处理上了
 
看看在主线程消耗非常大的函数，我们得到了这些：
 
现在当然有问题产生（为什么这么多哈希表查找？为什么排序要这么长时间？等等，看看上面的列表），但关键是，没有在一个地方优化什么就能带来魔法性能效益和一匹小马（此处比喻）。

观察1：材质“显示列表”总是被重建

观察2：哈希表查找太多了

从上面的观察名单,，发现“为什么哈希表查找如此之多”的问题。
在渲染代码中，很多年前我加了一句像这样的：
Material::SetPassWithShader(Shader* shader, ...)
调用的代码已经知道了哪个shader应该被设立。材质也知道这个shader，但是它存储了一些东西我们叫做PPtr（“persistent pointer固执指针”）它本质上是一个句柄。指针直接避免做一个句柄指向指针（handle->pointer）的查找（目前是一个哈希表查找，由于各种复杂的原因，很难做一个基于数组的处理系统）
结果是，在许多改变之后，Material::SetPassWithShader完成了两次handle->pointer查找，即使它已经有了实际的着色器指针作为参数!修复:
 
上图翻译：
通过应用程序清理和优化材质。
SetPassWithShader在某些点被增加来避免一个PPtr deref。结果是，现在它还是做“两次”m_shader PPtr derefs!那不是一个糟糕的优化。
所以把它们都清理掉；有一个Material.SeShaderPass 它直接取得它需要的，避免废弃并且到subshader中去。并只是在pass指针基于直接缓存显示列表。这允许移除特殊的情况为阴影caster passes复制代码。
VikingVillageStatic 工作台项目，i7 5820k，主线程 Camera.Render 7.25ms->6.59ms 17个文件改变，有135个插入的地方和213个删除的地方：
Ok我们的结果是好的，可以衡量的并且非常简单的实现了性能优化，也是的代码库更加小巧，多么好的一件事情。

小的调整

在上面Mac的渲染线程性能分析中，我们自己的代码在 BindDefaultVertexArray消耗了2.3%，感觉消耗得太多了。结果，它循环所有可能的顶点组件类型并检查一些东西。使得使用shader代码循环只在顶点组件部分。稍微快了一些
一个项目使用GetTextureDecodeValues很多次，它是用来计算色彩空间的，HDR和光照贴图纹理解压缩为常数。一个可选“intensity multiplier”参数，在所有的调用地方都被明确的设置为1.0，只有一个除外，它做了一系列的sRGB数学操作 。我察觉到，在代码中使得一些pow（）调用消失了 。增加到一个“look later” 清单中：为什么在第一个地方我们调用这个函数这么频繁呢？
一些代码在渲染循环中计算出drawcall对边界批处理需要放在哪里  （也就是说：去哪里切换到一个新的shader，等等），是比较一些状态作为单独的bool。把它们打包到位域中并且比较一个整数。没有可观察到性能变好,但是实际上代码变少了,所以一场胜利:)
（位域是指信息在存储时，并不需要占用一个完整的字节， 而只需占几个或一个二进制位。例如在存放一个开关量时，只有0和1 两种状态， 用一位二进位即可。所谓“位域”是把一个字节中的二进位划分为几 个不同的区域， 并说明每个区域的位数。每个域有一个域名，允许在程序中按域名进行操作。 这样就可以把几个不同的对象用一个字节的二进制位域来表示。）
注意到，弄清楚哪个顶点缓冲和顶点布局被物体查询网格数据使用，在内存中是一个非常远的部分。基于用途类型重排数据（渲染数据，碰撞数据，动画数据等等）
也减少了数据包装漏洞msinilo的优秀的CruncherSharp （在这种方法上做了一些调整：））（下图为CruncherSharp ）我听说有一个小工具对Linux（pahole）。在Mac上有 struct_layout但是它可以永远在unity中执行并且Python 脚本经常有一些溢出异常引起失败。
 
浏览代码的时候,发现 我们追踪每个贴图的mipmap bias的方法非常复杂。当纹理跟踪所有将要使用的的材质属性表时时，它设置每一个纹理；通知它们在任何mip bias上的改变，并且bias 是从性能表和 一起应用的每个纹理中获得，每次设置一个纹理在图形驱动上。天啊。固定的。因为这改变了我们图形抽象API的接口,这意味着改变所有11个渲染后端; 几个相当微不足道的改变但感觉很恐怖(我甚至连局部的建立它们的一半都不能)。不要害怕，我们有建造场来检查编译错误,和测试程序组来逆向检查!
 
上图翻译：
使纹理mip bias 健全的处理。
当bias是纹理阶段的一部分，它只这样怪异的，不是纹理。或者也许是其它的东西。
现在它只是纹理过滤器filter/变形warp/各向异性aniso的一部分设置，并且只有当它被改变时才被应用。
 Gone：
Bias应用在每个和所有gfxdevice.SetTexture 调用中，
Texture::NotifyMipBiasChanged,（博主注：先通知mip bias改变了）
TexEnv::TextureMipBiasChanged, （博主注：再调用改变mip bias纹理）
TexEnvData::mipBias。（博主注：再确确实实执行bias操作）
80个文件改变了，插入了228，删除了263。
没有明显的性能差别，但是感觉不那么复杂了。加一个“look later”清单：我们追踪每个纹理有很多相同的数据；有些关于非二次幂限制的纹理（NPOT）的UV缩放。这些天我怀疑它没有存在的理由，如果可能的话继续观察并且移除它。
并且也做了一些其他一些类似的局部调整,它们每个都很简单,让一些特殊的地方更好一些，但是不会观察到任何性能改进。也许把它们放大一百倍才能看到一些明显的影响，但是它们有更多的可能性  我们需要重做一些要严重事情去得到更好的结果。

材质属性表的布局

set<PropertyName> m_IsGammaSpaceTag; // which properties come as sRGB values

我取而代之的是(简化,只显示数据成员;dynamic_array很像std::vector,但更加有EASTL风格):

struct NameAndType { PropertyName name; PropertyType type; };

// Data layout:
// - Array of name+type information for lookups (m_Names). Do
//   not put anything else; only have info needed for lookups!
// - Location of property data in the value buffer (m_Offsets).
//   Uses 4 byte entries for smaller data; don‘t use size_t!
// - Byte buffer with actual property values (m_ValueBuffer).
// - Additional data per-property in m_GammaProps and
//   m_TextureAuxProps bit sets.
//数据布局：
//-数组名只要 名称+类型就好有（m_Name）信息来查找。不要再加别的东西
//只要有关键信息用来查询就好
//-性能数据的位置在value buffer (m_Offsets)中。使用4byte来记录小数据
//不要使用size_t!
//- 实际的属性值(m_ValueBuffer)使用Byte缓存
//-追加的数据  每个属性在m_GammaProps和m_TextureAuxProps设置为bit。
//
// All the arrays need to be kept in sync (sizes the same; all
// indexed by the same property index).
//所有数组需要保持同步（大小相同；相同属性的索引）
dynamic_array<NameAndType> m_Names;
dynamic_array<int> m_Offsets;
dynamic_array<UInt8> m_ValueBuffer;

// A bit set for each property that should do gamma->linear
// conversion when in linear color space
//在一个线性空间时都该做gamma->linear转换，对于每个属性用一个bit来设置   
dynamic_bitset m_GammaProps;
// A bit set for each property that is aux for a texture
// (e.g. *_ST for texture scale/tiling)
//  对于每个属性来说一个bit设置是一个纹理的辅助aux
// (如. *_ST for texture scale/tiling)
dynamic_bitset m_TextureAuxProps;

当一个新属性被添加到一个属性表，它只是附加于所有的数组。属性名称/类型信息和属性位置在数据缓冲中保持分离，所以当查找属性时，我们甚至不获取对搜索本身不需要的数据。
最大的外部变化是在这之前，一个是需要找到一个属性值并且存储一个直接指针指向它（被用于预记录材质显示列表，在重演它们之前能够“patch in临时接入” 全局shader属性的数值）现在每当改变数组大小都会引起指针无效；所以取而代之，能存储在指针中的所有的代码，必须改变去存储偏移offsets在属性列表中。所以，最后有一些代码被修改了。
 
寻找属性已经从一个O(logN)的操作（贴图查找）转变到一个O（N）操作。如果你学过计算机科学你就知道这不是个好事，它是一个典型的taught。然而，我看了各种项目并且找到典型的情况，属性表总共包含5-30个属性（大多数在10左右）；并且一个线性的扫描所有查找的数据紧挨着在内存中其他的数据，这与STL map查找map节点能随意的远离其他点作对比并不是那么糟（如果发生了这件事，每个节点能作为一个CPU缓冲存储器丢失）。从几个不同的项目的性能作分析,其中一部分是“查找属性”在PC、笔记本电脑和iPhone上一直很快。
可是这一变化带来了魔法一样性能改进的吗?并没有，它稍微改善了平均帧时间并且内存消耗得更少，特别是当有大量不同材质的时候。但是做了“只是用被打包的数组代替了STL maps ”节能有魔法般的结果吗？并不是。嗯,至少我不必再边翻我的眼睛边把这段代码展示给别人看了,就是这样。

效果

这个工作大约用了两周时间（我估计只有75%---其余花在了其它不相关的修正，代码检查等）所有的平台创建并且测试通过的一个状态；准备好请求。40个提交，135个文件，大概2000行代码改变了。
 
上图翻译：
大多数时间存储是从一个更好的gfxdevice 显示列表的超高速缓存，特别是材质总是选择不同的关键字这种情况（例如，Viking Village这款游戏在很快的PC 12ms-8.5ms）在其他情况下稍微快一些，但是也不是特别快（结合上面的，在google链接文档的细节）。一般来说结果的帧率更加稳定，也许由于在运行中很少内存分配。
?    材质不止一个显示列表在缓冲存储器中
?    更好的属性表数据布局（6 std：：map-> 3 dynamic_array 和 2 bitsets）。这意味着你不能把指针当做值来存储；改变了所有代码来储存offsets。增加了更多的单位测试和性能表！
?    让 texture mip bias健全的处理，现在它只有 filter/wrap/aniso 参数，替代了被循环追踪并且应用在每个SetTexture调用。
?    SetPassWithShader曾做了一个优化在某些点上来避免一个PPtr deref，但是现在它总是做两次derefs！把它清理掉。
?    移除世界matrix的设置替换成 light props 在正向循环之前统一一致，似乎没有用
?    稍微优化了线程显示列表可修补数据
?    OpenGL：稍微优化了BindDefaultVertexArray （像GLES）
?    1multiplier的情况时增加了特殊的GetTextureDecodeValues  
?    根据platform folks，网格缓冲永远不会再安卓/Tizen泰泽系统上丢失  
?    撤回TextureID 到所有32位平台除了ps4
?    更多密封的结构体/类打包在某些地方
?    从shaderlab上移除了不用的东西（如 MatrixVal）并且在很多地方加了注释
?    杂项：支持-数据包 命令行在发布玩家创建也有争议，并且在mac/linux上

博主总结：aras的代码风格非常好，并且他在写代码的时候就有许多注释，因此优化起来很有效率，优化的地方也很准确。aras也很善用分析器。。。。总之，看了之后受益匪浅。。希望unity越来越牛x。

待译。。。

原文：http://blog.csdn.net/wolf96/article/details/48222205