Zaawansowane programowanie GPU.pdf - Drobot.org
Zaawansowane programowanie GPU.pdf - Drobot.org
Zaawansowane programowanie GPU.pdf - Drobot.org
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Programowanie <strong>GPU</strong><br />
Michał <strong>Drobot</strong><br />
<strong>Drobot</strong>.<strong>org</strong>
Poznanie <strong>GPU</strong><br />
Jak to działa?<br />
Język (GLSL/HLSL)<br />
Optymalny kod
Architektura współczesnego <strong>GPU</strong><br />
S IMD – konsekwencje<br />
S truktura<br />
Pipeline<br />
Obsługa <strong>GPU</strong> w oparciu o S M 3.0<br />
Praktyki programistyczne<br />
Podstawy prawidłowego kodowania w oparciu<br />
o znajomość architektury i sprzętu
Architektura <strong>GPU</strong><br />
<strong>GPU</strong> – Graphic Processing Unit<br />
R ównoległa architektura S IMD<br />
Komputer wektorowy (4 skalarne wektory)<br />
<strong>GPU</strong> vs Multicore CPU<br />
<strong>GPU</strong> – olbrzymia ilość lekkich wątków, szybkie przez<br />
równoległość, powolne pojedynczo<br />
CPU – mała liczba ciężkich wątków, szybkie<br />
pojedynczo<br />
<strong>GPU</strong> dobre w rozwiązywaniu problemów<br />
równoległych, strumieniowych pamięciowo,<br />
ciężkich arytmetycznie
Architektura <strong>GPU</strong><br />
Podstawowe jednostki sprzętowe<br />
ALU<br />
Texture S amplers<br />
Jednostki wykonawcze wątków<br />
▪ Vertex Processing Unit<br />
▪ Pixel Processing Unit<br />
▪ Unified Thread Processor<br />
Pamięć DR AM
Architektura <strong>GPU</strong><br />
Obiekty w pamieci<br />
Buffered Objects<br />
Uniform R egisters/S tate Table<br />
Interpolated R egisters<br />
Temporary R egisters<br />
Textures
Architektura <strong>GPU</strong><br />
Buffered Objects<br />
S trumienie danych generowane przez CPU<br />
Ograniczona modyfikowalność<br />
Przykład<br />
▪ dane Vertexów obiektu
Architektura <strong>GPU</strong><br />
Uniform R egisters/S tate Table<br />
S tałe podczas działania potoku<br />
▪ Przekazywane względem poligonu<br />
rejestry dowolnego przeznaczenia (16 INT,<br />
224 Float)<br />
R ejestry Tablic S tanu<br />
▪ Macierze<br />
▪ Ś wiatła<br />
▪ Itp… .
Architektura <strong>GPU</strong><br />
Interpolated R egisters<br />
Dane opisujące poligon dostępne dla vertexa<br />
Posiadają dane interpolowane wzdłuż<br />
poligonu<br />
10 interpolatorów dowolnego przeznaczenia
Architektura <strong>GPU</strong><br />
Temporary R egisters<br />
Typowa reprezentacja rejestrów<br />
Tymczasowe rejestry obliczeń chwilowych
Architektura <strong>GPU</strong><br />
Textures<br />
Pojęciowo bliskie tablicom typu RAM<br />
▪ Nie można naraz czytać/pisać<br />
Kosztowne w dostępie<br />
▪ Wykorzystują samplery hardware’owe<br />
▪ Wyjątkowo kosztowne odczyty zależne
Pipeline<br />
Aplikacja<br />
Geometria<br />
Generuje dane 3D, wywołuje funkcje api,<br />
przekazuje dane do <strong>GPU</strong><br />
Transformacja 3D->2D<br />
[równoległe / vertex shader]<br />
Rasteryzacja<br />
Generowanie fragmentów z geometrii<br />
[równoległe / pixel shader]<br />
Kompozycja<br />
Łączenie fragmentów w obraz<br />
<strong>GPU</strong>
Pipeline
Pipeline<br />
Dx 10 / OGl 3.0
Pipeline<br />
6th generation <strong>GPU</strong>
Pipeline<br />
8th generation <strong>GPU</strong>
Pipeline - Shaders<br />
S haders<br />
Operacje na:<br />
▪ Macierzach<br />
▪ Wektorach<br />
Tablice stałe<br />
Zmienne powiązane z <strong>GPU</strong><br />
Podział danych:<br />
▪ Per-instance – np.. Per-vertex position<br />
▪ Per-pixel interpolated – np.. Koordynaty UV<br />
▪ Per-batch – np… dane zewnętrzne dt. światła
Pipeline – Shaders (VS 3.0)<br />
Transformacje do płaszczyzny przycięcia<br />
= clip-space<br />
Input:<br />
Vertex pos<br />
Tex coord<br />
Constant<br />
Dodatkowe kanały : fog, color itp..<br />
Output – wyjście przekazuje do pixel<br />
shader<br />
Vertex shader działa raz per vertex
Pipeline – Shaders (VS 3.0)<br />
Vertex Stream – 16 rejestrów<br />
v0<br />
v1 v2 v15<br />
32 rejestry tymczasowe<br />
r0 r1 r2 r31<br />
>256F & 16int - const<br />
c0 c1 c2 cN<br />
aL<br />
a0<br />
Rejestr<br />
Pętli<br />
Rejestr<br />
Adresu<br />
Vertex<br />
Shader<br />
12 Rejestrów wyjścia<br />
oPos<br />
position<br />
oTn<br />
Tex coord<br />
oPts
Pipeline – Shaders (PS 3.0)<br />
Ustala wyjściowy kolor pixela<br />
S amplowanie<br />
Operacje na pixelach<br />
Input<br />
Interpolowane wyjście z VS<br />
Podstawowe rejestry z VS : vertex: pos, normal, tex<br />
coors , etc.<br />
R ejestry dowolnego przeznaczenia<br />
Output<br />
Wektor R /G/B/A koloru<br />
Depth – głębia wg ustaleń R ender S tate<br />
Pixel shader uruchamiany raz dla każdego<br />
pixela
Pipeline – Shaders (PS 3.0)<br />
Pixel Stream – 10 rejestrów<br />
v0 v1 v2 v9<br />
32 rejestry tymczasowe<br />
r0 r1 r2 r31<br />
>256F & 16int - const<br />
c0 c1 c2 cN<br />
16 Rejestrów Samplerów<br />
s0 s1 s2 s15<br />
Pixel<br />
Shader<br />
aL<br />
a0<br />
Wyjście dla 4 kanałów<br />
oC0<br />
oC1<br />
oC2<br />
oC3<br />
oDepth
Pipeline<br />
Istniejące potoki (pipeline’y)<br />
Ustalony - Fixed<br />
▪ Konfigurowalny, nie programowalny<br />
Programowalne shadery - Programmable<br />
shaders<br />
▪ Centrowany na shadery<br />
▪ Programowalne shadery, lecz ustalony potok<br />
Programowalny potok<br />
▪ W pełni progrmowalny przepływ danych na <strong>GPU</strong>
Pipeline<br />
Dodatkowe elementy potoku<br />
Vertex cache<br />
Texture cache<br />
Z-buffer<br />
▪ E arly-Z<br />
S tencil<br />
Branch processor – >= S M 3.0
Pipeline<br />
Vertex cache<br />
Cache pamięci na vertexy<br />
Przeważnie liniowy długoś ci 256 bits<br />
Dos tępny globalnie dla ws zys tkich vertex<br />
fetchy
Pipeline<br />
Texture cache<br />
Liniowy o długości 32K<br />
▪ Współdzielony / segmentowany między wszystkie<br />
samplery<br />
▪ M ultitexturing niszczy cache<br />
▪ Naraz odczytuje jedynie pojedynczy sektor w<br />
pobliżu aktualnej operacji<br />
▪ Odczyty zależne niszczą cache<br />
▪ Przechowuje dane w liniach o określonej długości<br />
▪ S egmentuje tablice na małe bloki używane przy<br />
cache’owaniu
Pipeline<br />
Z-buffer<br />
Dodatkowy bufor karty graficznej przechowujący<br />
głębie każdego pixela<br />
Używany w rozwiązywaniu problemu widoczności<br />
pixela przy zapisywaniu do bufora ramki<br />
▪ Algorytm malarza<br />
Aktualna głębia pixela jest sprawdzana z głebią<br />
zapisana w Z-buforze, jeśli jest większa pixel nie jest<br />
rysowany<br />
Obecnie 24b lub 32b o skali log<br />
▪ Problematyka artefaktów<br />
▪ Z-Fighting<br />
Obsługa parametryczna, sprzętowa, nie<br />
programowalna
Pipeline<br />
Z-buffer<br />
E arly-Z<br />
▪ Naturalne rozwinięcie Z-bufora<br />
▪ Podczas budowania Z, dokonuje testu<br />
▪ Odpalany przed wykonaniem R asteryzacji<br />
▪ Posiada wartość Z pixela z Vertex S hadera<br />
▪ Może być wykorzystywany jako świadoma optymalizacja<br />
▪ Depth pre-pass<br />
▪ Front – to – Back sorting<br />
Obsługa parametryczna, sprzętowa, nie<br />
programowalna
Pipeline<br />
S tencil<br />
Dodatkowy bufor używany wraz z buforem Z<br />
S łuży dodatkowych testom odrzucania pixeli<br />
Można do niego pisać i wykorzystywać przy<br />
optymalizacji<br />
Obsługa parametryczna, sprzętowa, nie<br />
programowalna
Pipeline<br />
R ender state<br />
S tany sprzętowe <strong>GPU</strong><br />
▪ Z-test<br />
▪ S tencil<br />
▪ Culling<br />
▪ Blending<br />
Parametryzują wewnętrzne sprzętowe<br />
systemy optymalizacji
Pipeline<br />
Branch processor (>= S M 3.0)<br />
Umożliwia wprowadzenie architektury M IMD<br />
Operacje na fragmentach są przeprowadzane w<br />
bloczkach (np. 32x32, 8x8 , 2x2)<br />
▪ Każdy z bloczków za pomocą Branch processora i tzw. Flow<br />
control może wykonać odmienną ścieżkę wykonawczą<br />
▪ Jeśli którykolwiek texel z bloczku musi wybrać odmienną<br />
drogę od innych ,obliczenia są wykonywane dla wszystkich<br />
texeli i wszystkich dróg<br />
▪ Wprowadza fizyczną obsługę dynamicznych if, else, for, while<br />
itp.<br />
Narzut obliczeniowy < 6 cykli
Języki<br />
GLS L<br />
HLS L<br />
C G<br />
Wszystkie są podobne składniowo<br />
R óżnice występują jedynie na poziomie<br />
składniowym kilku funkcji<br />
▪ Np.. Lerp (HLS L) = mix(GLS L), float4 = vec4 etc.<br />
HLS L > CG > GLS L
Języki<br />
Języki przygotowane do obliczeń wektorowych<br />
Podstawowe typy<br />
▪ Float<br />
▪ Float2, float3, float4 / vec2, vec3, vec4<br />
▪ Float4x4 / mat4<br />
Operacje wektorowe ALU<br />
▪ Dot<br />
▪ Mul<br />
▪ Normalize<br />
▪ Lerp / mix<br />
▪ C lamp
Języki<br />
Obsługa samplerów<br />
tex2D / texture2D<br />
texCube / textureCube<br />
tex3D / texture3D<br />
Filtrowanie<br />
▪ POINT<br />
▪ LINE AR<br />
▪ ANIZO<br />
▪ E tc.
Języki<br />
Dyrektywy kompilatora<br />
Asm<br />
Flow control<br />
▪ [loop]<br />
▪ [flatten]<br />
▪ [branch]<br />
▪ E tc.<br />
Zapoznać się z możliwościami języków<br />
Google<br />
OGL consorcium<br />
MS DN<br />
Nvidia developer<br />
Ati developer
Praktyki programistyczne<br />
Zalecenia ogólne<br />
S tosunek ALU:Tex S amplers > 5:1<br />
▪ Jeśli to możliwe odczyty z textury zastąpić arytmetyką<br />
Liczba vertexów
Praktyki programistyczne<br />
Zagadka ;]<br />
#R1 = (x,y,z)<br />
DP3 R0.w, R1, R1;<br />
RSQ R0.w, R0.w;<br />
MUL R0.xyz , R1 , R0.w;
Praktyki programistyczne<br />
Zalecenia dla vertex shaderów<br />
Usuwać nieużywane interpolatory oraz<br />
rejestry ogólnego przeznaczenia<br />
Jeśli to możliwe używać wczesnego<br />
odrzucania<br />
Zalecenia dla pixel shaderów<br />
Texture sampling<br />
▪ Unikać zależnych odczytów textur<br />
▪ Unikać samplowania dużych obszarów (cache)<br />
▪ Korzystać właściwie z własności samplera<br />
(POINT/LINNE AR )
Praktyki programistyczne<br />
Branching<br />
Zaawansowana problematyka umożliwiająca wzrost<br />
prędkości o rzędy wielkości jak i również spowolnienie<br />
przetwarzania<br />
Podobieństwo w optymalizacji programów na CPU<br />
▪ S truktury wyboru drogi<br />
▪ If – else<br />
Dodatkowe utrudnienie wynikające z równoległości<br />
przetwarzania danych<br />
Dokładne omówienie być może kiedyś ;]
Praktyki programistyczne<br />
<br />
Jeśli wszystko zawiedzie<br />
Używać wstawek asm w miejscach szczególnie wrażliwych<br />
wydajnościowo<br />
▪ For, while etc…<br />
S prawdzić kod asm tworzony przez kompilator<br />
▪ Niestety często dochodzi do błędów i mało wydajnej optymalizacji<br />
▪ Poprawić w asm<br />
Używać dyrektyw kompilacji<br />
▪ Optymalizacij<br />
▪ Isolate<br />
▪ Call / Inline<br />
▪ Unrolll<br />
▪ loop<br />
▪ Flow control<br />
▪ Branch<br />
▪ flatten
Plan wykładów<br />
Architektura oraz optymalizacja shaderów<br />
Modelowanie właściwości fizycznych<br />
materiałów<br />
Obliczenia na texturach / tablicach<br />
Wprowadzenie – obsługa render targetów<br />
Post processing obrazu – metody i praktyki<br />
GP<strong>GPU</strong> – obliczenia ogólnego zastosowania<br />
na <strong>GPU</strong>
Punktacja etapu ‘rozbudowy’<br />
Do zdobycia 10 (+2) pkt<br />
5 pkt<br />
▪ Wybranie 3 materiałów a następnie wymodelowanie ich oraz<br />
zintegrowanie z frameworkiem<br />
▪ Wybierane z puli materiałów<br />
▪ 2 proste , 1 średni<br />
▪ Dodatkowo do +1 pkt za zaawansowany materiał<br />
5 pkt<br />
▪ Integracja modułu obsługi render targetów<br />
▪ Wprowadzenie 3 efektów post processingu<br />
▪ Wybierane z puli efektów<br />
▪ 2 proste, 1 średni<br />
▪ Dodatkowo do +1 pkt za zaawansowany efekt
Punktacja etapu ‘rozbudowy’<br />
S hadery będą oceniane pod względem<br />
Przejrzystości<br />
Wydajności (optymalizacji)<br />
Prawidłowego efektu<br />
Zastosowanej metody<br />
Pomysłowości<br />
Zastrzegam możliwość rozmowy nt.<br />
konkretnego rozwiązania, jego zasadności<br />
oraz zrozumienia zagadnienia
Michał <strong>Drobot</strong><br />
<strong>Drobot</strong>.<strong>org</strong>
Change language