懶得反覆打解釋，雖然有點亂和長...
問題僅專注於CPU/GPU/RAM/VRAM，至於SSD/HDD可以暫時忽略，通常而言後兩者很難是瓶頸，如果真有問題就考慮上SSD。
_____________
遊戲中大多數應用於遊戲上的邏輯，很受限於主執行緒(main-thread)原因有幾個，有很多東西只適合放在主執行緒上例如GUI這些的。
GUI其背後的事件驅動設計框架於該thread上，通常耦合許多東西，如果想要包山包海會導致UI的邏輯在更新按鈕等事件成本上過於沉重，導致GUI的變化很容易影響幀數。
其次並行性差的原因在於總是容易集中在某些功能上，例如transform或是render，很難平衡不同thread並且這些邏輯彼此之間可能存在同幀中的相依性才能確保正確，而不能像遊戲提交到渲染可以async到下一個幀執行。
雖然人眼上看去螢幕中有許多人物，但許多人物中如骨骼(bone)本質上是批量處理，為了有效利用cache和其資料結構順序存取設計等，還有加鎖等實作上的限制，通常由Tree(樹)和array(C#中的list)處理這類，因為沒辦法有效區分哪些有變哪些沒變，所以基本上每幀都要重複工作計算全部的。
由於設計上導致只能利用幾個thread，再加上因為很難『確定』是否某些更新會產生『廣播』的效果，很可能就像地圖要分割負載平衡一樣，你很難找到那個邊界，並且這樣設計是否高效?
所以通常而言有太多邏輯需要前後覆蓋或依賴前面結果等，就必須得完全等前一批全部處理完才能跟著處理下一種邏輯，而難以分開來分別處理完成。
批量的優點在於能最高化利用資料在快取中，同時可能消滅掉可能無用冗餘的操作，畢竟你不需要說處理到一半突然要同步要跑哪些邏輯等等。
易於使用的設計且通用，但也限制住遊戲通常只能利用幾個thread。
就現在而言普遍渲染的CPU負荷並不大，取決於遊戲引擎和製作者的技術，因為繪製的API本質上就是收集許多資料，這些資料相當於設定GPU這個畫筆，好的方式可以大幅降低每個drawcall的CPU成本，另外就是變形網格(蒙皮網格)需要骨骼這個成本，不過現在CPU每1ms(5Ghz)可以處理3000根骨骼，線上遊戲一個人物看不同設計可能低至100高至300多，手機遊戲還只能幾分之一。(IPC影響不大)
RAM通常處理容易miss的地方，需要繪製大量可動的物件或是遍歷大量設定資料例如動畫，還有script(腳本)通常因為GC(垃圾收集)所造成。
反覆收集資料形成可用的指令，並編譯和引用Shader進行繪製。(編譯通常在安裝或加載時完成，應該理解成把中間碼給編譯(或解釋)，原始碼早就編譯好了)
可能有些人不太好理解指令和資料的區別，你可以理解指令是一個高度耦合硬體設計的資料，有一定的編碼格式。
同樣作用於『設定』，設定可能是指令也可能是資料，例如直接從指令中得知或資料中得知，只是指令本身影響流程，指令可能會去取資料改變行為就是了。(只是GPU用API提交的指令應該理解為命令(command)而不是指令(instruction))
實際上Shader編譯出來才是真正的instruction，繪製API這些設定行為是個畫筆一樣，將資料傳遞到GPU上保存著，並靈活組織之間的關係，而核心在Mesh Render上。
在現代的流程中幾乎離不開三角形，哪怕是一個2D或粒子發射等，實際上都是可能兩個三角形形成一個四邊形。
但是相比於3D建模而言這終究少得多而可以忽略。
整個GPU概念上就是從幾何管道到像素管道的一個過程，各種步驟行為都是為了提高執行效率，無論是提高利用率或是降低資源浪費而已。
按NVidia分法如以下:
幾何可以細分成，頂點索引->頂點屬性獲取->頂點著色器->VPC為止，而頂點著色器的部份換代可以區分幾何著色器、曲面細分著色器、網格著色器，這些目的都是為了提高效率，但不細說因為展開太長。
每個GPU在一幀開始時都限制於需要建立頂點索引排佈頂點資料以供後續，目的是為了規避大量頂點資料在VRAM上的耗費容量與頻寬。
透過整理組織結構，保證了可以並行並且壓縮(共用頂點)來大幅節省對VRAM的耗費。
對於一個普遍建模來說，在沒有展開UV時理想上的結構約是2個三角形、面對應1個頂點，在展開UV不同情況下合理的佈局約比例是1三角形對應0.55~0.66個頂點。
影響因素除了建模還有遊戲引擎的導入時最佳化，並添加安排整個網格內的資料佈局，擁有stream等屬性等，利於後續減少浪費頻寬。
一般而言我們談論到一個遊戲的建模，其頂點/三角形數量都是沒有進行渲染時的負荷，都是解包出來的，無法代表具體流程所造就的負荷。
對於一個150K的三角形，頂點數量約90K頂點，每個頂點約90byte的資料，因為拆分網格讓頂點數量在單網格保持在65536以下，故僅只需要2byte(16bit)，一三角形索引三頂點只需要2*3=6byte。
因為stream等設定，加上Shader僅需要其中約32byte，理論上而言對於VRAM需要渲染該模型一次，就需要90k*32byte~=2.8MB多+6byte*150k~=3.7MB。
由於幾何幾乎難以被cache，大部分幾乎在VRAM上，所以讀取一次這樣的網格需要消耗VRAM 3.7MB的頻寬，根據燈光和各種效果如反射、陰影，可能計算5~6次，這裡算為6次後為22MB頻寬。
需要渲染這樣的網格20個，共計300萬三角形，每幀需要消耗VRAM 440MB(0.44GB)，每秒渲染100幀需要44GB/s，會耗費一段時間沒法做什麼事情(盡管一定程度上會重疊其他工作，減少浪費時間)。
如果我們還需要全部都需要變形，稱作骨骼網格、蒙皮網格，則因為每次需要兩個數據，並獨立計算一次骨骼，足夠高的精度好的變形需要4bone，需要取8次頂點屬性，共計32byte。(前面32byte，可能由頂點位置4byte*3+法線4byte*3+UV4byte*2=32byte，但只需取三次頂點屬性)
讀取一次這樣的網格則計算為，90K*64byte~=5.6MB+6byte*150k~=6.5MB，按上面的流程計算一次，每幀消耗掉0.78GB，100次後消耗費78GB/s。
組裝回三角形，決定外觀需要在L2上工作，這時候才真正需要取頂點屬性值和變為一個個獨立可行的面(盡管需要按一定順序)和設置一些Shader ID等等，簡化來說(頂點資料*3+索引)*2，一個讀+寫的過程，可能會大於(因為需要寫入更多)或更少(因為stream等設置改善的緩衝區和組織資料，減少Shader不必要存取的資料浪費，例如頂點屬性中有切線的數值，但是Shader不需要)。
(索引是『去重複』的一些操作所需，兩次)
按靜態網格計算，32*3+6byte=102byte，按變形網格計算，64byte*3+6byte=198byte，讀寫完通常『至少』要204byte，396byte。
(頻寬是讀+寫，高速記憶體等算半雙工，只有PCIE這種是全雙工，通道是有限必須重複使用的)
對於靜態網格需要612M(300萬三角形，3M個)*6=3.672GB/幀，對於變形網格需要1188M*6=7.128GB/幀。
100幀共計需要367.2GB/s和712.8GB/s的L2頻寬。
之後到VPC上，被檢測是否剔除無須真正到光柵化器(現納入像素Shader負荷)，作為剔除圖元輸入，每個VPC可以檢測一個圖元(三角形)。
通常瓶頸可能也在這裡，當三角形過多的話，通常是靜態網格才能瓶頸，變形網格可能是VAF和L2瓶頸。(與SM/CU等成比例，每個靜態網格三角形需要3個頂點*3個屬性9個頂點屬性獲取，而變形網格每個三角形需要3個頂點*(常用3個屬性+2個屬性*4bone)等於33個頂點屬性獲取)
3M個三角形，因為多個渲染步驟共計18M渲染的三角形開銷這樣一幀，100幀需要1.8G三角形處理能力，相當於三個前端以0.6Ghz運作，或一個前端以1.8Ghz運作。(效率100%的話...)
由於前端往往依賴『低速』『高延遲』的L2和VRAM，利用率很低，即使單元能提取可能也受到該週期的資料提取不上來如寬度不夠大或管線延遲等，利用率通常20~30%就不錯了。
可能有人覺得ALU是瓶頸，其實是個錯覺，除了光照對表面外貌的計算等外，非常難以優化出一個Shader能充分運用計算的，現代架構改進只是剛好讓Shader需要一些計算時能及時一起做計算來壓低『延遲』，在每個SM/CU內壓低調度，最終提高利用率。(所以單純堆高fp32/int32並不能真正提高渲染性能)
到了RAS後，RAS會受到剔除完成的三角形數量影響，同時也受到一個影響『光柵化的像素面積』，盡管每個RAS可以對應低至2x2高至16*16(16*16達最大效率)，對於RDNA2的之後架構是1:32像素外，其餘現代的架構(不說太遠古的)約1:16像素。
同時之間取高值，簡單大量生產的面例如粒子，就可能會浪費RAS，需要混合輸出也同時浪費ROP。
TMU方面則以每個像素按需要執行的Shader紋理採樣量算，不同Shader產生效果約2~7次，加上很多三角形覆蓋的面重複等和後處理導致overdraw(過度繪製)需要乘以約2~5次，極端可能非常多次。
加上紋理過濾不同模式週期，有些細節差異不過多說，約產生1~2週期差異。
這樣每個解析度，例如3840*2160~=8.2M個像素，按不同Shader和場景的組合變化佔據的面積，可能在16.4M~57.4M，按通常程度過度繪製幅度約，32.8M~287M，按不同紋理過濾模式和複雜情況則到32.8M~574M每幀。
100幀情況下可以消耗高達57.4GT/s(通常利用率較高，可以到50%，實際約114.8GT/s)
不考慮後處理/反鋸齒/HDR調色情況下(CROP可以單週期雙混合，但通常不容易所以這裡當成1週期1次)
8.2*1~3次(寫入)*2~5(過度繪製)=16.4M~123M像素，100幀後可消耗高達12.3GP/s(利用通常較高等同TMU，實際約24.6GP/s)
在普遍forward下，紋素/像素相對體積沒很膨脹且易於在cache上工作，如果工作在deferred，也就是現在大多數商業產品上，例如很多手機高品質遊戲/3A，則framebuffer上處理的資料龐大容易miss，因為G-Buffer編碼太多資料。
上述的填充率加總，按每個3~6byte算到L2上，需要消耗139.4G*3~6=418.2GB~836GB/s的L2頻寬，或高達每0.8~1.2byte至VRAM上約111.52GB/s~167.28GB/s。
越前端利用率通常越低，限制越大。( PD(prim dist 圖元派發)實質上就『一個』在多種架構多個GPU中都是，需要先進的著色器例如網格著色器節省避免反覆建立，或利用計算著色器繞過限制，對於相對零碎不連續的網格提高利用率)
__________
爆VRAM是因為需要重新解碼丟回VRAM上，才導致嚴重延遲，利用串流(指串流紋理、HLOD)等技術則是節省許多也能從RAM->PCIE->VRAM上搬運，但同樣過於嚴重就會受限RAM和PCIE的頻寬，並且PCIE頻寬通道有限，實質上能利用可能僅幾分之一的實質頻寬。
大多數反覆加載消耗在CPU上導致延遲，按照不同設計可能HDD/SSD都有影響，現在建議SSD容易隨機存取。
認真說有很多東西是難以並行，沒有實際操作過逆向過分析過，不懂各種設計權衡下造就的問題，你可能會有盲目的自信心忽略限制，從而過度簡單化一件事情...
例如GPU上需要批量工作，還要考慮裝載到cache上及可以利用的thread，需要來回切換搬運而無法同時做不怎同質的事情，利用率就很難上去了。(過於大量的計算還得考慮計算延遲，計算的延遲週期*吞吐率*計算資料寬度=暫存器數量，盡管現在都已經堆積到足夠fp32 FMA的程度了...)
CPU上，所有資料結構如Tree這些都需要分支和存取資料，而每個CPU核心不管多厲害的分支預測實質只能輸出一個分支結果在一個週期，實質意義上的IPC是0.8~1.5之間，我們看到各種比較的bechmark評比的是PPC，也就是每週期性能，而不是真實指令數，只是太常把PPC用於代表IPC。
(分支預測可以同時拆分分支預測表試圖一同處理兩個分支，但本質上仍然只能輸出一個分支，不要扯太多，請考慮分支預測的本質和分支是什麼。)
________
請注意，變形網格(骨骼網格、蒙皮網格)骨骼變換影響頂點是指『最大』，而並非一定會使用4bone，理論上1頂點:5個屬性和1頂點:11個屬性後者要2.2倍，實際上『平均』可能僅使用多約40~50%(相對一個骨骼，一個骨骼是必須的)
(即使全部都是4bone不等於一定全部都會跑到4bone，甚至可以更精確無限制，但GPU頂點/頻寬負荷越大，同時消耗更多CPU...)
盡管可能會少取一些頂點屬性，但按照設計和組織出來的緩衝區一但要使用仍可能會取滿64byte。(雖然只取了兩個屬性共兩次，沒辦法的設計)
(實務上可能4bone->1bone取48byte(而不是40byte)，因此快了33%，需要考慮對齊限制)
(如果頂點屬性沒有設為stream，Shader也沒有使用它，仍然要浪費讀取和拼裝用頻寬或頂點屬性獲取成本，看設計...)
____題外話_____
不能只比理論值，也要考慮到延遲(latency)，可能會耗費不少電晶體，同等條件下利用率更高，能抵達的利用率上限也更高。
都以新架構的顯卡比較而言如下:
NVidia>AMD>Intel，在GPU無論SM/CU內延遲(包含存取L1)都這樣，還有一個數值是SM/CU需要存取到低等級的Cache System時的延遲，需要通過Crossbar到L2甚至包含L3(AMD/Intel)到VRAM上的設計。
由於Crossbar需要取捨，通常越大規模的顯卡會比低規模的顯卡在存取L2/L3/VRAM的延遲上更高，一定程度上阻礙的利用率保持同等甚至會下降，所以兩倍規模無法擁有兩倍性能。(還可能包含PD一些等等瓶頸)
這裡的規模採以位寬判定，因為每32/64個位寬為一個單位互連，所以256bit比128bit延遲更高。(例如前兩家翻倍可能增長20~30%，Intel直接增加50%延遲這樣的例子...前面數值只是舉例大概)
在這個指標上，增長規模增長的延遲NVidia~=AMD >Intel，前兩者是算老牌GPU廠商，懂得處理好驅動到很好，且硬體設計足夠合理，Intel在這裡吃虧導致規模損失嚴重，這是無法靠驅動彌補的。
不過同等理論值下所需要的電晶體成本，Nvidia>AMD>Intel，這包含SM/CU內+Crossbar後互連的全部設計，最貴是NVidia，最便宜的是Intel...所以還是得合理設計才能真正到低成本高性能。
(不過NVidia的缺點在於還沒解決L2頻寬瓶頸，AMD和Intel相對而言沒有這個問題)
(Ampere到Ada Lovelace偷偷增加了50% L2的位寬寬度，同時L2頻率增長約33%，最終提供了兩倍頻寬沒有在白皮書上講...不過也就剛剛好夠支撐跟安培一樣規模比例)
____其他____
不納入光照的其他效果(不算forward/deferred):體積照明/體積霧
解析度*3~4次紋理採樣*1~2週期(紋理採樣過濾)*疊代次數(1~100)(疊代次數越高通常光線對比的痕跡越清晰明確，但成本很高，普遍20~40左右，極端設置下達100)(一般不需要紋理採樣過濾各異向性)
8.2M*3*1*40=0.984GT
100fps=98.4GT/s(利用率50%~75% ->131.2GT/s~196.8GT/s)
解析度*1次像素輸出*1~2(如果HDR映射+1)*疊代次數(1~100)
8.2M*1*1*40=0.328GT
100fps=32.8GP/s(利用率50%+->~=65.6GP/s)
如果要產生光線遮罩從而產生對比(有光無光)的光線軌跡，需要攝像機採樣一次幀紋理(因此需要一次幾何成本)。
粒子:
可能需要紋理時按解析度*紋理採樣1次*1~2週期*overdraw(難以剔除+幾乎需要透明混合，容易超過5甚至10，嚴重達20~100)
8.2M*1*2*10=0.164GT
100fps=16.4GT/s(利用率24~72%，22.7GT/s~68.3GT/s)
不需要紋理也能輸出單純的顏色時，僅計算RAS/ROP。
8.2M*1*1*10=0.082GP
100fps=8.2GP/s(利用率24~72%，11.35GP/s~34.15GP/s)
紙片草、樹上大量紙片樹葉類似粒子，overdraw程度上升到10~20甚至更高，按照風、搖動等需求紋理採樣為3~4。
模型草、樹overdraw低得多約5~10，但有大量幾何開銷。(按靜態網格算，透過Shader達成風場飄動效果，不需要靠骨骼計算)
一些體積類效果可能需要多次採樣(類似於體積光照這些疊代)開銷較高，多數後處理可能會結合延遲著色的效果在螢幕空間計算陰影/反射效果(盡管失去精度/訊息)，後處理類按整個螢幕解析度一次紋理/像素成本計算，一些類型可能不需紋理但是需要一次像素寫入且能多種後處理自動合併一次處理。(未必能自動)
_________________註解__________
不同thread代表不同內容，所以不能同時，所以你只能VS時，以下高使用率。(VS和GS...都一類)
->VPC、VFX、L2、VRAM、SM、PD...
平衡的情況，除了L2、VRAM、SM利用率高其他受限大概30~40%以內。
->L2、VRAM、SM、VPC、VFX、TMU、ROP、RAS...
像素高負荷(PS)
->TMU、ROP、L2、VRAM、SM、RAS...
上述計算的100幀，如果包含不包含『其他』只算本身大概幾幀，如果是3060大概多少幀?
如果是蒙皮網格，大概40fps，如果是計算蒙皮網格(動態合併)60fps，如果是一般網格70fps。
蒙皮最重是L2 40~45%、VFX 30~40%、VPC 30%。
計算蒙皮最重是L2 55~65%、VFX 40~50%、VPC 42~45%。
一般網格(靜態)是VPC 60%+、L2 30%、VFX 25%。
不同陰影、反射大面積可能會讓overdraw(反射基於攝像機採樣而不是被draw面積)的幅度從5提升至7~10。
上述fps可能低至30fps以下，計算蒙皮網格45~50fps，一般網格55~60fps。
______新增2024/10/5__________
※重複著色問題:頂點緩衝區是有限的，這意味著消除重複頂點工作可能失敗，在建立唯一索引緩衝區的過程可能多次，而這在傳統管線而非基於Mesh Shader或基於Compute Shader於Async多幀是相當致命的，每幀都要重複處理這個問題。
也就是同樣頂點在觸發頂點著色器時可能多次觸發，在經過排序聚集於編輯器導入時等或遊戲加載時處理，將單次頂點觸發由3~5次左右將低至1.1~1.4次，可以透過上述計算結果知道浪費頻寬是相當誇張的。
所以『至少』這個部份可能仍要乘以一些係數才是真實的消耗獲取屬性和頻寬量，例如*1.1~1.2左右更加準確，少數模型外觀係數可能相對更高，不過可能有更優的演算法解決。
________________
頂點屬性常見介紹
位置(Position):三維空間中表示頂點所在的位置，一般頂點要求較高會受到在世界空間內偏離原點等影響，精度需要在fp32，所以32bit(4byte)*3(x,y,z)=12byte。
法線(Normal):頂點屬性中的法線，是必要的屬性，代表著垂直該面的方向，同樣需要12byte。
法線基本常見的模式區分為面(face)和頂點(vertex)兩種，前者相對粗糙的表面而後者相對平滑，而後者執行模式下也相對消耗較多，但是結合法線貼圖後並不僅是從頂點獲得方向，而是從紋理採樣處理至像素片段，可以精確到像素點的程度且性能更高可控。
UV:代表表面被攤開成一個平面的情況並逐一對應，UV在頂點屬性中代表需要查找的對應(x,y)座標。
切線(Tangent):切線空間是與物件空間不一樣的座標，XY與UV相關而Z則處理法線，W則在有需要時可以翻轉法線，一共是4byte*4=16byte。
切線空間的優點:能使法線貼圖跟隨頂點變形後的結果，且同時不依賴需要按UV佈局的要求，這使得法線貼圖更通用。
顏色(Color):使用頂點著色的方式，不需要依賴紋理且相對不易模糊，分別為四個顏色通道，每個顏色通道8bit(1byte)，共計4byte。
使用頂點顏色雖然很難表現出紋理細膩色彩變化，但是不需要進行紋理採樣可以決定一個面的顏色。
混合權重(BlendWeight):根據權重來決定骨骼至網格的變形程度，每個頂點可以受到四個骨骼影響，每個骨骼約4byte，共計16byte。
混合索引(BlendIndices):索引到對應的骨骼，每個骨骼用4byte紀錄關係，在可以受到四個骨骼影響下，總計約16byte。
材質ID(Material ID):以4byte(32bit)標示對應的材質。
材質是一種經過定義佔據空間可以執行的Shader，可以認為是一種實例。在Unity是加入於三角形索引中集群判定而非單獨編碼在頂點中，所以不會計入頂點屬性中。
所以假設一個網格共4096個三角形，共四種色都均分1024個，則只在開頭編碼相應材質ID，可以大幅節省不必要的儲存開銷。
____
頂點可以反覆定義多張UV在上面，這意味著可能有UV0、UV1、UV2...等等，每個都要佔用8byte，盡管通常這些屬性都是Stream的，但可能會佔據很多空間，而大量使用交錯緩衝區(按Stream屬性觸發)可能會使得快取的效率稍差。
遊戲引擎(渲染管線部份)可能會盡可能努力進行資源管理的改進重用部份來減少反覆生成三角形和少用部份屬性，這可能節省一些頻寬，但即使如此仍然不要濫用。
(例如在變形網格中輪廓僅需要位置、法線、UV，和反覆多次forward的燈光計算(多盞燈)，權重和骨骼索引開銷在額外次數被消除頻寬開銷和頂點獲取，並且減少反覆頂點讀取，但同樣生成足夠多的三角形)
比較理想的情況下VRAM到L2上並只被讀取拼裝至三角形不寫回Cache上而持續輸出小塊被檢測判定背面、可見性判定剔除至RAS與L1上進行轉換和開始像素片段計算。
不過也能改變整更渲染流程使用meshlet的思路，不過需要MS/CS來完成，先剔除後計算而非傳統流程先計算後剔除，盡管更加複雜，但對於通常的背面剔除(50%機率是背面)可規避VPC逐一檢測的缺陷從而在實際上約1.8~1.9倍(同時也包含避免讀取頂點屬性，可結合VB)，而實際複雜場景更多面重疊的幾何模型，按頂點法線方向形成簇統計，合理平均簇大小將比傳統頂點著色器快至3~5倍左右。(實際約3.5~4.5)
以Mesh Shader利用率高約45%(計算著色器可高至63~65%)，結合高剔除率所達成的效果。
在標準上DX12_2中spec寫著為256v/256t，(NV自己擴展下為256v/512t)，仍建議以64V/84T或98T為主，在分割情況下VT比無法達0.5(1頂點2三角形)，越大簇利用率越大且VT比越低數據越緊湊，但粗剔除成功率越低。(所以權衡下不易過大)(沒有UV則能達到64/126)
可以理解cluster culling的效率很高，如果結合VB和重心座標加速將能更快。(如果在足夠的三角形密度，例如至少接近光柵化像素比例1:4(四百萬屏幕空間像素:一百萬三角形)，會較優。)
如果提及的是UE5的Nanite，自動LOD的處理帶來一定延遲，和軟光柵化及複雜的設計如材質與像素計算等，建議要到達單三角形像素級(每像素1三角形)以上才有優勢，越高越好。(Nanite包含了Cluster Culling等等改進，但VB並非實質參與而是負責G-buffer生成)
變形網格(骨骼網格、蒙皮網格)可能會因為變形而需要進行更新MS/CS中的資料，會有一些代價，盡管使用了SM/CU去取代了PD(prim dist)自行完成。(但並不一定會徹底不用PD)
在Unity6中僅採用計算著色器動態蒙皮合併(C++層自動處理無法定義)，在Unity2022(中國)實現虛擬幾何體但特性不一，在一般版本路線圖中仍採用傳統方式處理幾何。
為了呈現更多屬性並能呈現在光照中顯得精緻，即使利用延遲著色仍要大量編碼至G-Buffer這類紋理中，越多屬性且難靠量化降低精度的情況下，處理一次多種屬性可能需要32Byte以上，這對Cache的壓力很大，一但Miss至更低等級的Cache和Memory上都會瓶頸。
Visibility Buffer(可見性緩衝區)則編碼相對緊湊，並透過計算取得切線等屬性，雖然計算量可能相對較大。(並且可能需要跳躍而降低cache hit rate)
在密集渲染中VB將具備一些優勢，因為僅在後續將真實需要的頂點屬性和紋理一同處理。
__________
一般遊戲為了在傳統流程中減少不必要的提交和造成不必要的GPU計算屬性，會需要在CPU端計算可見性，也就是基於包圍盒的方式進行檢測，因為不會發生進入任一攝像機視錐內並算完後做整片網格丟棄這種開銷。(這是一種粗剔除)
包圍盒的CPU成本非常低到近乎無視的程度，在大多數使用下也並無太多問題。
缺點是，一些交互的效果例如燈光會受到包圍盒(bounds)的設定造成許多麻煩，尤其在Unity的蒙皮網格需要進行骨骼變形情況下很難處理可見性，其可見性並非基於骨骼而是基於網格的固定bounds，並根據物件階層移動中心點。
這導致會有異常臉部受光而身體卻完全不受燈光影響的問題，這是因為燈光範圍與bounds計算結果所導致的，若臉部與身體是不同網格的情況下。
而為了預測可能的旋轉變形角度，通常bounds會比真實網格大上一圈甚至更多不少，使得照明出現問題的機會更大，而照明範圍加大可以減輕該問題，但是更容易使單網格受多照明影響，這在forward中尤為致命，高多邊形網格在需要多次計算後成本非常昂貴。
____
形態鍵的計算比較複雜，在未來我可能會添加，但在不啟用時僅影響VRAM佔用，對於大量使用形態鍵的網格而言，每個被影響頂點可能產生12~30byte至一個形態鍵。所以大量形態鍵會使得網格膨脹多倍佔用空間。
_____
有其他需要可以詢問。
。
LINE