4.4 GPU資源機(jī)制

本節(jié)將闡述GPU的內(nèi)存訪問、資源管理等機(jī)制。

4.4.1 內(nèi)存架構(gòu)

部分架構(gòu)的GPU與CPU類似，也有多級(jí)緩存結(jié)構(gòu)：寄存器、L1緩存、L2緩存、GPU顯存、系統(tǒng)顯存。

它們的存取速度從寄存器到系統(tǒng)內(nèi)存依次變慢： 存儲(chǔ)類型 寄存器 共享內(nèi)存 L1緩存 L2緩存 紋理、常量緩存 全局內(nèi)存

訪問周期	1	1~32	1~32	32~64	400~600	400~600

由此可見，shader直接訪問寄存器、L1、L2緩存還是比較快的，但訪問紋理、常量緩存和全局內(nèi)存非常慢，會(huì)造成很高的延遲。 上面的多級(jí)緩存結(jié)構(gòu)可被稱為“CPU-Style”，還存在GPU-Style的內(nèi)存架構(gòu)：

這種架構(gòu)的特點(diǎn)是ALU多，GPU上下文（Context）多，吞吐量高，依賴高帶寬與系統(tǒng)內(nèi)存交換數(shù)據(jù)。

4.4.2 GPU Context和延遲

由于SIMT技術(shù)的引入，導(dǎo)致很多同一個(gè)SM內(nèi)的很多Core并不是獨(dú)立的，當(dāng)它們當(dāng)中有部分Core需要訪問到紋理、常量緩存和全局內(nèi)存時(shí)，就會(huì)導(dǎo)致非常大的卡頓（Stall）。 例如下圖中，有4組上下文（Context），它們共用同一組運(yùn)算單元ALU。

假設(shè)第一組Context需要訪問緩存或內(nèi)存，會(huì)導(dǎo)致2~3個(gè)周期的延遲，此時(shí)調(diào)度器會(huì)激活第二組Context以利用ALU：

當(dāng)?shù)诙MContext訪問緩存或內(nèi)存又卡住，會(huì)依次激活第三、第四組Context，直到第一組Context恢復(fù)運(yùn)行或所有都被激活：

延遲的后果是每組Context的總體執(zhí)行時(shí)間被拉長(zhǎng)了：

但是，越多Context可用就越可以提升運(yùn)算單元的吞吐量，比如下圖的18組Context的架構(gòu)可以最大化地提升吞吐量：

4.4.3 CPU-GPU異構(gòu)系統(tǒng)

根據(jù)CPU和GPU是否共享內(nèi)存，可分為兩種類型的CPU-GPU架構(gòu)：

上圖左是分離式架構(gòu)，CPU和GPU各自有獨(dú)立的緩存和內(nèi)存，它們通過PCI-e等總線通訊。這種結(jié)構(gòu)的缺點(diǎn)在于 PCI-e 相對(duì)于兩者具有低帶寬和高延遲，數(shù)據(jù)的傳輸成了其中的性能瓶頸。目前使用非常廣泛，如PC、智能手機(jī)等。 上圖右是耦合式架構(gòu)，CPU 和 GPU 共享內(nèi)存和緩存。AMD 的 APU 采用的就是這種結(jié)構(gòu)，目前主要使用在游戲主機(jī)中，如 PS4。 在存儲(chǔ)管理方面，分離式結(jié)構(gòu)中 CPU 和 GPU 各自擁有獨(dú)立的內(nèi)存，兩者共享一套虛擬地址空間，必要時(shí)會(huì)進(jìn)行內(nèi)存拷貝。對(duì)于耦合式結(jié)構(gòu)，GPU 沒有獨(dú)立的內(nèi)存，與 GPU 共享系統(tǒng)內(nèi)存，由 MMU 進(jìn)行存儲(chǔ)管理。

4.4.4 GPU資源管理模型

下圖是分離式架構(gòu)的資源管理模型：

MMIO（Memory Mapped IO）

CPU與GPU的交流就是通過MMIO進(jìn)行的。CPU 通過 MMIO 訪問 GPU 的寄存器狀態(tài)。

DMA傳輸大量的數(shù)據(jù)就是通過MMIO進(jìn)行命令控制的。

I/O端口可用于間接訪問MMIO區(qū)域，像Nouveau等開源軟件從來不訪問它。

GPU Context

GPU Context代表了GPU計(jì)算的狀態(tài)。

在GPU中擁有自己的虛擬地址。

GPU 中可以并存多個(gè)活躍態(tài)下的Context。

GPU Channel

任何命令都是由CPU發(fā)出。

命令流（command stream）被提交到硬件單元，也就是GPU Channel。

每個(gè)GPU Channel關(guān)聯(lián)一個(gè)context，而一個(gè)GPU Context可以有多個(gè)GPU channel。

每個(gè)GPU Context 包含相關(guān)channel的 GPU Channel Descriptors ， 每個(gè) Descriptor 都是 GPU 內(nèi)存中的一個(gè)對(duì)象。

每個(gè) GPU Channel Descriptor 存儲(chǔ)了 Channel 的設(shè)置，其中就包括 Page Table 。

每個(gè) GPU Channel 在GPU內(nèi)存中分配了唯一的命令緩存，這通過MMIO對(duì)CPU可見。

GPU Context Switching 和命令執(zhí)行都在GPU硬件內(nèi)部調(diào)度。

GPU Page Table

GPU Context在虛擬基地空間由Page Table隔離其它的Context 。

GPU Page Table隔離CPU Page Table，位于GPU內(nèi)存中。

GPU Page Table的物理地址位于 GPU Channel Descriptor中。

GPU Page Table不僅僅將 GPU虛擬地址轉(zhuǎn)換成GPU內(nèi)存的物理地址，也可以轉(zhuǎn)換成CPU的物理地址。因此，GPU Page Table可以將GPU虛擬地址和CPU內(nèi)存地址統(tǒng)一到GPU統(tǒng)一虛擬地址空間來。

PCI-e BAR

GPU 設(shè)備通過PCI-e總線接入到主機(jī)上。Base Address Registers(BARs) 是 MMIO的窗口，在GPU啟動(dòng)時(shí)候配置。

GPU的控制寄存器和內(nèi)存都映射到了BARs中。

GPU設(shè)備內(nèi)存通過映射的MMIO窗口去配置GPU和訪問GPU內(nèi)存。

PFIFO Engine

PFIFO是GPU命令提交通過的一個(gè)特殊的部件。

PFIFO維護(hù)了一些獨(dú)立命令隊(duì)列，也就是Channel。

此命令隊(duì)列是Ring Buffer，有PUT和GET的指針。

所有訪問Channel控制區(qū)域的執(zhí)行指令都被PFIFO 攔截下來。

GPU驅(qū)動(dòng)使用Channel Descriptor來存儲(chǔ)相關(guān)的Channel設(shè)定。

PFIFO將讀取的命令轉(zhuǎn)交給PGRAPH Engine。

BO

Buffer Object (BO)，內(nèi)存的一塊(Block)，能夠用于存儲(chǔ)紋理（Texture）、渲染目標(biāo)（Render Target）、著色代碼（shader code）等等。

Nouveau和Gdev經(jīng)常使用BO。

Nouveau是一個(gè)自由及開放源代碼顯卡驅(qū)動(dòng)程序，是為NVidia的顯卡所編寫。 Gdev是一套豐富的開源軟件，用于NVIDIA的GPGPU技術(shù)，包括設(shè)備驅(qū)動(dòng)程序。

更多詳細(xì)可以閱讀論文：Data Transfer Matters for GPU Computing。

4.4.5 CPU-GPU數(shù)據(jù)流

下圖是分離式架構(gòu)的CPU-GPU的數(shù)據(jù)流程圖：

1、將主存的處理數(shù)據(jù)復(fù)制到顯存中。 2、CPU指令驅(qū)動(dòng)GPU。 3、GPU中的每個(gè)運(yùn)算單元并行處理。此步會(huì)從顯存存取數(shù)據(jù)。 4、GPU將顯存結(jié)果傳回主存。

4.4.6 顯像機(jī)制

水平和垂直同步信號(hào)在早期的CRT顯示器，電子槍從上到下逐行掃描，掃描完成后顯示器就呈現(xiàn)一幀畫面。然后電子槍回到初始位置進(jìn)行下一次掃描。為了同步顯示器的顯示過程和系統(tǒng)的視頻控制器，顯示器會(huì)用硬件時(shí)鐘產(chǎn)生一系列的定時(shí)信號(hào)。

當(dāng)電子槍換行進(jìn)行掃描時(shí)，顯示器會(huì)發(fā)出一個(gè)水平同步信號(hào)（horizonal synchronization），簡(jiǎn)稱HSync當(dāng)一幀畫面繪制完成后，電子槍回復(fù)到原位，準(zhǔn)備畫下一幀前，顯示器會(huì)發(fā)出一個(gè)垂直同步信號(hào)（vertical synchronization），簡(jiǎn)稱VSync。 顯示器通常以固定頻率進(jìn)行刷新，這個(gè)刷新率就是 VSync 信號(hào)產(chǎn)生的頻率。雖然現(xiàn)在的顯示器基本都是液晶顯示屏了，但其原理基本一致。 CPU將計(jì)算好顯示內(nèi)容提交至 GPU，GPU 渲染完成后將渲染結(jié)果存入幀緩沖區(qū)，視頻控制器會(huì)按照 VSync 信號(hào)逐幀讀取幀緩沖區(qū)的數(shù)據(jù)，經(jīng)過數(shù)據(jù)轉(zhuǎn)換后最終由顯示器進(jìn)行顯示。

雙緩沖在單緩沖下，幀緩沖區(qū)的讀取和刷新都都會(huì)有比較大的效率問題，經(jīng)常會(huì)出現(xiàn)相互等待的情況，導(dǎo)致幀率下降。 為了解決效率問題，GPU 通常會(huì)引入兩個(gè)緩沖區(qū)，即雙緩沖機(jī)制。在這種情況下，GPU 會(huì)預(yù)先渲染一幀放入一個(gè)緩沖區(qū)中，用于視頻控制器的讀取。當(dāng)下一幀渲染完畢后，GPU 會(huì)直接把視頻控制器的指針指向第二個(gè)緩沖器。

垂直同步雙緩沖雖然能解決效率問題，但會(huì)引入一個(gè)新的問題。當(dāng)視頻控制器還未讀取完成時(shí)，即屏幕內(nèi)容剛顯示一半時(shí)，GPU 將新的一幀內(nèi)容提交到幀緩沖區(qū)并把兩個(gè)緩沖區(qū)進(jìn)行交換后，視頻控制器就會(huì)把新的一幀數(shù)據(jù)的下半段顯示到屏幕上，造成畫面撕裂現(xiàn)象：

為了解決這個(gè)問題，GPU 通常有一個(gè)機(jī)制叫做垂直同步（簡(jiǎn)寫也是V-Sync），當(dāng)開啟垂直同步后，GPU 會(huì)等待顯示器的 VSync 信號(hào)發(fā)出后，才進(jìn)行新的一幀渲染和緩沖區(qū)更新。這樣能解決畫面撕裂現(xiàn)象，也增加了畫面流暢度，但需要消費(fèi)更多的計(jì)算資源，也會(huì)帶來部分延遲。

4.5 Shader運(yùn)行機(jī)制

Shader代碼也跟傳統(tǒng)的C++等語(yǔ)言類似，需要將面向人類的高級(jí)語(yǔ)言（GLSL、HLSL、CGSL）通過編譯器轉(zhuǎn)成面向機(jī)器的二進(jìn)制指令，二進(jìn)制指令可轉(zhuǎn)譯成匯編代碼，以便技術(shù)人員查閱和調(diào)試。

由高級(jí)語(yǔ)言編譯成匯編指令的過程通常是在離線階段執(zhí)行，以減輕運(yùn)行時(shí)的消耗。 在執(zhí)行階段，CPU端將shader二進(jìn)制指令經(jīng)由PCI-e推送到GPU端，GPU在執(zhí)行代碼時(shí)，會(huì)用Context將指令分成若干Channel推送到各個(gè)Core的存儲(chǔ)空間。 對(duì)現(xiàn)代GPU而言，可編程的階段越來越多，包含但不限于：頂點(diǎn)著色器（Vertex Shader）、曲面細(xì)分控制著色器（Tessellation Control Shader）、幾何著色器（Geometry Shader）、像素/片元著色器（Fragment Shader）、計(jì)算著色器（Compute Shader）、...

這些著色器形成流水線式的并行化的渲染管線。下面將配合具體的例子說明。 下段是計(jì)算漫反射的經(jīng)典代碼：

sampler mySamp; Texture2D myTex; float3 lightDir; float4 diffuseShader(float3 norm, float2 uv) { float3 kd; kd = myTex.Sample(mySamp, uv); kd *= clamp( dot(lightDir, norm), 0.0, 1.0); return float4(kd, 1.0); } 經(jīng)過編譯后成為匯編代碼：: sample r0, v4, t0, s0 mul r3, v0, cb0[0] madd r3, v1, cb0[1], r3 madd r3, v2, cb0[2], r3 clmp r3, r3, l(0.0), l(1.0) mul o0, r0, r3 mul o1, r1, r3 mul o2, r2, r3 mov o3, l(1.0) 在執(zhí)行階段，以上匯編代碼會(huì)被GPU推送到執(zhí)行上下文（Execution Context），然后ALU會(huì)逐條獲取（Detch）、解碼（Decode）匯編指令，并執(zhí)行它們。

以上示例圖只是單個(gè)ALU的執(zhí)行情況，實(shí)際上，GPU有幾十甚至上百個(gè)執(zhí)行單元在同時(shí)執(zhí)行shader指令：

對(duì)于SIMT架構(gòu)的GPU，匯編指令有所不同，變成了SIMT特定指令代碼：: VEC8_sample vec_r0, vec_v4, t0, vec_s0 VEC8_mul vec_r3, vec_v0, cb0[0] VEC8_madd vec_r3, vec_v1, cb0[1], vec_r3 VEC8_madd vec_r3, vec_v2, cb0[2], vec_r3 VEC8_clmp vec_r3, vec_r3, l(0.0), l(1.0) VEC8_mul vec_o0, vec_r0, vec_r3 VEC8_mul vec_o1, vec_r1, vec_r3 VEC8_mul vec_o2, vec_r2, vec_r3 VEC8_mov o3, l(1.0) 并且Context以Core為單位組成共享的結(jié)構(gòu)，同一個(gè)Core的多個(gè)ALU共享一組Context：

如果有多個(gè)Core，就會(huì)有更多的ALU同時(shí)參與shader計(jì)算，每個(gè)Core執(zhí)行的數(shù)據(jù)是不一樣的，可能是頂點(diǎn)、圖元、像素等任何數(shù)據(jù)：

4.6 利用擴(kuò)展例證

NV shader thread group提供了OpenGL的擴(kuò)展，可以查詢GPU線程、Core、SM、Warp等硬件相關(guān)的屬性。如果要開啟次此擴(kuò)展，需要滿足以下條件：

OpenGL 4.3+；

GLSL 4.3+；

支持OpenGL 4.3+的NV顯卡；

并且此擴(kuò)展只在NV部分5代著色器內(nèi)起作用：

This extension interacts with NV_gpu_program5 This extension interacts with NV_compute_program5 This extension interacts with NV_tessellation_program5

下面是具體的字段和代表的意義：

// 開啟擴(kuò)展 #extension GL_NV_shader_thread_group : require (or enable) WARP_SIZE_NV// 單個(gè)線程束的線程數(shù)量 WARPS_PER_SM_NV// 單個(gè)SM的線程束數(shù)量 SM_COUNT_NV// SM數(shù)量 uniform uint gl_WarpSizeNV;// 單個(gè)線程束的線程數(shù)量 uniform uint gl_WarpsPerSMNV;// 單個(gè)SM的線程束數(shù)量 uniform uint gl_SMCountNV;// SM數(shù)量 in uint gl_WarpIDNV;// 當(dāng)前線程束id in uint gl_SMIDNV;// 當(dāng)前線程束所在的SM id，取值[0, gl_SMCountNV-1] in uint gl_ThreadInWarpNV;// 當(dāng)前線程id，取值[0, gl_WarpSizeNV-1] in uint gl_ThreadEqMaskNV;// 是否等于當(dāng)前線程id的位域掩碼。 in uint gl_ThreadGeMaskNV;// 是否大于等于當(dāng)前線程id的位域掩碼。 in uint gl_ThreadGtMaskNV;// 是否大于當(dāng)前線程id的位域掩碼。 in uint gl_ThreadLeMaskNV;// 是否小于等于當(dāng)前線程id的位域掩碼。 in uint gl_ThreadLtMaskNV;// 是否小于當(dāng)前線程id的位域掩碼。 in bool gl_HelperThreadNV;// 當(dāng)前線程是否協(xié)助型線程。 上述所說的協(xié)助型線程gl_HelperThreadNV是指在處理2x2的像素塊時(shí)，那些未被圖元覆蓋的像素著色器線程將被標(biāo)記為gl_HelperThreadNV = true，它們的結(jié)果將被忽略，也不會(huì)被存儲(chǔ)，但可輔助一些計(jì)算，如導(dǎo)數(shù)dFdx和dFdy。為了防止理解有誤，貼出原文：

The variable gl_HelperThreadNV specifies if the current thread is a helper thread. In implementations supporting this extension, fragment shader invocations may be arranged in SIMD thread groups of 2x2 fragments called "quad". When a fragment shader instruction is executed on a quad, it\'s possible that some fragments within the quad will execute the instruction even if they are not covered by the primitive. Those threads are called helper threads. Their outputs will be discarded and they will not execute global store functions, but the intermediate values they compute can still be used by thread group sharing functions or by fragment derivative functions like dFdx and dFdy.

利用以上字段，可以編寫特殊shader代碼轉(zhuǎn)成顏色信息，以便可視化窺探GPU的工作機(jī)制和流程。 利用NV擴(kuò)展字段，可視化了頂點(diǎn)著色器、像素著色器的SM、Warp id，為我們查探GPU的工作機(jī)制和流程提供了途徑。 下面正式進(jìn)入驗(yàn)證階段，將以Geforce RTX 2060作為驗(yàn)證對(duì)象，具體信息如下：

操作系統(tǒng)：Windows 10 Pro, 64-bit DirectX 版本：12.0 GPU 處理器：GeForce RTX 2060 驅(qū)動(dòng)程序版本：417.71 Driver Type: Standard Direct3D API 版本：12 Direct3D 功能級(jí)別：12_1 CUDA 核心：1920 核心時(shí)鐘：1710 MHz 內(nèi)存數(shù)據(jù)速率：14.00 Gbps 內(nèi)存接口：192-位 內(nèi)存帶寬：336.05 GB/秒 全部可用的圖形內(nèi)存：22494MB 專用視頻內(nèi)存：6144 MB GDDR6 系統(tǒng)視頻內(nèi)存：0MB 共享系統(tǒng)內(nèi)存：16350MB 視頻 BIOS 版本：90.06.3F.00.73 IRQ：Not used 總線：PCI Express x16 Gen3

首先在應(yīng)用程序創(chuàng)建包含兩個(gè)三角形的頂點(diǎn)數(shù)據(jù)：

// set up vertex data (and buffer(s)) and configure vertex attributes const float HalfSize = 1.0f; float vertices[] = { -HalfSize, -HalfSize, 0.0f, // left bottom HalfSize, -HalfSize, 0.0f, // right bottom -HalfSize, HalfSize, 0.0f, // top left -HalfSize, HalfSize, 0.0f, // top left HalfSize, -HalfSize, 0.0f, // right bottom HalfSize, HalfSize, 0.0f, // top right }; 渲染采用的頂點(diǎn)著色器非常簡(jiǎn)單：#version 430 core layout (location = 0) in vec3 aPos; void main() { gl_Position = vec4(aPos, 1.0f); } 片元著色器也是寥寥數(shù)行：#version 430 core out vec4 FragColor; void main() { FragColor = vec4(1.0f, 0.5f, 0.2f, 1.0f); } 繪制出來的原始畫面如下： 緊接著，修改片元著色器，加入擴(kuò)展所需的代碼，并修改顏色計(jì)算：#version 430 core #extension GL_NV_shader_thread_group : require uniform uint gl_WarpSizeNV;// 單個(gè)線程束的線程數(shù)量 uniform uint gl_WarpsPerSMNV;// 單個(gè)SM的線程束數(shù)量 uniform uint gl_SMCountNV;// SM數(shù)量 in uint gl_WarpIDNV;// 當(dāng)前線程束id in uint gl_SMIDNV;// 當(dāng)前線程所在的SM id，取值[0, gl_SMCountNV-1] in uint gl_ThreadInWarpNV;// 當(dāng)前線程id，取值[0, gl_WarpSizeNV-1] out vec4 FragColor; void main() { // SM id float lightness = gl_SMIDNV / gl_SMCountNV; FragColor = vec4(lightness); } 從上面可分析出一些信息：

畫面共有32個(gè)亮度色階，也就是Geforce RTX 2060有32個(gè)SM。

單個(gè)SM每次渲染16x16為單位的像素塊，也就是每個(gè)SM有256個(gè)Core。

SM之間不是順序分配像素塊，而是無序分配。

不同三角形的接縫處出現(xiàn)斷層，說明同一個(gè)像素塊如果分屬不同的三角形，就會(huì)分配到不同的SM進(jìn)行處理。由此推斷，相同面積的區(qū)域，如果所屬的三角形越多，就會(huì)導(dǎo)致分配給SM的次數(shù)越多，消耗的渲染性能也越多。

接著修改片元著色器的顏色計(jì)算代碼以顯示W(wǎng)arp id：

// warp id float lightness = gl_WarpIDNV / gl_WarpsPerSMNV; FragColor = vec4(lightness); 由此可得出一些信息或推論：

畫面共有32個(gè)亮度色階，也就是每個(gè)SM有32個(gè)Warp，每個(gè)Warp有8個(gè)Core。

每個(gè)色塊像素是4x8，由于每個(gè)Warp有8個(gè)Core，由此推斷每個(gè)Core單次要處理2x2的最小單元像素塊。

也是無序分配像素塊。

三角形接縫處出現(xiàn)斷層，同SM的推斷一致。

再修改片元著色器的顏色計(jì)算代碼以顯示線程id：

// thread id float lightness = gl_ThreadInWarpNV / gl_WarpSizeNV; FragColor = vec4(lightness); 為了方便分析，用Photoshop對(duì)中間局部放大10倍，得到以下畫面： 也可以得出一些結(jié)論：

相較SM、線程束，線程分布圖比較規(guī)律。說明同一個(gè)Warp的線程分布是規(guī)律的。

三角形接縫處出現(xiàn)紊亂，說明是不同的Warp造成了不同的線程。

畫面有32個(gè)色階，說明單個(gè)Warp有32個(gè)線程。

每個(gè)像素獨(dú)占一個(gè)亮度色階，與周邊相鄰像素都不同，說明每個(gè)線程只處理一個(gè)像素。

再次說明，以上畫面和結(jié)論是基于Geforce RTX 2060，不同型號(hào)的GPU可能會(huì)不一樣，得到的結(jié)果和推論也會(huì)有所不同。 更多NV擴(kuò)展可參見OpenGL官網(wǎng)：NV extensions。

五、總結(jié)

5.1 CPU vs GPU

它們之間的差異（緩存、核心數(shù)量、內(nèi)存、線程數(shù)等）可用下圖展示出來：

5.2 渲染優(yōu)化建議

由上章的分析，可以很容易給出渲染優(yōu)化建議：

減少CPU和GPU的數(shù)據(jù)交換：

例如：glGetUniformLocation會(huì)從GPU內(nèi)存查詢狀態(tài)，耗費(fèi)很多時(shí)間周期。

避免每幀設(shè)置、查詢渲染狀態(tài)，可在初始化時(shí)緩存狀態(tài)。

CPU版的粒子、動(dòng)畫會(huì)每幀修改、提交數(shù)據(jù)，可移至GPU端。

BVH

Portal

BSP

OSP

合批（Batch）

減少頂點(diǎn)數(shù)、三角形數(shù)

視錐裁剪

避免每幀提交Buffer數(shù)據(jù)

減少渲染狀態(tài)設(shè)置和查詢

啟用GPU Instance

開啟LOD

避免從顯存讀數(shù)據(jù)

減少過繪制：

粒子數(shù)量多且面積小，由于像素塊機(jī)制，會(huì)加劇過繪制情況

植物、沙石、毛發(fā)等也如此

背面裁剪

遮擋裁剪

視口裁剪

剪切矩形（scissor rectangle）

Early-Z

層次Z緩沖（Hierarchical Z-Buffering，HZB）

避免Tex Kill操作

避免Alpha Test

避免Alpha Blend

開啟深度測(cè)試

開啟裁剪：

控制物體數(shù)量

Shader優(yōu)化：

避免if、switch分支語(yǔ)句

避免for循環(huán)語(yǔ)句，特別是循環(huán)次數(shù)可變的

減少紋理采樣次數(shù)

禁用clip或discard操作

減少?gòu)?fù)雜數(shù)學(xué)函數(shù)調(diào)用

更多優(yōu)化技巧可閱讀：

移動(dòng)游戲性能優(yōu)化通用技法。

GPU Programming Guide。

Real-Time Rendering Resources。

5.3 GPU的未來

從章節(jié)[2.2 GPU歷史](#2.2 GPU歷史)可以得出一些結(jié)論，也可以推測(cè)GPU發(fā)展的趨勢(shì)：

硬件升級(jí)。更多運(yùn)算單元，更多存儲(chǔ)空間，更高并發(fā)，更高帶寬，更低延時(shí)。。。

Tile-Based Rendering的集成。基于瓦片的渲染可以一定程度降低帶寬和提升光照計(jì)算效率，目前部分移動(dòng)端及桌面的GPU已經(jīng)引入這個(gè)技術(shù)，未來將有望成為常態(tài)。

3D內(nèi)存技術(shù)。目前大多數(shù)傳統(tǒng)的內(nèi)存是2D的，3D內(nèi)存則不同，在物理結(jié)構(gòu)上是3D的，類似立方體結(jié)構(gòu)，集成于芯片內(nèi)。可獲得幾倍的訪問速度和效能比。

GPU愈加可編程化。GPU天生是并行且相對(duì)固定的，未來將會(huì)開放越來越多的shader可供編程，而CPU剛好相反，將往并行化發(fā)展。也就是說，未來的GPU越來越像CPU，而CPU越來越像GPU。難道它們應(yīng)驗(yàn)了古語(yǔ)：合久必分，分久必合么？

實(shí)時(shí)光照追蹤的普及。基于Turing架構(gòu)的GPU已經(jīng)加入大量RT Core、HVB、AI降噪等技術(shù)，Hybrid Rendering Pipeline就是此架構(gòu)的光線追蹤渲染管線，能夠同時(shí)結(jié)合光柵化器、RT Core、Compute Core執(zhí)行混合渲染：

Hybrid Rendering Pipeline相當(dāng)于光線追蹤渲染管線和光柵化渲染管線的合體：

數(shù)據(jù)并發(fā)提升、深度神經(jīng)網(wǎng)絡(luò)、GPU計(jì)算單元等普及及提升。

AI降噪和AI抗鋸齒。AI降噪已經(jīng)在部分RTX系列的光線追蹤版本得到應(yīng)用，而AI抗鋸齒（Super Res）可用于超高分辨率的視頻圖像抗鋸齒：

基于任務(wù)和網(wǎng)格著色器的渲染管線。基于任務(wù)和網(wǎng)格著色器的渲染管線（Graphics Pipeline with Task and Mesh Shaders）與傳統(tǒng)的光柵化渲染光線有著很大的差異，它以線程組（Thread Group）、任務(wù)著色器（Task shader）和網(wǎng)格著色器（Mesh shader）為基礎(chǔ)，形成一種全新的渲染管線：

關(guān)于此技術(shù)的更多詳情可閱讀：NVIDIA Turing Architecture Whitepaper。

可變速率著色（Variable Rate Shading）。可變利率著色技術(shù)可判斷畫面區(qū)域的重要性（或由應(yīng)用程序指定），然后根據(jù)畫面區(qū)域的重要性程度采用不同的著色分辨率精度，可以顯著降低功耗，提高著色效率。

5.4 結(jié)語(yǔ)

本文系統(tǒng)地講解了GPU的歷史、發(fā)展、工作流程，以及部分過程的細(xì)化說明和用到的各種技術(shù)，我們從中可以看到GPU架構(gòu)的動(dòng)機(jī)、機(jī)制、瓶頸，以及未來的發(fā)展。 希望看完本文，大家能很好地回答導(dǎo)言提出的問題：1.3 帶著問題閱讀。如果不能全部回答，也沒關(guān)系，回頭看相關(guān)章節(jié)，總能找到答案。

如果想更深入地了解GPU的設(shè)計(jì)細(xì)節(jié)、實(shí)現(xiàn)細(xì)節(jié)，可閱讀GPU廠商定期發(fā)布的白皮書和各大高校、機(jī)構(gòu)發(fā)布的論文。推薦一個(gè)GPU解說視頻：A trip through the Graphics Pipeline 2011: Index，雖然是多年前的視頻，但比較系統(tǒng)、全面地講解了GPU的機(jī)制和技術(shù)。

審核編輯 ：李倩