Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Pracownia Gier w OpenGL

Podobne prezentacje


Prezentacja na temat: "Pracownia Gier w OpenGL"— Zapis prezentacji:

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

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

3 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

4 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

5 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

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

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

8 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….

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

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

11 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

12 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

13 Pipeline

14 Pipeline Dx 10 / OGl 3.0

15 Pipeline 6th generation GPU

16 Pipeline 8th generation GPU

17 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

18 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

19 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

20 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

21 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

22 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

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

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

25 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

26 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

27 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

28 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

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

30 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

31 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

32 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

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

34 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

35 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

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

37 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)

38 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ś ;]

39 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

40 Pytania? ?

41 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

42 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

43 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

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


Pobierz ppt "Pracownia Gier w OpenGL"

Podobne prezentacje


Reklamy Google