一、導(dǎo)言
二、GPU概述
三、GPU物理架構(gòu)
四、GPU運行機制

4.1 GPU渲染總覽
4.2 GPU邏輯管線
4.3 GPU技術(shù)要點
4.4 GPU資源機制

4.4.1 內(nèi)存架構(gòu)
4.4.2 GPU Context和延遲
4.4.3 CPU-GPU異構(gòu)系統(tǒng)
4.4.4 GPU資源管理模型
4.4.5 CPU-GPU數(shù)據(jù)流
4.4.6 顯像機制

4.5 Shader運行機制
4.6 利用擴展例證

五、總結(jié)

5.1 CPU vs GPU
5.2 渲染優(yōu)化建議
5.3 GPU的未來
5.4 結(jié)語

參考文獻
特別說明

上篇：深入GPU硬件架構(gòu)及運行機制（上）

中篇：深入GPU硬件架構(gòu)及運行機制（中）

下載鏈接：

NVIDIA GPU架構(gòu)白皮書

1、NVIDIA A100 Tensor Core GPU技術(shù)白皮書

2、NVIDIA Kepler GK110-GK210架構(gòu)白皮書

3、NVIDIA Kepler GK110-GK210架構(gòu)白皮書

4、NVIDIA Kepler GK110架構(gòu)白皮書

5、NVIDIA Tesla P100技術(shù)白皮書

6、NVIDIA Tesla V100 GPU架構(gòu)白皮書

7、英偉達Turing GPU 架構(gòu)白皮書

GPU技術(shù)專題下載鏈接

《GPU高性能計算概述》

《GPU深度學(xué)習基礎(chǔ)介紹》

《OpenACC基本介紹》

《CUDA CC 編程介紹》

《CUDA Fortr基本介紹》

深度報告：GPU研究框架

CPU和GPU研究框架合集

4.4 GPU資源機制

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

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

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

它們的存取速度從寄存器到系統(tǒng)內(nèi)存依次變慢：

存儲類型

寄存器

共享內(nèi)存

L1緩存

L2緩存

紋理、常量緩存

全局內(nèi)存


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

由此可見，shader直接訪問寄存器、L1、L2緩存還是比較快的，但訪問紋理、常量緩存和全局內(nèi)存非常慢，會造成很高的延遲。

上面的多級緩存結(jié)構(gòu)可被稱為“CPU-Style”，還存在GPU-Style的內(nèi)存架構(gòu)：

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

4.4.2 GPU Context和延遲

由于SIMT技術(shù)的引入，導(dǎo)致很多同一個SM內(nèi)的很多Core并不是獨立的，當它們當中有部分Core需要訪問到紋理、常量緩存和全局內(nèi)存時，就會導(dǎo)致非常大的卡頓（Stall）。

例如下圖中，有4組上下文（Context），它們共用同一組運算單元ALU。

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

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

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

但是，越多Context可用就越可以提升運算單元的吞吐量，比如下圖的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各自有獨立的緩存和內(nèi)存，它們通過PCI-e等總線通訊。這種結(jié)構(gòu)的缺點在于 PCI-e 相對于兩者具有低帶寬和高延遲，數(shù)據(jù)的傳輸成了其中的性能瓶頸。目前使用非常廣泛，如PC、智能手機等。

上圖右是耦合式架構(gòu)，CPU 和 GPU 共享內(nèi)存和緩存。AMD 的 APU 采用的就是這種結(jié)構(gòu)，目前主要使用在游戲主機中，如 PS4。

在存儲管理方面，分離式結(jié)構(gòu)中 CPU 和 GPU 各自擁有獨立的內(nèi)存，兩者共享一套虛擬地址空間，必要時會進行內(nèi)存拷貝。對于耦合式結(jié)構(gòu)，GPU 沒有獨立的內(nèi)存，與 GPU 共享系統(tǒng)內(nèi)存，由 MMU 進行存儲管理。

4.4.4 GPU資源管理模型

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

MMIO（Memory Mapped IO）

CPU與GPU的交流就是通過MMIO進行的。CPU 通過 MMIO 訪問 GPU 的寄存器狀態(tài)。
DMA傳輸大量的數(shù)據(jù)就是通過MMIO進行命令控制的。
I/O端口可用于間接訪問MMIO區(qū)域，像Nouveau等開源軟件從來不訪問它。

GPU Context

GPU Context代表了GPU計算的狀態(tài)。
在GPU中擁有自己的虛擬地址。
GPU 中可以并存多個活躍態(tài)下的Context。

GPU Channel

任何命令都是由CPU發(fā)出。
命令流（command stream）被提交到硬件單元，也就是GPU Channel。
每個GPU Channel關(guān)聯(lián)一個context，而一個GPU Context可以有多個GPU channel。
每個GPU Context 包含相關(guān)channel的 GPU Channel Descriptors ，每個 Descriptor 都是 GPU 內(nèi)存中的一個對象。
每個 GPU Channel Descriptor 存儲了 Channel 的設(shè)置，其中就包括 Page Table 。
每個 GPU Channel 在GPU內(nèi)存中分配了唯一的命令緩存，這通過MMIO對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總線接入到主機上。Base Address Registers(BARs) 是 MMIO的窗口，在GPU啟動時候配置。
GPU的控制寄存器和內(nèi)存都映射到了BARs中。
GPU設(shè)備內(nèi)存通過映射的MMIO窗口去配置GPU和訪問GPU內(nèi)存。

PFIFO Engine

PFIFO是GPU命令提交通過的一個特殊的部件。
PFIFO維護了一些獨立命令隊列，也就是Channel。
此命令隊列是Ring Buffer，有PUT和GET的指針。
所有訪問Channel控制區(qū)域的執(zhí)行指令都被PFIFO 攔截下來。
GPU驅(qū)動使用Channel Descriptor來存儲相關(guān)的Channel設(shè)定。
PFIFO將讀取的命令轉(zhuǎn)交給PGRAPH Engine。

Buffer Object (BO)，內(nèi)存的一塊(Block)，能夠用于存儲紋理（Texture）、渲染目標（Render Target）、著色代碼（shader code）等等。
Nouveau和Gdev經(jīng)常使用BO。
Nouveau是一個自由及開放源代碼顯卡驅(qū)動程序，是為NVidia的顯卡所編寫。
Gdev是一套豐富的開源軟件，用于NVIDIA的GPGPU技術(shù)，包括設(shè)備驅(qū)動程序。

更多詳細可以閱讀論文：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ū)動GPU。

3、GPU中的每個運算單元并行處理。此步會從顯存存取數(shù)據(jù)。

4、GPU將顯存結(jié)果傳回主存。

4.4.6 顯像機制

水平和垂直同步信號
在早期的CRT顯示器，電子槍從上到下逐行掃描，掃描完成后顯示器就呈現(xiàn)一幀畫面。然后電子槍回到初始位置進行下一次掃描。為了同步顯示器的顯示過程和系統(tǒng)的視頻控制器，顯示器會用硬件時鐘產(chǎn)生一系列的定時信號。
當電子槍換行進行掃描時，顯示器會發(fā)出一個水平同步信號（horizonal synchronization），簡稱 HSync
當一幀畫面繪制完成后，電子槍回復(fù)到原位，準備畫下一幀前，顯示器會發(fā)出一個垂直同步信號（vertical synchronization），簡稱 VSync。
顯示器通常以固定頻率進行刷新，這個刷新率就是 VSync 信號產(chǎn)生的頻率。雖然現(xiàn)在的顯示器基本都是液晶顯示屏了，但其原理基本一致。
CPU將計算好顯示內(nèi)容提交至 GPU，GPU 渲染完成后將渲染結(jié)果存入幀緩沖區(qū)，視頻控制器會按照 VSync 信號逐幀讀取幀緩沖區(qū)的數(shù)據(jù)，經(jīng)過數(shù)據(jù)轉(zhuǎn)換后最終由顯示器進行顯示。
雙緩沖
在單緩沖下，幀緩沖區(qū)的讀取和刷新都都會有比較大的效率問題，經(jīng)常會出現(xiàn)相互等待的情況，導(dǎo)致幀率下降。
為了解決效率問題，GPU 通常會引入兩個緩沖區(qū)，即 雙緩沖機制。在這種情況下，GPU 會預(yù)先渲染一幀放入一個緩沖區(qū)中，用于視頻控制器的讀取。當下一幀渲染完畢后，GPU 會直接把視頻控制器的指針指向第二個緩沖器。
垂直同步
雙緩沖雖然能解決效率問題，但會引入一個新的問題。當視頻控制器還未讀取完成時，即屏幕內(nèi)容剛顯示一半時，GPU 將新的一幀內(nèi)容提交到幀緩沖區(qū)并把兩個緩沖區(qū)進行交換后，視頻控制器就會把新的一幀數(shù)據(jù)的下半段顯示到屏幕上，造成畫面撕裂現(xiàn)象：
為了解決這個問題，GPU 通常有一個機制叫做垂直同步（簡寫也是V-Sync），當開啟垂直同步后，GPU 會等待顯示器的 VSync 信號發(fā)出后，才進行新的一幀渲染和緩沖區(qū)更新。這樣能解決畫面撕裂現(xiàn)象，也增加了畫面流暢度，但需要消費更多的計算資源，也會帶來部分延遲。

4.5 Shader運行機制

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

由高級語言編譯成匯編指令的過程通常是在離線階段執(zhí)行，以減輕運行時的消耗。

在執(zhí)行階段，CPU端將shader二進制指令經(jīng)由PCI-e推送到GPU端，GPU在執(zhí)行代碼時，會用Context將指令分成若干Channel推送到各個Core的存儲空間。

對現(xiàn)代GPU而言，可編程的階段越來越多，包含但不限于：頂點著色器（Vertex Shader）、曲面細分控制著色器（Tessellation Control Shader）、幾何著色器（Geometry Shader）、像素/片元著色器（Fragment Shader）、計算著色器（Compute Shader）、...

這些著色器形成流水線式的并行化的渲染管線。下面將配合具體的例子說明。

下段是計算漫反射的經(jīng)典代碼：

sampler mySamp;
Texture2D<float3> 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)過編譯后成為匯編代碼：

<diffuseShader>:
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í)行階段，以上匯編代碼會被GPU推送到執(zhí)行上下文（Execution Context），然后ALU會逐條獲?。―etch）、解碼（Decode）匯編指令，并執(zhí)行它們。

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

對于SIMT架構(gòu)的GPU，匯編指令有所不同，變成了SIMT特定指令代碼：

<VEC8_diffuseShader>: 
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)，同一個Core的多個ALU共享一組Context：

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

4.6 利用擴展例證

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

OpenGL 4.3+；
GLSL 4.3+；
支持OpenGL 4.3+的NV顯卡；

并且此擴展只在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

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

// 開啟擴展
#extension GL_NV_shader_thread_group : require     (or enable)

WARP_SIZE_NV	// 單個線程束的線程數(shù)量
WARPS_PER_SM_NV	// 單個SM的線程束數(shù)量
SM_COUNT_NV		// SM數(shù)量

uniform uint  gl_WarpSizeNV;	// 單個線程束的線程數(shù)量
uniform uint  gl_WarpsPerSMNV;	// 單個SM的線程束數(shù)量
uniform uint  gl_SMCountNV;		// SM數(shù)量

in uint  gl_WarpIDNV;		// 當前線程束id
in uint  gl_SMIDNV;			// 當前線程束所在的SM id，取值[0, gl_SMCountNV-1]
in uint  gl_ThreadInWarpNV;	// 當前線程id，取值[0, gl_WarpSizeNV-1]

in uint  gl_ThreadEqMaskNV;	// 是否等于當前線程id的位域掩碼。
in uint  gl_ThreadGeMaskNV;	// 是否大于等于當前線程id的位域掩碼。
in uint  gl_ThreadGtMaskNV;	// 是否大于當前線程id的位域掩碼。
in uint  gl_ThreadLeMaskNV;	// 是否小于等于當前線程id的位域掩碼。
in uint  gl_ThreadLtMaskNV;	// 是否小于當前線程id的位域掩碼。

in bool  gl_HelperThreadNV;	// 當前線程是否協(xié)助型線程。

上述所說的協(xié)助型線程gl_HelperThreadNV是指在處理2x2的像素塊時，那些未被圖元覆蓋的像素著色器線程將被標記為gl_HelperThreadNV = true，它們的結(jié)果將被忽略，也不會被存儲，但可輔助一些計算，如導(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的工作機制和流程。

利用NV擴展字段，可視化了頂點著色器、像素著色器的SM、Warp id，為我們查探GPU的工作機制和流程提供了途徑。

下面正式進入驗證階段，將以Geforce RTX 2060作為驗證對象，具體信息如下：

操作系統(tǒng)：Windows 10 Pro, 64-bit
DirectX 版本：12.0
GPU 處理器：GeForce RTX 2060
驅(qū)動程序版本：417.71
Driver Type: Standard
Direct3D API 版本：12
Direct3D 功能級別：12_1
CUDA 核心：1920
核心時鐘：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)建包含兩個三角形的頂點數(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
};

渲染采用的頂點著色器非常簡單：

#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);
}

繪制出來的原始畫面如下：

緊接著，修改片元著色器，加入擴展所需的代碼，并修改顏色計算：

#version 430 core
#extension GL_NV_shader_thread_group : require

uniform uint  gl_WarpSizeNV;	// 單個線程束的線程數(shù)量
uniform uint  gl_WarpsPerSMNV;	// 單個SM的線程束數(shù)量
uniform uint  gl_SMCountNV;		// SM數(shù)量

in uint  gl_WarpIDNV;		// 當前線程束id
in uint  gl_SMIDNV;			// 當前線程所在的SM id，取值[0, gl_SMCountNV-1]
in uint  gl_ThreadInWarpNV;	// 當前線程id，取值[0, gl_WarpSizeNV-1]

out vec4 FragColor;

void main()
{
	// SM id
	float lightness = gl_SMIDNV / gl_SMCountNV;
	FragColor = vec4(lightness);
}

從上面可分析出一些信息：

畫面共有32個亮度色階，也就是Geforce RTX 2060有32個SM。
單個SM每次渲染16x16為單位的像素塊，也就是每個SM有256個Core。
SM之間不是順序分配像素塊，而是無序分配。
不同三角形的接縫處出現(xiàn)斷層，說明同一個像素塊如果分屬不同的三角形，就會分配到不同的SM進行處理。由此推斷，相同面積的區(qū)域，如果所屬的三角形越多，就會導(dǎo)致分配給SM的次數(shù)越多，消耗的渲染性能也越多。

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

// warp id
float lightness = gl_WarpIDNV / gl_WarpsPerSMNV;
FragColor = vec4(lightness);

由此可得出一些信息或推論：

畫面共有32個亮度色階，也就是每個SM有32個Warp，每個Warp有8個Core。
每個色塊像素是4x8，由于每個Warp有8個Core，由此推斷每個Core單次要處理2x2的最小單元像素塊。
也是無序分配像素塊。
三角形接縫處出現(xiàn)斷層，同SM的推斷一致。

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

// thread id
float lightness = gl_ThreadInWarpNV / gl_WarpSizeNV;
FragColor = vec4(lightness);

為了方便分析，用Photoshop對中間局部放大10倍，得到以下畫面：

也可以得出一些結(jié)論：

相較SM、線程束，線程分布圖比較規(guī)律。說明同一個Warp的線程分布是規(guī)律的。
三角形接縫處出現(xiàn)紊亂，說明是不同的Warp造成了不同的線程。
畫面有32個色階，說明單個Warp有32個線程。
每個像素獨占一個亮度色階，與周邊相鄰像素都不同，說明每個線程只處理一個像素。

再次說明，以上畫面和結(jié)論是基于Geforce RTX 2060，不同型號的GPU可能會不一樣，得到的結(jié)果和推論也會有所不同。

更多NV擴展可參見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會從GPU內(nèi)存查詢狀態(tài)，耗費很多時間周期。
避免每幀設(shè)置、查詢渲染狀態(tài)，可在初始化時緩存狀態(tài)。
CPU版的粒子、動畫會每幀修改、提交數(shù)據(jù)，可移至GPU端。
BVH
Portal
BSP
OSP
合批（Batch）
減少頂點數(shù)、三角形數(shù)
視錐裁剪
避免每幀提交Buffer數(shù)據(jù)
減少渲染狀態(tài)設(shè)置和查詢
啟用GPU Instance
開啟LOD
避免從顯存讀數(shù)據(jù)

減少過繪制：

粒子數(shù)量多且面積小，由于像素塊機制，會加劇過繪制情況
植物、沙石、毛發(fā)等也如此
背面裁剪
遮擋裁剪
視口裁剪
剪切矩形（scissor rectangle）
Early-Z
層次Z緩沖（Hierarchical Z-Buffering，HZB）
避免Tex Kill操作
避免Alpha Test
避免Alpha Blend
開啟深度測試
開啟裁剪：
控制物體數(shù)量

Shader優(yōu)化：

避免if、switch分支語句
避免for循環(huán)語句，特別是循環(huán)次數(shù)可變的
減少紋理采樣次數(shù)
禁用clip或discard操作
減少復(fù)雜數(shù)學(xué)函數(shù)調(diào)用

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

移動游戲性能優(yōu)化通用技法。
GPU Programming Guide。
Real-Time Rendering Resources。

5.3 GPU的未來

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

硬件升級。更多運算單元，更多存儲空間，更高并發(fā)，更高帶寬，更低延時。。。
Tile-Based Rendering的集成?；谕咂匿秩究梢砸欢ǔ潭冉档蛶捄吞嵘庹沼嬎阈?，目前部分移動端及桌面的GPU已經(jīng)引入這個技術(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天生是并行且相對固定的，未來將會開放越來越多的shader可供編程，而CPU剛好相反，將往并行化發(fā)展。也就是說，未來的GPU越來越像CPU，而CPU越來越像GPU。難道它們應(yīng)驗了古語：合久必分，分久必合么？
實時光照追蹤的普及?；赥uring架構(gòu)的GPU已經(jīng)加入大量RT Core、HVB、AI降噪等技術(shù)，Hybrid Rendering Pipeline就是此架構(gòu)的光線追蹤渲染管線，能夠同時結(jié)合光柵化器、RT Core、Compute Core執(zhí)行混合渲染：
Hybrid Rendering Pipeline相當于光線追蹤渲染管線和光柵化渲染管線的合體：
數(shù)據(jù)并發(fā)提升、深度神經(jīng)網(wǎng)絡(luò)、GPU計算單元等普及及提升。
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）?？勺兝手夹g(shù)可判斷畫面區(qū)域的重要性（或由應(yīng)用程序指定），然后根據(jù)畫面區(qū)域的重要性程度采用不同的著色分辨率精度，可以顯著降低功耗，提高著色效率。

5.4 結(jié)語

本文系統(tǒng)地講解了GPU的歷史、發(fā)展、工作流程，以及部分過程的細化說明和用到的各種技術(shù)，我們從中可以看到GPU架構(gòu)的動機、機制、瓶頸，以及未來的發(fā)展。

希望看完本文，大家能很好地回答導(dǎo)言提出的問題：1.3 帶著問題閱讀。如果不能全部回答，也沒關(guān)系，回頭看相關(guān)章節(jié)，總能找到答案。

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

作者：0向往0

博客地址：

https://www.cnblogs.com/timlly/p/11471507.html

參考文獻