Unity ShaderLab學習總結

http://www.jianshu.com/p/7b9498e58659

Unity ShaderLab學習總結

 

做者 DonaldW 關注

2014.07.20 17:17* 字數 4891 閱讀 39776評論 10喜歡 112

Why Bothers？

爲何已經有ShaderForge這種可視化Shader編輯器、爲何Asset Store已經有那麼多炫酷的Shader組件可下載，仍是有必要學些Shader的編寫？

2014-0718-1607-11-33.png

• 由於上面這些Shader工具/組件最終都是以Shader文件的形式而存在。
• 須要開發人員/技術美術有能力對Shader進行功能分析、效率評估、選擇、優化、兼容、甚至是Debug。
• 對於特殊的需求，可能仍是直接編寫Shader比較實際、高效。

總之，Shader編寫是重要的；但至於緊不緊急，視乎項目需求。

涉及範圍

本文只討論Unity ShaderLab相關的知識和使用方法。但，

• 既不討論渲染相關的基礎概念，基礎概念可參考Rendering Pipeline Overview等文章。
• 也不討論具體的渲染技巧
• 移動設備GPU和桌面設備GPU硬件架構上有較多不一樣點，詳見下面的「移動設備GPU架構簡述」一章。

使用Shader

2014-0720-1007-25-36.png

如上圖，一句話總結：

1. GameObject裏有MeshRenderer，
2. MeshRenderer裏有Material列表，
3. 每一個Material裏有且只有一個Shader；
4. Material在編輯器暴露該Shader的可調屬性。

因此關鍵是怎麼編寫Shader。

Shader基礎

編輯器

使用MonoDevelop這反人類的IDE來編寫Shader竟然是讓人滿意的。有語法高亮，無語法提示。
若是習慣VisualStudio，能夠以下實現.Shader文件的語法高亮。

• 下載做者donaldwu本身添加的關鍵詞文件usertype.dat。其包括了Unity ShaderLab的部分關鍵字，和HLSL的全部關鍵字。關鍵字之後持續添加中。
• 將下載的usertype.dat放到Microsoft Visual Studio xx.x\CommonX\IDE\文件夾下；
• 打開VS，工具>選項>文本編輯器>文件擴展名，擴展名裏填「shader」，編輯器選VC++，點擊添加；
• 重啓VS，Done。

Shader

Shader "ShaderLab Tutorials/TestShader" { // ... }

2014-0720-1707-17-42.png

Shader的名字會直接決定shader在material裏出現的路徑

SubShader

Shader "ShaderLab Tutorials/TestShader" { SubShader { //... } }

一個Shader有多個SubShader。一個SubShader可理解爲一個Shader的一個渲染方案。即SubShader是爲了針對不一樣的渲染狀況而編寫的。每一個Shader至少1個SubShader、理論能夠無限多個，但每每兩三個就足夠。
一個時刻只會選取一個SubShader進行渲染，具體SubShader的選取規則包括：

• 從上到下選取
• SubShader的標籤、Pass的標籤
  • 是否符合當前的「Unity渲染路徑」
  • 是否符合當前的ReplacementTag
• SubShader是否和當前的GPU兼容
• 等

按此規則第一個被選取的SubShader將會用於渲染，未被選取的SubShader在此次渲染將被忽略。

SubShader的Tag

Shader "ShaderLab Tutorials/TestShader" { SubShader { Tags { "Queue"="Geometry+10" "RenderType"="Opaque" } //... } }

SubShader內部能夠有標籤（Tags）的定義。Tag指定了這個SubShader的渲染順序（時機），以及其餘的一些設置。

• "RenderType"標籤。Unity能夠運行時替換符合特定RenderType的全部Shader。Camera.RenderWithShader或Camera.SetReplacementShader配合使用。Unity內置的RenderType包括：
  • "Opaque"：絕大部分不透明的物體都使用這個；
  • "Transparent"：絕大部分透明的物體、包括粒子特效都使用這個；
  • "Background"：天空盒都使用這個；
  • "Overlay"：GUI、鏡頭光暈都使用這個；
  • 用戶也能夠定義任意本身的RenderType這個標籤所取的值。
  • 應注意，Camera.RenderWithShader或Camera.SetReplacementShader不要求標籤只能是RenderType，RenderType只是Unity內部用於Replace的一個標籤而已，你也能夠自定義本身全新的標籤用於Replace。
    好比，你爲本身的ShaderA.SubShaderA1（會被Unity選取到的SubShader，常爲Shader文件中的第一個SubShader）增長Tag爲"Distort"="On"，而後將"Distort"做爲參數replacementTag傳給函數。此時，做爲replacementShader實參的ShaderB.SubShaderB1中如有也有如出一轍的"Distort"="On"，則此SubShaderB1將代替SubShaderA1用於本次渲染。
  • 具體可參考Rendering with Replaced Shaders
• "Queue"標籤。定義渲染順序。預製的值爲
  • "Background"。值爲1000。好比用於天空盒。
  • "Geometry"。值爲2000。大部分物體在這個隊列。不透明的物體也在這裏。這個隊列內部的物體的渲染順序會有進一步的優化（應該是從近到遠，early-z test能夠剔除不需通過FS處理的片元）。其餘隊列的物體都是按空間位置的從遠到近進行渲染。
  • "AlphaTest"。值爲2450。已進行AlphaTest的物體在這個隊列。
  • "Transparent"。值爲3000。透明物體。
  • "Overlay"。值爲4000。好比鏡頭光暈。
  • 用戶能夠定義任意值，好比"Queue"="Geometry+10"
• "ForceNoShadowCasting"，值爲"true"時，表示不接受陰影。
• "IgnoreProjector"，值爲"true"時，表示不接受Projector組件的投影。

另，關於渲染隊列和Batch的非官方經驗總結是，一幀的渲染隊列的生成，依次決定於每一個渲染物體的：

• Shader的RenderType tag,
• Renderer.SortingLayerID,
• Renderer.SortingOrder,
• Material.renderQueue（默認值爲Shader裏的"Queue"）,
• Transform.z(ViewSpace)（默認爲按z值從前到後，但當Queue是「Transparent」的時候，按z值從後到前）。

這個渲染隊列決定了以後（可能有dirty flag的機制？）渲染器再依次遍歷這個渲染隊列，「同一種」材質的渲染物體合到一個Batch裏。

Pass

Shader "ShaderLab Tutorials/TestShader" { SubShader { Pass { //... } } }

一個SubShader（渲染方案）是由一個個Pass塊來執行的。每一個Pass都會消耗對應的一個DrawCall。在知足渲染效果的狀況下儘量地減小Pass的數量。

Pass的Tag

Shader "ShaderLab Tutorials/TestShader" { SubShader { Pass { Tags{ "LightMode"="ForwardBase" } //... } } }

和SubShader有本身專屬的Tag相似，Pass也有Pass專屬的Tag。
其中最重要Tag是 "LightMode"，指定Pass和Unity的哪種渲染路徑（「Rendering Path」）搭配使用。除最重要的ForwardBase、ForwardAdd外，這裏需額外提醒的Tag取值可包括：

• Always，永遠都渲染，但不處理光照
• ShadowCaster，用於渲染產生陰影的物體
• ShadowCollector，用於收集物體陰影到屏幕座標Buff裏。

其餘渲染路徑相關的Tag詳見下面章節「Unity渲染路徑種類」。
具體全部Tag取值，可參考ShaderLab syntax: Pass Tags。

FallBack

Shader "ShaderLab Tutorials/TestShader"{ SubShader { Pass {} } FallBack "Diffuse" // "Diffuse"即Unity預製的固有Shader // FallBack Off //將關閉FallBack }

當本Shader的全部SubShader都不支持當前顯卡，就會使用FallBack語句指定的另外一個Shader。FallBack最好指定Unity本身預製的Shader實現，因其通常可以在當前全部顯卡運行。

Properties

Shader "ShaderLab Tutorials/TestShader" { Properties { _Range ("My Range", Range (0.02,0.15)) = 0.07 // sliders _Color ("My Color", Color) = (.34, .85, .92, 1) // color _2D ("My Texture 2D", 2D) = "" {} // textures _Rect("My Rectangle", Rect) = "name" { } _Cube ("My Cubemap", Cube) = "name" { } _Float ("My Float", Float) = 1 _Vector ("My Vector", Vector) = (1,2,3,4) // Display as a toggle. [Toggle] _Invert ("Invert color?", Float) = 0 // Blend mode values [Enum(UnityEngine.Rendering.BlendMode)] _Blend ("Blend mode", Float) = 1 //setup corresponding shader keywords. [KeywordEnum(Off, On)] _UseSpecular ("Use Specular", Float) = 0 } // Shader SubShader{ Pass{ //... uniform float4 _Color; //... float4 frag() : COLOR{ return fixed4(_Color); } //... #pragma multi_compile __ _USESPECULAR_ON } } //fixed pipeline SubShader { Pass{ Color[_Color] } } }

• Shader在Unity編輯器暴露給美術的參數，經過Properties來實現。
• 全部可能的參數如上所示。主要也就Float、Vector和Texture這3類。
• 除了經過編輯器編輯Properties，腳本也能夠經過Material的接口（好比SetFloat、SetTexture編輯）
• 以後在Shader程序經過[name]（固定管線）或直接name（可編程Shader）訪問這些屬性。
• 在每個Property前面也能相似C#那樣添加Attribute，以達到額外UI面板功能。詳見MaterialPropertyDrawer.html。

Shader中的數據類型

有3種基本數值類型：float、half和fixed。
這3種基本數值類型能夠再組成vector和matrix，好比half3是由3個half組成、float4x4是由16個float組成。

• float：32位高精度浮點數。
• half：16位中精度浮點數。範圍是[-6萬, +6萬]，能精確到十進制的小數點後3.3位。
• fixed：11位低精度浮點數。範圍是[-2, 2]，精度是1/256。

數據類型影響性能

• 精度夠用就好。
  • 顏色和單位向量，使用fixed
  • 其餘狀況，儘可能使用half（即範圍在[-6萬, +6萬]內、精確到小數點後3.3位）；不然才使用float。

ShaderLab中的Matrix

當提到「Row-Major」、「Column-Major」，根據不一樣的場合，它們可能指不一樣的意思：

• 數學上的，主要是指矢量V是Row Vector、仍是Column Vector。引用自[Game Engine Architecture 2nd Edition, 183]。留意到V和M的乘法，當是Row Vector的時候，數學上寫做VM，Matrix在右邊，Matrix的最下面一行表示Translate；當是Column Vector的時候，數學上寫做MtVt，Matrix在左邊而且須要轉置，Matrix最右面一列表示Translate。
• 訪問接口上的：Row-Major即MyMatrix[Row][Column]、Column-Major即MyMatrix[Column][Row]。HLSL/CG的訪問接口都是Row-Major，好比MyMatrix[3]返回的是第3行；GLSL的訪問接口是Column-Major，好比MyMatrix[3]返回的是第3列。
• 寄存器存儲上的：每一個元素是按行存儲在寄存器中、仍是按列存儲在寄存器中。須要關注它的通常狀況舉例是，float2x3的MyMatrix，究竟是佔用2個寄存器（Row-Major）、仍是3個寄存器（Column-Major）。在HLSL裏，能夠經過#pragmapack_matrix設定row_major或者column_major。

上述狀況，互不相干。
而後，ShaderLab中，數學上是Column Vector、訪問接口上是Row-Major、存儲上是（還沒有查明）。

ShaderLab中各個Space的座標系

通常狀況下，從Vertex Buff輸入頂點到Vertex Shader，

• 該頂點爲左手座標系Model Space中的頂點vInModel，
  其用w=1的Homogenous Cooridniates（故等效於Cartesian Coordinates）表達vInModel = float4(xm, ym, zm, 1)；
• vInWrold = mul(_Object2World , vInModel)後，得出左手座標系World Space中的vInWorld，其爲w=1的Homogenous Cooridniates（故等效於Cartesian Coordinates）vInWorld = float4(xw, yw, zw, 1)；
• vInView = mul(UNITY_MATRIX_V , vInWrold)後，得出右手座標系View Space中的vInView，其爲w=1的Homogenous Cooridniates（故等效於Cartesian Coordinates）vInWorld = float4(xv, yv, zv, 1)；
• vInClip = mul(UNITY_MATRIX_P , vInView)後，得出左手座標系Clip Space中的vInClip，其爲w每每不等於1的Homogenous Cooridniates（故每每不等效於Cartesian Coordinates）vInClip = float4(xc, yc, zc, wc)；
  設r、l、t、b、n、f的長度絕對值以下圖：
  
  
  
  注意View Space中攝像機前方的z值爲負數、-z爲正數。則GL/DX/Metal的Clip Space座標爲：
  • GL:
    • xc=(2nx+rz+lz)/(r-l);
    • yc=(2ny+tz+bz)/(t-b);
    • zc=(-fz-nz-2nf)/(f-n);
    • wc=-z;
  • DX/Metal:
    • xc=(2nx+rz+lz)/(r-l);
    • yc=(2ny+tz+bz)/(t-b);
    • zc=(-fz-nf)/(f-n);
    • wc=-z;
• vInNDC = vInClip / vInClip.w後，得出左手座標系Normalized Device Coordinates中的vInNDC，其爲w=1的Homogenous Cooridniates（故等效於Cartesian Coordinates）vInNDC = float4(xn, yn, zn, 1)。
  xn和yn的取值範圍爲[-1,1]。
  • GL: zn=zc/wc=(fz+nz+2nf)/((f-n)z);
  • DX/Metal: zn=zc/wc=(fz+nf)/((f-n)z);
  • 在Unity中，zn的取值範圍能夠這樣決定：
    • 若是UNITY_REVERSED_Z已定義，zn的取值範圍是[UNITY_NEAR_CLIP_VALUE, 0]，即[1,0]
    • 若是UNITY_REVERSED_Z未定義，zn的取值範圍是[UNITY_NEAR_CLIP_VALUE, 1]
      • 若是SHADER_API_D3D9/SHADER_API_D3D11_9X定義了，即[0,1]
      • 不然，即OpenGL狀況，即[-1,1]

v2f vert (appdata v) { v2f o; o.vertex = mul(UNITY_MATRIX_MVP, v.vertex); // 1 、二、3是等價的，和4是不等價的 // 由於是M在左、V在右，因此是Column Vector // 由於是HLSL/CG語言，因此是訪問方式是Row-Major o.rootInView = mul(UNITY_MATRIX_MV, float4(0, 0, 0, 1)); // 1 o.rootInView = float4(UNITY_MATRIX_MV[0].w, UNITY_MATRIX_MV[1].w, UNITY_MATRIX_MV[2].w, 1); // 2 o.rootInView = UNITY_MATRIX_MV._m03_m13_m23_m33; // 3 //o.rootInView = UNITY_MATRIX_MV[3]; // 4 return o; } fixed4 frag (v2f i) : SV_Target { // 由於是ViewSpace是右手座標系，因此當root在view前面的時候，z是負數，因此須要-z才能正確顯示顏色 fixed4 col = fixed4(i.rootInView.x, i.rootInView.y, -i.rootInView.z, 1); return col; } struct appdata { float4 vertex : POSITION; }; struct v2f { float4 rootInView : TEXCOORD0; float4 vertex : SV_POSITION; };

Shader形態

Shader形態之1：固定管線

固定管線是爲了兼容老式顯卡。都是頂點光照。以後固定管線多是被Unity拋棄的功能，因此最好不學它、當它不存在。特徵是裏面出現了形以下面Material塊、沒有CGPROGRAM和ENDCG塊。

Shader "ShaderLab Tutorials/TestShader" { Properties { _Color ("My Color", Color) = (.34, .85, .92, 1) // color } // Fixed Pipeline SubShader { Pass { Material{ Diffuse [_Color] Ambient [_Color] } Lighting On } } }

Shader形態之2：可編程Shader

Shader "ShaderLab Tutorials/TestShader" { Properties {} SubShader { Pass { // ... the usual pass state setup ... CGPROGRAM // compilation directives for this snippet, e.g.: #pragma vertex vert #pragma fragment frag // the Cg/HLSL code itself float4 vert(float4 v:POSITION) : SV_POSITION{ return mul(UNITY_MATRIX_MVP, v); } float4 frag() : COLOR{ return fixed4(1.0, 0.0, 0.0, 1.0); } ENDCG // ... the rest of pass setup ... } } }

• 功能最強大、最自由的形態。
• 特徵是在Pass裏出現CGPROGRAM和ENDCG塊
• 編譯指令#pragma。詳見官網Cg snippets。其中重要的包括：

編譯指令	示例/含義
#pragma vertex name #pragma fragment name	替換name，來指定Vertex Shader函數、Fragment Shader函數。
#pragma target name	替換name（爲2.0、3.0等）。設置編譯目標shader model的版本。
#pragma only_renderers name name ... #pragma exclude_renderers name name...	#pragma only_renderers gles gles3， #pragma exclude_renderers d3d9 d3d11 opengl， 只爲指定渲染平臺（render platform）編譯

• 引用庫。經過形如#include "UnityCG.cginc"引入指定的庫。經常使用的就是UnityCG.cginc了。其餘庫詳見官網Built-in shader include files。
• ShaderLab內置值。Unity給Shader程序提供了便捷的、經常使用的值，好比下面例子中的UNITY_MATRIX_MVP就表明了這個時刻的MVP矩陣。詳見官網ShaderLab built-in values。
• Shader輸入輸出參數語義（Semantics）。在管線流程中每一個階段之間（好比Vertex Shader階段和FragmentShader階段之間）的輸入輸出參數，經過語義字符串，來指定參數的含義。經常使用的語義包括：COLOR、SV_Position、TEXCOORD[n]。完整的參數語義可見HLSL Semantic（因爲是HLSL的鏈接，因此可能不徹底在Unity裏可使用）。
• 特別地，由於Vertex Shader的的輸入每每是管線的最開始，Unity爲此內置了經常使用的數據結構：

數據結構	含義
appdata_base	vertex shader input with position, normal, one texture coordinate.
appdata_tan	vertex shader input with position, normal, tangent, one texture coordinate.
appdata_full	vertex shader input with position, normal, tangent, vertex color and two texture coordinates.
appdata_img	vertex shader input with position and one texture coordinate.

Shader形態之3：SurfaceShader

Shader "ShaderLab Tutorials/TestShader" { Properties { } // Surface Shader SubShader { Tags { "RenderType" = "Opaque" } CGPROGRAM #pragma surface surf Lambert struct Input { float4 color : COLOR; }; void surf (Input IN, inout SurfaceOutput o) { o.Albedo = 1; } ENDCG } FallBack "Diffuse" }

• SurfaceShader能夠認爲是一個光照Shader的語法糖、一個光照VS/FS的生成器。減小了開發者寫重複代碼的須要。
• 在手遊，因爲對性能要求比較高，因此不建議使用SurfaceShader。由於SurfaceShader是一個比較「通用」的功能，而通用每每致使性能不高。
• 特徵是在SubShader裏出現CGPROGRAM和ENDCG塊。（而不是出如今Pass裏。由於SurfaceShader本身會編譯成多個Pass。）
• 編譯指令是：
  #pragma surface surfaceFunction lightModel [optionalparams]
  • surfaceFunction：surfaceShader函數，形如void surf (Input IN, inout SurfaceOutput o)
  • lightModel：使用的光照模式。包括Lambert（漫反射）和BlinnPhong（鏡面反射）。
    • 也能夠本身定義光照函數。好比編譯指令爲#pragma surface surf MyCalc
      • 在Shader裏定義half4 LightingMyCalc (SurfaceOutput s, 參數略)函數進行處理(函數名在簽名加上了「Lighting」）。
      • 詳見Custom Lighting models in Surface Shaders
• 你定義輸入數據結構（好比上面的Input）、編寫本身的Surface函數處理輸入、最終輸出修改事後的SurfaceOutput。SurfaceOutput的定義爲

  struct SurfaceOutput { half3 Albedo; // 紋理顏色值（r, g, b) half3 Normal; // 法向量(x, y, z) half3 Emission; // 自發光顏色值(r, g, b) half Specular; // 鏡面反射度 half Gloss; // 光澤度 half Alpha; // 不透明度 };

Shader形態之4：Compiled Shader

點擊a.shader文件的「Compile and show code」，能夠看到該文件的「編譯」事後的ShaderLab shader文件，文件名形如Compiled-a.shader。
其依然是ShaderLab文件，其包含最終提交給GPU的shader代碼字符串。
先就其結構進行簡述以下，會發現和上述的編譯前ShaderLab結構很類似。

// Compiled shader for iPhone, iPod Touch and iPad, uncompressed size: 36.5KB // Skipping shader variants that would not be included into build of current scene. Shader "ShaderLab Tutorials/TestShader" { Properties {...} SubShader { // Stats for Vertex shader: // gles : 14 avg math (11..19), 1 avg texture (1..2) // metal : 14 avg math (11..17) // Stats for Fragment shader: // metal : 14 avg math (11..19), 1 avg texture (1..2) Pass { Program "vp" // vertex program { SubProgram "gles" { // Stats: 11 math, 1 textures Keywords{...} // keywords for shader variants ("uber shader") //shader codes in string " #ifdef VERTEX vertex shader codes #endif // Note, on gles, fragment shader stays here inside Program "vp" #ifdef FRAGMENT fragment shader codes #endif " } SubProgram "metal" { some setup Keywords{...} //vertex shader codes in string "..." } } Program "fp" // fragment program { SubProgram "gles" { Keywords{...} "// shader disassembly not supported on gles" //(because gles fragment shader codes are in Program "vp") } SubProgram "metal" { common setup Keywords{...} //fragment shader codes in string "..." } } } } ... }

Unity渲染路徑（Rendering Path）種類

概述

開發者能夠在Unity工程的PlayerSettings設置對渲染路徑進行3選1：

• Deferred Lighting，延遲光照路徑。3者中最高質量地還原光照陰影。光照性能只與最終像素數目有關，光源數量再多都不會影響性能。
• Forward Rendering，順序渲染路徑。能發揮出Shader所有特性的渲染路徑，固然也就支持像素級光照。最經常使用、功能最自由，性能與光源數目*受光照物體數目有關，具體性能視乎其具體使用到的Shader的複雜度。
• Vertex Lit，頂點光照路徑。頂點級光照。性能最高、兼容性最強、支持特性最少、品質最差。

渲染路徑的內部階段和Pass的LightMode標籤

每一個渲染路徑的內部會再分爲幾個階段。
而後，Shader裏的每一個Pass，均可以指定爲不一樣的LightMode。而LightMode實際就是說：「我但願這個Pass在這個XXX渲染路徑的這個YYY子階段被執行」。

Deferred Ligting

渲染路徑內部子階段	對應的LightMode	描述
Base Pass	"PrepassBase"	渲染物體信息。即把法向量、高光度到一張ARGB32的物體信息紋理上，把深度信息保存在Z-Buff上。
Lighting Pass	無對應可編程Pass	根據Base Pass得出的物體信息，在屏幕座標系下，使用BlinnPhong光照模式，把光照信息渲染到ARGB32的光照信息紋理上（RGB表示diffuse顏色值、A表示高光度）
Final Pass	"PrepassFinal"	根據光照信息紋理，物體再渲染一次，將光照信息、紋理信息和自發光信息最終混合。LightMap也在這個Pass進行。

Forward Rendering

渲染路徑內部子階段	對應的LightMode	描述
Base Pass	"ForwardBase"	渲染：最亮一個的方向光光源（像素級）和對應的陰影、全部頂點級光源、LightMap、全部LightProbe的SH光源（Sphere Harmonic，球諧函數，效率超高的低頻光）、環境光、自發光。
Additional Passes	"ForwardAdd"	其餘須要像素級渲染的的光源

注意到的是，在Forward Rendering中，光源多是像素級光源、頂點級光源或SH光源。其判斷標準是：

• 配製成「Not Important」的光源都是頂點級光源和SH光源
• 最亮的方向光永遠都是像素級光源
• 配置成「Important」的都是像素級光源
• 上面2種狀況加起來的像素級光源數目小於「Quality Settings」裏面的「Pixel Light Count」的話，會把第1種狀況的光源補爲額外的像素級光源。

另外，配置成「Auto」的光源有更復雜的判斷標註，截圖以下：

2014-0720-1607-31-40.png

具體可參考Forward Rendering Path Details。

Vertex Lit

渲染路徑內部子階段	對應的LightMode	描述
Vertex	"Vertex"	渲染無LightMap物體
VertexLMRGBM	"VertexLMRGBM"	渲染有RGBM編碼的LightMap物體
VertexLM	"VertexLM"	渲染有雙LDR編碼的LightMap物體

不一樣LightMode的Pass的被選擇

一個工程的渲染路徑是惟一的，但一個工程裏的Shader是容許配有不一樣LightMode的Pass的。
在Unity，策略是「從工程配置的渲染路徑模式開始，按Deferred、Forward、VertxLit的順序，搜索最匹配的LightMode的一個Pass」。
好比，在配置成Deferred路徑時，優先選有Deferred相關LightMode的Pass；找不到纔會選Forward相關的Pass；還找不到，纔會選VertexLit相關的Pass。
再好比，在配置成Forward路徑時，優先選Forward相關的Pass；找不到纔會選VertexLit相關的Pass。

移動設備GPU架構簡述

《The Mali GPU: An Abstract Machine》系列以Arm Mali GPU爲例子給出了全面的討論，現簡述以下：

• Part 1 - Frame Pipelining
  • Application/Geometry/Fragment三階段組成，三者中最大才是瓶頸
  • OpenGL的同步API是個「illusion」，事實上是CommandQueue（直到遇到Fence會被強制同步）,以減小CPU/GPU之間的互相等待
  • Pipeline Throttle，爲了更低的延遲，當GPU累積了多幀（每每是3幀，以eglSwapBuffers()或Present()來區分幀）的Command時，OS會經過eglSwapBuffers()或Present()來阻塞CPU讓其進入idle，從而防止更多後續Command的提交
• Part 2 - Tile-based Rendering
  • tile-based deferred rendering （Wiki，PowerVR/Mali/Adreno）是重要的概念。其將Fragment一幀處理多個好比16x16的單元，併爲Shader集成一個小但快的cache，從而大幅避免Shader和主內存之間帶寬消耗（電量消耗）
• Part 3 - The Midgard Shader Core
  • GPU包含數個（當前常見爲4-8個）Unified Shading Core，可動態分配用於Vertex Shader、Fragment Shader或Compute Kernel
  • 每一個Unified Shader Core包含數個（當前常見爲2個）用於SIMD計算的運算器Arithmetic Pipeline（A-pipe），1個用於紋理採樣的Texutre Pipeline（T-pipe），1個用於非紋理類的內存讀寫的Load/Store Pipeline（LS-pipe）好比頂點屬性寫讀、變量訪問等
  • 會進行Early-ZS測試嘗試減小Overdraw（依賴於渲染物體提交順序由前至後）
  • Arm的Forward Pixel Kill和PowerVR的Hidden Surface Removal作到像素級別的Overdraw減小（不用依賴於渲染物體提交順序由前至後）
  • 當Shader使用discard或clip、在Fragment Shader裏修改深度值、半透明，將不能進行Early-ZS，只好使用傳統的Late-ZS
• Part 4 - The Bifrost Shader Core
  • 2016年的新型號，對架構做出了優化

參考資源

• Youtube：https://www.youtube.com/watch?v=hDJQXzajiPg （包括part1-6）。視頻是最佳的入門方式沒有之一，因此牆裂建議就算不看下文的全部內容，都要去看一下part1。
• 書籍：《Unity 3D ShaderLab開發實戰詳解》
• Unity各類官方文檔