Pracownia Gier w OpenGL Programowanie GPU Pracownia Gier w OpenGL Michał Drobot Drobot.org

Cel Poznanie GPU Jak to działa? Język (GLSL/HLSL) Optymalny kod

Plan Architektura współczesnego GPU Pipeline SIMD – konsekwencje Struktura Pipeline Obsługa GPU w oparciu o SM 3.0 Praktyki programistyczne Podstawy prawidłowego kodowania w oparciu o znajomość architektury i sprzętu

Architektura GPU GPU – Graphic Processing Unit Równoległa architektura SIMD Komputer wektorowy (4 skalarne wektory) GPU vs Multicore CPU GPU – olbrzymia ilość lekkich wątków, szybkie przez równoległość, powolne pojedynczo CPU – mała liczba ciężkich wątków, szybkie pojedynczo GPU dobre w rozwiązywaniu problemów równoległych, strumieniowych pamięciowo, ciężkich arytmetycznie

Architektura GPU Podstawowe jednostki sprzętowe ALU Texture Samplers Jednostki wykonawcze wątków Vertex Processing Unit Pixel Processing Unit Unified Thread Processor Pamięć DRAM

Architektura GPU Obiekty w pamieci Buffered Objects Uniform Registers/State Table Interpolated Registers Temporary Registers Textures

Architektura GPU Buffered Objects Strumienie danych generowane przez CPU Ograniczona modyfikowalność Przykład dane Vertexów obiektu

Architektura GPU Uniform Registers/State Table Stałe podczas działania potoku Przekazywane względem poligonu rejestry dowolnego przeznaczenia (16 INT, 224 Float) Rejestry Tablic Stanu Macierze Światła Itp….

Architektura GPU Interpolated Registers Dane opisujące poligon dostępne dla vertexa Posiadają dane interpolowane wzdłuż poligonu 10 interpolatorów dowolnego przeznaczenia

Architektura GPU Temporary Registers Typowa reprezentacja rejestrów Tymczasowe rejestry obliczeń chwilowych

Architektura GPU Textures Pojęciowo bliskie tablicom typu RAM Nie można naraz czytać/pisać Kosztowne w dostępie Wykorzystują samplery hardware’owe Wyjątkowo kosztowne odczyty zależne

Pipeline Aplikacja Geometria Rasteryzacja Kompozycja GPU Generuje dane 3D, wywołuje funkcje api, przekazuje dane do GPU GPU Geometria Transformacja 3D->2D [równoległe / vertex shader] Rasteryzacja Generowanie fragmentów z geometrii [równoległe / pixel shader] Kompozycja Łączenie fragmentów w obraz

Pipeline

Pipeline Dx 10 / OGl 3.0

Pipeline 6th generation GPU

Pipeline 8th generation GPU

Pipeline - Shaders Shaders Operacje na: Tablice stałe Macierzach Wektorach Tablice stałe Zmienne powiązane z GPU Podział danych: Per-instance – np.. Per-vertex position Per-pixel interpolated – np.. Koordynaty UV Per-batch – np…dane zewnętrzne dt. światła

Pipeline – Shaders (VS 3.0) Transformacje do płaszczyzny przycięcia = clip-space Input: Vertex pos Tex coord Constant Dodatkowe kanały : fog, color itp.. Output – wyjście przekazuje do pixel shader Vertex shader działa raz per vertex

Pipeline – Shaders (VS 3.0) Vertex Stream – 16 rejestrów v0 v1 v2 v15 oPos 32 rejestry tymczasowe position Vertex Shader r0 r1 r2 r31 oTn >256F & 16int - const 12 Rejestrów wyjścia Tex coord c0 c1 c2 cN aL a0 oPts Rejestr Pętli Rejestr Adresu

Pipeline – Shaders (PS 3.0) Ustala wyjściowy kolor pixela Samplowanie Operacje na pixelach Input Interpolowane wyjście z VS Podstawowe rejestry z VS : vertex: pos, normal, tex coors , etc. Rejestry dowolnego przeznaczenia Output Wektor R/G/B/A koloru Depth – głębia wg ustaleń Render State Pixel shader uruchamiany raz dla każdego pixela

Pipeline – Shaders (PS 3.0) Pixel Stream – 10 rejestrów v0 v1 v2 v9 oC0 32 rejestry tymczasowe oC1 Pixel Shader r0 r1 r2 r31 >256F & 16int - const oC2 Wyjście dla 4 kanałów c0 c1 c2 cN oC3 16 Rejestrów Samplerów s0 s1 s2 s15 oDepth aL a0

Pipeline Istniejące potoki (pipeline’y) Ustalony - Fixed Konfigurowalny, nie programowalny Programowalne shadery - Programmable shaders Centrowany na shadery Programowalne shadery, lecz ustalony potok Programowalny potok W pełni progrmowalny przepływ danych na GPU

Pipeline Dodatkowe elementy potoku Vertex cache Texture cache Z-buffer Early-Z Stencil Branch processor – >= SM 3.0

Pipeline Vertex cache Cache pamięci na vertexy Przeważnie liniowy długości 256 bits Dostępny globalnie dla wszystkich vertex fetchy

Pipeline Texture cache Liniowy o długości 32K Współdzielony / segmentowany między wszystkie samplery Multitexturing niszczy cache Naraz odczytuje jedynie pojedynczy sektor w pobliżu aktualnej operacji Odczyty zależne niszczą cache Przechowuje dane w liniach o określonej długości Segmentuje tablice na małe bloki używane przy cache’owaniu

Pipeline Z-buffer Dodatkowy bufor karty graficznej przechowujący głębie każdego pixela Używany w rozwiązywaniu problemu widoczności pixela przy zapisywaniu do bufora ramki Algorytm malarza Aktualna głębia pixela jest sprawdzana z głebią zapisana w Z-buforze, jeśli jest większa pixel nie jest rysowany Obecnie 24b lub 32b o skali log Problematyka artefaktów Z-Fighting Obsługa parametryczna, sprzętowa, nie programowalna

Pipeline Z-buffer Early-Z Naturalne rozwinięcie Z-bufora Podczas budowania Z, dokonuje testu Odpalany przed wykonaniem Rasteryzacji Posiada wartość Z pixela z Vertex Shadera Może być wykorzystywany jako świadoma optymalizacja Depth pre-pass Front – to – Back sorting Obsługa parametryczna, sprzętowa, nie programowalna

Pipeline Stencil Dodatkowy bufor używany wraz z buforem Z Służy dodatkowych testom odrzucania pixeli Można do niego pisać i wykorzystywać przy optymalizacji Obsługa parametryczna, sprzętowa, nie programowalna

Pipeline Render state Stany sprzętowe GPU Z-test Stencil Culling Blending Parametryzują wewnętrzne sprzętowe systemy optymalizacji

Pipeline Branch processor (>= SM 3.0) Umożliwia wprowadzenie architektury MIMD Operacje na fragmentach są przeprowadzane w bloczkach (np. 32x32, 8x8 , 2x2) Każdy z bloczków za pomocą Branch processora i tzw. Flow control może wykonać odmienną ścieżkę wykonawczą Jeśli którykolwiek texel z bloczku musi wybrać odmienną drogę od innych ,obliczenia są wykonywane dla wszystkich texeli i wszystkich dróg Wprowadza fizyczną obsługę dynamicznych if, else, for, while itp. Narzut obliczeniowy < 6 cykli

Języki GLSL HLSL CG Wszystkie są podobne składniowo Różnice występują jedynie na poziomie składniowym kilku funkcji Np.. Lerp (HLSL) = mix(GLSL), float4 = vec4 etc. HLSL > CG > GLSL

Języki Języki przygotowane do obliczeń wektorowych Podstawowe typy Float Float2, float3, float4 / vec2, vec3, vec4 Float4x4 / mat4 Operacje wektorowe ALU Dot Mul Normalize Lerp / mix Clamp

Języki Obsługa samplerów tex2D / texture2D texCube / textureCube Filtrowanie POINT LINEAR ANIZO Etc.

Języki Dyrektywy kompilatora Zapoznać się z możliwościami języków Asm Flow control [loop] [flatten] [branch] Etc. Zapoznać się z możliwościami języków Google OGL consorcium MSDN Nvidia developer Ati developer

Praktyki programistyczne Zalecenia ogólne Stosunek ALU:Tex Samplers > 5:1 Jeśli to możliwe odczyty z textury zastąpić arytmetyką Liczba vertexów <= liczby pixeli Jeśli to możliwe korzystać z interpolatorów i wykonywać obliczenia na vertexach Szczególnie uważać przy funkcjach wielocyklowych Pow Sin cos Normalize Length

Praktyki programistyczne Zagadka ;] #R1 = (x,y,z) DP3 R0.w, R1, R1; RSQ R0.w, R0.w; MUL R0.xyz , R1 , R0.w;

Praktyki programistyczne Zalecenia dla vertex shaderów Usuwać nieużywane interpolatory oraz rejestry ogólnego przeznaczenia Jeśli to możliwe używać wczesnego odrzucania Zalecenia dla pixel shaderów Texture sampling Unikać zależnych odczytów textur Unikać samplowania dużych obszarów (cache) Korzystać właściwie z własności samplera (POINT/LINNEAR)

Praktyki programistyczne Branching Zaawansowana problematyka umożliwiająca wzrost prędkości o rzędy wielkości jak i również spowolnienie przetwarzania Podobieństwo w optymalizacji programów na CPU Struktury wyboru drogi If – else Dodatkowe utrudnienie wynikające z równoległości przetwarzania danych Dokładne omówienie być może kiedyś ;]

Praktyki programistyczne Jeśli wszystko zawiedzie Używać wstawek asm w miejscach szczególnie wrażliwych wydajnościowo For, while etc… Sprawdzić kod asm tworzony przez kompilator Niestety często dochodzi do błędów i mało wydajnej optymalizacji Poprawić w asm Używać dyrektyw kompilacji Optymalizacij Isolate Call / Inline Unrolll loop Flow control Branch flatten

Pytania? ?

Plan wykładów Architektura oraz optymalizacja shaderów Modelowanie właściwości fizycznych materiałów Obliczenia na texturach / tablicach Wprowadzenie – obsługa render targetów Post processing obrazu – metody i praktyki GPGPU – obliczenia ogólnego zastosowania na GPU

Punktacja etapu ‘rozbudowy’ Do zdobycia 10 (+2) pkt 5 pkt Wybranie 3 materiałów a następnie wymodelowanie ich oraz zintegrowanie z frameworkiem Wybierane z puli materiałów 2 proste , 1 średni Dodatkowo do +1 pkt za zaawansowany materiał Integracja modułu obsługi render targetów Wprowadzenie 3 efektów post processingu Wybierane z puli efektów 2 proste, 1 średni Dodatkowo do +1 pkt za zaawansowany efekt

Punktacja etapu ‘rozbudowy’ Shadery będą oceniane pod względem Przejrzystości Wydajności (optymalizacji) Prawidłowego efektu Zastosowanej metody Pomysłowości Zastrzegam możliwość rozmowy nt. konkretnego rozwiązania, jego zasadności oraz zrozumienia zagadnienia

Dziękuje za uwagę Michał Drobot Drobot.org