Mobilne akceleratory grafiki

Kamil Trzciński, 2013 O mnie

Kamil Trzciński http://ayufan.eu / [email protected]

● Od 14 lat zajmuję się programowaniem (C/C++, Java, C#, Python, PHP, itd.) ● Od 10 lat zajmuję się programowaniem grafiki (OpenGL, DirectX 9/10/11, Ray-Tracing) ● Od 6 lat zajmuję się branżą mobilną (SymbianOS, Android, iOS) ● Od 2 lat zajmuję się mobilną grafiką (OpenGL ES, XNA, DirectX for WP8) Plan

● Bardzo krótko o historii ● Mobilne układy graficzne ● API ● Programowalne jednostki cieniowania ● Optymalizacja ● Silniki graficzne oraz silniki gier Wstęp

Grafika komputerowa to dziedzina informatyki zajmująca się wykorzystaniem technik komputerowych do celów wizualizacji artystycznej oraz wizualizacji rzeczywistości.

Bardzo często grafika komputerowa jest kojarzona z urządzeniem wspomagającym jej generowanie - kartą graficzną, odpowiedzialna za renderowanie grafiki oraz jej konwersję na sygnał zrozumiały dla wyświetlacza 1. Historia Historia

Historia kart graficznych sięga wczesnych lat 80-tych ubiegłego wieku. Pierwsze karty graficzne potrafiły jedynie wyświetlać znaki alfabetu łacińskiego ze zdefiniowanego w pamięci generatora znaków, tzw. trybu tekstowego.

W późniejszym okresie pojawiły się układy, wykonujące tzw. operacje BitBLT, pozwalające na nałożenie na siebie 2 różnych bitmap w postaci rastrowej. Historia Historia #2

● Wraz z nadejściem systemu operacyjnego Microsoft Windows 3.0 wzrosło zapotrzebowanie na przetwarzanie grafiki rastrowej dużej rozdzielczości. ● Powstaje interfejs GDI odpowiedzialny za programowanie operacji związanych z grafiką. ● Krótko po tym powstały pierwsze akceleratory 2D wyprodukowane przez firmę S3. Wydarzenie to zapoczątkowało erę graficznych akceleratorów grafiki. Historia #3

● 1996 – wprowadzenie chipsetu Voodoo Graphics przez firmę 3dfx, dodatkowej karty rozszerzeń pełniącej funkcję akceleratora grafiki 3D.

● Powstają biblioteki umożliwiające tworzenie trójwymiarowych wizualizacji: Direct3D oraz OpenGL. Historia #3 Historia #4

● 1999/2000 – DirectX 7.0 dodaje obsługę: T&L (ang. transformation and lighting) ● Jednostka T&L zdejmowała z programisty i CPU konieczność wyliczania współrzędnych wielokątów względem kamery, a następnie obliczanie wypadkowego koloru pikseli należących do tych wielokątów, przy jednoczesnym uwzględnieniu umiejscowienia źródeł światła ● Mniejwięcej od tego momentu akceleratory graficzne zaczeły być nazywane: GPU (ang. graphics processing unit). Historia #4 Historia #5

● Powstaje specyfikacja Shader Model 1.0/1.1 zgodna z Direct3D 8.0.

● NVIDIA GeForce 3 – pierwsza programowalna karta graficzna. ● Karta ta udostępniała możliwość napisania krótkiego programu pozwalającego na rmodyfikację pozycji, wypadkowego koloru wierzchołka czy współrzędnych tekstury przekazywanych do rasteryzera. Obliczenia przeprowadzane były przez specjalne jednostki cieniujące zw. Vertex i Pixel Shaderem. Historia #6

● DirectX 9.0 przynosi powstanie wysokopoziomowych języków programowania: HLSL oraz Cg wykorzystujących składnię języka C. Wprowadza Shader Model 2.0.

● DirectX 9.0c do dnia dzisiejszego jest jednym z najczęściej stosowanych interfejsów graficznym. Zaimplementowany w nim Shader Model 3.0 praktycznie nie ma ograniczeń na długość programów cieniujących (programy są na tyle długie, że wystarczają do znacznej większości aktualnych zastosowań). Historia #7

● DirectX 10.0 oraz Shader Model 4.0

● Najważniejsza zmianą jest wprowadzenie tzw. Geometry Shaders czyli jednostek pozwalających na przetwarzanie geometrii. Wcześniejsze wersje shaderów umożliwiały przetwarzanie wierzchołków oraz pikseli, natomiast nie pozwalały na modyfikację siatki obiektów. Wprowadzenie Geometry Shaders umożliwiło dodawanie lub usuwanie całych trójkątów z potoku renderingu. Historia #8

● To jest też moment pojawienia się GPGPU (ang. General-purpose graphics processing unit)

● nVidia udostępnia autorskie oprogramowanie umożliwiające wykorzystanie procesorów strumieniowych zamontowanych w kartach graficznych o nazwie CUDA szybko zdobyło popularność szczególnie w zastosowaniach matematycznych czy kryptografii, gdzie procesory ogólnego przeznaczenia nie są najszybsze. Historia #8 Historia #9

DirectX 11 - Shader Model 5.0

● Wprowadza sprzętową obsługę teselacji (Domain i Hull Shaders) ● Wprowadza obsługę Compute Shader (odpowiednik CUDA) ● Systematyzuje obsługę dla starszych wersji API (feature levels) Urządzenia mobilne

● Jednym z czynników, które przyczyniły się do znaczącego wzrostu popularności urządzeń mobilnych była widoczna poprawa jakości wyświetlaczy graficznych.

● Pierwsze urządzanie cechowały się wyświetlaczami monochromatycznymi o rozdzielczości 4k pikseli.

● Obecnym standardem dla telefonów są wyświetlacze o rozdzielczości 1M-2Mpx (FullHD), a dla tabletów 2M-3Mpx (Retina). Urządzenia mobilne #2

● Obecne urządzenia cechują się mocą obliczeniową porównywalną z komputerami klasy PC sprzed 5 lat. Różnica jest natomiast w wielkości i poborze mocy. Najwydajniejsze obecnie urządzenia potrafią podczas intensywnego korzystania wytrzymać po 10-12 godzin.

● To ciągłe współzawodnictwo między producentami wymusza wprowadzanie nowych i szybszych technologii oraz dalszą miniaturyzacją układów scalonych. Urządzenia mobilne #3

● Najnowsze dane pokazują, że wartość rynku gier mobilnych wynosiła 7,8 miliarda $ w 2012. W 2016 powinna osiągnąć co najmniej 18,3 miliarda $ (http://www.gamesindustry.biz/articles/2012-11-28-the- state-of-mobile-game-development)

● Większość przychodów pochodzi lub będzie pochodzić ze sprzedaży gier oraz dodatków (DLC, IAP).

● Obecnie użytkownicy tabletów spędzają 67% czasu na graniu w mobilne gry. W przypadku telefonów jest to 39%. Przewiduje się powolną erozję popularności konsol do gier na rzecz właśnie urządzeń mobilnych, smartfonów i tabletów 2. Mobilne układy graficzne Hardware

Praktycznie wszystkie obecnie produkowane urządzenia zbudowane są w technologii SoC (ang. System-on-a-chip).

Głównymi dostawcami są: ● PowerVR (Imagination Technologies Group) ● ARM Holdings ● Qualcomm ● NVIDIA PowerVR

● PowerVR jest dywizją Imagination Technologies będącej twórcą rozwiązań sprzętowych i programowych przeznaczonych do renderingu 2D i 3D.

● Układy PowerVR są z powodzeniem wykorzystywane w urządzeniach firmy Apple: wszystkie wersje iPada, iPhone 4S i 5 oraz w niektórych urządzeniach innych producentów, np.: Samsung.

● PowerVR wykorzystuje do wizualizacji grafiki 3D metodę zwaną odroczonym kafelkowym mechanizemem renderingu (TBDR). PowerVR #2

● Obraz jest renderowany dopiero w momencie, gdy wszystkie renderowane poligony zostaną przesłane dla danej ramki. ● Kosztowne operacje, tj.: teksturowanie i cieniowanie pikseli są odroczone do momentu, gdy będzie znana widoczność wszystkich pikseli renderowanego obrazu. ● Obraz następnie jest dzielony na kafle o rozmiarze 32x32 piksele. Do każdego kafla przypisana jest lista wpływających na wynikowy obraz trójkątów. Rendering wykorzystuje technikę podobną do rzucania promieniami (ang. ray-casting). PowerVR #3

● Jest to jedyny akcelerator wykorzystujący TBDR.

● Podejście to umożliwia renderingu przezroczystych trójkątów niezależnie od kolejności w której były przetwarzane.

● Większość obecnie dostępnych układów obsługuje najważniejsze API programistyczne, tj.: OpenGL ES 1.1, 2.0, 2.1, DirectX 9, 10.1 oraz OpenCL PowerVR #4 PowerVR #5 ARM Mali

● Mali jest akceleratorem graficznym (GPU), produktem firmy ARM. ● Firma ARM jest projektantem większości dostępnych na rynku układów ARM (m.in. nowych Cortex-A8, A9 i A15) oraz popularnych układów graficznych dla urządzeń mobilnych Mali, znanych chociażby z Samsungów Galaxy S II, Galaxy S III czy Galaxy Note. ● Z powodzeniem wykorzystywany w wielu minikomputerach: Hackberry A10, Cubieboard ● W zależności od wersji układy mają do 8 rdzeni GPU. ARM Mali #2

● Wszystkie starsze układy (do Mali-450) obsługują OpenGL ES 1.1, 2.0 oraz OpenVG 1.1

● Nowsze nawet OpenGL ES 3.0, OpenCL 1.1 oraz DirectX 11

● Obsługa tekstur oraz ekranów o rodzielczościach 4096x4096

● Obsługa FSAA (full scene anti- aliasing) oraz SSAA (super sampling anti-aliasing) Qualcomm Adreno

● Wcześniej Imageon, własność ATI. Marka została sprzedana Qualcommowi w 2008, który następnie zmienij jej nazwę na Adreno (anagram Radeon)

● Wykorzystywane w wielu urządzeniach różnych producentów: Samsung, HTC, LG

● Obsługuje OpenGL ES 1.1, 2.0 (Adreno 320 - 3.0), Direct3D FL 9.3, OpenCL 1.2, OpenVG 1.1 Qualcomm Adreno #2 NVIDIA Tegra

● SoC w skład, którego wchodzi układ GeForce ULP (ultra low power).

● Drugi po Mali-400 akcelerator niewykorzystujący zunifikowanych jednostek cieniujących.

● Zapowiedziana Tegra 4 ma być 6x szybsza niż Tegra 3 oraz 20x szybsza niż Tegra 2. NVIDIA Tegra #3 NVIDIA Tegra #2 NVIDIA Tegra #4 NVIDIA Tegra #4

Rozszerzenia: ● Early-Z support ● Integrated Pixel Shader and Blending Unit ● Coverage sampling anti-aliasing (CSAA) ● Advanced Anisotropic Filtering (AF) Wydajność

● Na wydajność ma wpływ nie tylko stosowany układ, ale może przede wszystkim rozdzielczość ekranu.

3. API application programming interface API

DirectX - jest to zestaw funkcji API spomagających generowanie grafiki (dwu- i trójwymiarowej), dźwięku oraz innych zadań związanych zwykle z grami i innymi aplikacjami multimedialnymi. Dostępny na urządzeniach z systemem operacyjnym Windows.

OpenGL ES - jest to specyfikacja uniwersalnego API do generowania grafiki oparta o specyfikację OpenGL. Dostępna na prawie wszystkich platformach.

OpenVG - jest to specyfikacja API do akceleracji grafiki wektorowej.

OpenCL - jest to zestaw funkcji wspomagających pisanie aplikacji działających na różnego rodzaju jednostkach obliczeniowych (np. CPU, GPU). OpenGL ES

● Pierwsza wersja została wydana w 2003 roku.

● Popularniejszy i szerzej stosowany niż DirectX: Android, Linux, iOS / OS X, PS3, Nintendo, BlackBerry, Raspberry PI, SymbianOS

● OpenGL ES jest uproszczoną oraz lekko zmodyfikowaną wersją OpenGL dla Desktop.

● Interfejs OpenGL ES opiera się o wykorzystanie programowania strukturalnego.

● Niestety, ale nadal wykorzystuje dość intensywnie rozszerzenia. OpenGL ES 1.0 oraz 1.1

● Rezygnacją z wykorzystania funkcji glBegin() i glEnd()

● Rezygnacją z ręcznego wywołania funkcji renderujących na rzecz buforów wierzchołków

● Usunięciem wielu typów renderowanych objektów, tj.: kwadratów, poligonów, linii

● Usunięciem obsługi bufora akumulacji, list wyświetlania oraz niektórych parametrów materiałowych OpenGL ES 1.1

● Bufory danych - funkcja umożliwiła zapisywanie wierzchołków i indeksów w pamięci karty graficznej

● Multiteksturing - funkcja umożliwiła nakładanie wielu tekstur w jednym przebiegu renderingu, pozwoliło to np. na wykonywanie operacji iloczynu skalarnego (Register Combiners)

● Automatyczną generację poziomów szczegółowości - aplikacje nie musiały implementować lub zapisywać dalszych poziomów szczegółowości dla tekstur, operację tą wykonywała karta graficzna lub sterownik karty graficznej OpenGL ES 1.1 #2 OpenGL ES 2.0

● Rezygnacja ze stałego potoku renderingu na rzecz programowalnego.

● Wszystkie operacje, tj.: transformacja, oświetlenie, parametry materiału, parametry oświetlenia zostały zastąpione specjalnie przygotowywanymi programami cieniującymi wierzchołki i piksele (ang. shaders).

● Niekompatybilna z OpenGL ES 1.0/1.1.

● Standard - obsługiwana przez 99,7% urządzeń z Androidem. OpenGL ES 2.0 #2

Raczej kompatybilna z OpenGL. Ostatnie problemy rozwiązuje rozszerzenie: GL_ARB_ES2_COMPATIBILITY. http://www.opengl. org/registry/specs/ARB/ES2_compatibility.txt OpenGL ES 2.0 OpenGL ES 3.0

● Wersja 3 jest bardziej ewolucją niż rewolucją tak jak było to poprzednio.

● Wstecznie kompatybilna z OpenGL ES 2.0!

● Obecnie nie jest obsługiwany przez żaden system operacyjny.

● Dostępny jest emulator mapujący wywołania OpenGL ES 3.0 na wywołania OpenGL: http://malideveloper.arm. com/develop-for-mali/tools/opengl-es-3-0-emulator/ OpenGL ES 3.0 #2

1. Określanie widoczności obiektów (occlusion queries) 2. Wyświetlanie wielu obiektów jednocześnie (instanced rendering) 3. Obsługa wielu buforów renderingu (MRT) 4. Obsługa stało oraz zmiennoprzecinkowych operacji w shaderach 5. Obsługa tekstur głębokości (depth textures) 6. Rozszerzenie obsługiwanych formatów tekstur, buforów renderingu oraz ich wielkości 7. Wymuszenie większej spójności implementacyjnej między różnymi urządzeniami (więcej rozszerzeń, które stają się standardem!) OpenGL ES - Rozszerzenia

OpenGL został zaprojektowany w taki sposób, aby producenci sprzętu graficznego mogli rozszerzać jego funkcjonalność poprzez własne rozszerzenia.

Zalety:

● Pozwalają na wykorzystanie funkcji, które jeszcze nie są w standardzie, np. nowe formaty kompresji tekstur. ● Możliwość tworzenia lepszych i bardziej zaawansowanych wizualizacji. OpenGL ES - Rozszerzenia #2

Wady:

● Znaczne skomplikowanie potoku renderingu: konieczność obsługi niestandardowych metod renderingu. ● Rożni producenci róznie implementują dane rozszerzenie: konieczność testowania na większej ilości urządzeń. ● Rozszerzenia są fajne, ale zazwyczaj nie warto ich używać, bo urządzenia i tak są za wolne. Asus Eee PAD Transformer Prime TF201

GL_NV_platform_binary GL_OES_texture_half_float GL_OES_rgb8_rgba8 GL_OES_texture_float GL_OES_EGL_sync GL_EXT_texture_array GL_OES_fbo_render_mipmap GL_OES_compressed_ETC1_RGB8_texture GL_NV_depth_nonlinear GL_EXT_texture_compression_latc GL_NV_draw_path GL_NV_texture_compression_latc GL_NV_texture_npot_2D_mipmap GL_EXT_texture_compression_dxt1 GL_OES_EGL_image GL_EXT_texture_compression_s3tc GL_OES_EGL_image_external GL_NV_texture_compression_s3tc GL_OES_vertex_half_float GL_EXT_texture_filter_anisotropic GL_OES_mapbuffer GL_NV_get_tex_image GL_NV_draw_buffers GL_NV_read_buffer GL_NV_multiview_draw_buffers GL_NV_shader_framebuffer_fetch GL_EXT_Cg_shader GL_NV_fbo_color_attachments GL_EXT_packed_float GL_EXT_bgra GL_NV_EGL_stream_consumer_exter GL_EXT_texture_format_BGRA8888 nal GL_EXT_unpack_subimage GL_NV_coverage_sample GL_NV_pack_subimage GL_EXT_occlusion_query_boolean GL_NV_texture_compression_s3tc_update GL_NV_timer_query GL_NV_read_depth GL_EXT_robustness GL_NV_read_stencil GL_OES_standard_derivatives OpenGL ES - Extensions #3

http://gfxbench.com/ DirectX

● Zestaw API wspomagający generowanie grafiki (dwu- i trójwymiarowej), ale też dźwięku (XAudio2), obsługi wideo (DirectShow) czy wejścia.

● Produkt firmy Microsoft dostępny tylko na platformę Windows oraz konsolę Xbox.

● Wraz z biblioteką DirectX 10 wprowadzono tzw. poziomy funkcjonalności (ang. feature levels).

● Od DirectX 10 API udostępnia tylko funkcje programowalnego potoku renderingu. DirectX #2

● Unifikacja interfejsu oraz wprowadzenie poziomów funkcjonalności ułatwia proces przygotowania i utrzymania kodu aplikacji. W mojej opinii pisanie pod DirectX jest prostsze w dłuższej perspektywie.

● Nowsze poziomy są wstecznie kompatybilne. W większości przypadków rozszerzenie funkcjonalności aplikacji wymaga zmiany poziomu na wyższy oraz dodanie implementacji nowych efektów. DirectX #feature levels DirectX #feature levels #2 DirectX #feature levels #3

● Na komputerach osobistych obecnie dostępna jest specyfikacja oznaczona jako 11.1 (Windows 8).

● Natomiast telefony (Lumia 820/920, HTC 8X) oparte o najnowszy system Windows Phone 8 wykorzystują 9.3.

● FL9.3 już teraz pozwala tworzyć niesamowicie wyglądające gry. Zostaje jednak kwestia wydajności sprzętowej, ale i tak!

● Najlepsze jest to, że ten sam kod daje prawie identyczny rendering na Windows 8, Windows RT oraz Windows Phone 8. DirectX FL9.3 DirectX FL9.3 #2

Możliwości: ● Określanie widoczności obiektów (ang. occlusion queries) ● Wyświetlanie wielu obiektów jednocześnie (instanced rendering) ● Obsługa wielu buforów renderingu (MRT)

To są wszystko możliwości, które będą dostępne w OpenGL ES 3.0. Niektóre są dostępne w formie rozszerzeń (occlussion query w Tegra 3). 4. Programowalne jednostki cieniowania Jednostki cieniujące

Vertex Shader (DirectX) Vertex Program (OpenGL/ES)

Programowalna jednostka cieniująca wierzchołki. Program cieniujący napisany dla tej jednostki jest uruchamiany raz na każdym przetwarzanym wierzchołku. Ma on za zadanie transformację położenia wierzchołka z wirtualnej przestrzeni 3D na współrzędne ekranu względem obserwatora. W ten sposób można wpływać na wynikowy kształt figury powodując ruch lub deformacje. Jednostki cieniujące #2

Geometry Shader

Programowalna jednostka cieniująca geometrię, pozwalająca na modyfikację siatki wierzchołków. Program cieniujący ma możliwość proceduralnego dodawania lub usuwania wierzchołków z siatki trójkątów.

Obecnie brak jest obsługi Geometry Shaderów na urządzeniach mobilnych. Jednostki cieniujące #3

Pixel Shader (DirectX) Fragment Shader (OpenGL/ES)

Programowalna jednostka pozwalająca na wyliczenie koloru pikseli. Na wejściu programu są parametry cieniowania pobrane z rasteryzatora, który wypełnia wielokąty przesyłane z potoku graficznego. Cieniowanie pikseli umożliwia nakładanie na fakturę obiektu zaawansowanych efektów oświetlenia, map cieni lub map wypukłości. Jednostki cieniujące #4

Hull i Domain Shaders

Shadery teselacji. Dostępne od DirectX 11.

Hull jest odpowiedzialny za uszczegółowienie siatki wielokątów dodając dodatkowe punkty kontrolne wysyłane do teselatora.

Domain jest odpowiedzialny za korektę położenia teselowanych wierzchołków. Języki programowania shaderów

GLSL - Język programowania używany w OpenGL/ES wprowadzony przez komitet standaryzacyjny ARB. Dostępny od OpenGL 2.0 (w 1.5 jako rozszerzenie) oraz OpenGL ES 2.0.

HLSL - Język programowania używany począwszy od DirectX 9.0. Do Shader Model 3.0 kompatybilny składniowo z Cg.

Cg - Uniwersalny język programowania dla DirectX oraz OpenGL będący własnością NVIDII. Kompilator potrafi wygenerować, np. kod GLSL. Obecnie coraz rzadziej wykorzystywany z uwagi na słaby platform mobilnych. GLSL #zmienne

Z punktu widzenia silnika graficznego obsługującego mechanizm shaderów, niezwykle istotną kwestię stanowi sposób przekazywania z poziomu aplikacji wartości parametrów shaderów, czyli zmiennych uniform. ● Definiowane są niezależnie dla Vertex i Fragment Shaderów. ● Ich ustawianie z poziomu aplikacji odbywa się przy użyciu funkcji glGetUniformLocation(p, name) zwracającej indeks zmiennej, a następnie, w zależności od typu zmiennej, wywołaniu odpowiedniej funkcji glUniform*(idx, v) w celu przypisania wartości GLSL #atrybuty

Inaczej nazywane wejściowe semantyki wiązania programu cieniującego. Oznaczane one są słowem kluczowym attribute.

Służą one do dowiązania danych ze strumienia wierzchołków do odpowiednich zmiennych atrybutów wejściowych shadera wierzchołków. Realizowane jest to poprzez pobranie indeksu zmiennej attribute (funkcja glGetAttribLocation(p, name)) i dowiązanie strumienia zawierającego wartości atrybutu (funkcje glAttribPointer(idx,...) i glEnableVertexAttribArray(idx)). GLSL #wyjścia

Inaczej nazywane wyjściowe semantyki wiązania programu cieniującego. Oznaczane one są słowem kluczowym varying.

Służą one do przekazania wartości z programu cieniującego wierzchołki do programu cieniującego piksele. Przekazywana wartość jest interpolowana na pikselach. GLSL #precyzja

● W OpenGL ES wprowadzono możliwość określenia oczekiwanej precyzji dla obliczeń wykonywanych na określonych danych. ● Zalecane jest korzystanie z 32 bitowej precyzji do obliczeń pozycji, ale wystarczy 8 lub 16 bitowa precyzja do obliczeń kolorów. ● Dla wszystkich semantyk można zdefiniować oczekiwaną precyzję używając jednego z 3 modyfikatorów. Minimalna definiowana przez standard dokładność: ○ highp - 16 bit, float, -2^62 do 2^62, ○ mediump - 10 bit, float, -2^14 do 2^14, ○ lowp - 8 bit, float, -2 do 2, GLSL #precyzja

Pewnym problemem jest jednak to, że starsze układy SoC nie obsługują 32 bitowej precyzji.

Można to sprawdzić: int range[2], precision; glGetShaderPrecisionFormat (GL_FRAGMENT_SHADER, GL_HIGH_FLOAT, range, &precision); GLSL #2 HLSL

● Konieczność wcześniejszego skompilowania i zapisania skompilowanego kodu. ● Semantyka HLSL różni się w zależności od wersji Shader Model. ● Wartości do programów cieniujących przekazywane są poprzez rejestry (uniform, do Shader Model 3.0) lub poprzez bufory stałych (constant buffers, od Shader Model 4.0). ● SDK do Windows Phone 8 udostępnia Shader Model 4.0 w specyfikacji dla FL9.3. ● A teraz co ciekawe: bufory stałych są tylko narzucone przez API DirectX11, bo ich implementacja emuluje wykorzystanie rejestrów :) HLSL #2

● Trochę inne podejście do wejściowych i wyjściowych semantyk: wykorzystanie słów kluczowych in i out dla argumentów funkcji shadera.

● Mniejsza kontrola precyzji: float i half.

● Można wymusić D3DCOMPILE_PARTIAL_PRECISION w trakcie kompilacji. HLSL #3 HLSL #precyzja obliczeń HLSL <-> GLSL

Możliwe. Są nawet narzędzia do tego: hlsl2glsl. Pierwotnie stworzone przez ATI, następnie zaadaptowane i rozbudowywane przez Unity. https://github.com/aras-p/hlsl2glslfork

Do konwersji z GLSL na HLSL można wykorzystać projekt Google ANGLE. Translator wywołań OpenGL ES 2.0 na API DirectX 9. ANGLE jest wykorzystywane jako domyślny backend WebGL w Chrome i Firefoxie na Windowsie. https://code.google.com/p/angleproject/ HLSL <-> GLSL #2

● Ale zazwyczaj jak piszemy shadery ręcznie, to można je zgeneralizować, aby możliwe było używanie GLSL i HLSL. ● Semantyki obu języków są podobne. Trzeba natomiast użyć trochę #ifdef / #endif co niestety zaciemnia czytelność kodu. HLSL <-> GLSL #3 5. Optymalizacja Optymalizacja

● Użycie kompresji: ○ ETC (Ericsson Texture Compression) - jedyny zawsze obsługiwany format od Androida 2.2. ○ DXT (S3 Texture Compression) - dostępny na PC, Android (SoC Tegra) oraz Windows Phone 7/8 ○ PVRTC (PowerVR Texture Compression) - iOS ○ ATITC - dostępne na urządzeniach z Adreno glCompressedTexImage2D (GL_TEXTURE_2D, 0, GL_ATC_RGB_AMD, uiWidth, uiHeight, 0, uiSize, pvData); Optymalizacja #2

FPS Size First Load Reload RGB 43,1 6.0 MB 376 ms 251 ms ETC 42,6 1.9 MB 142 ms 174 ms ATCRGB 43,2 1.4 MB 143 ms 128 ms Optymalizacja #3

● Użycie tekstur o niższej głębi. Zamiast RGBA8888 można użyć: RGB565, RBA5551, RGBA4444.

● Łączenie kilku tekstur w jedną: Optymalizacja #4

● Użycie mipmappingu. Podnosi zużycie pamięci o 33%, ale redukuje wykorzystanie przepustowości pamięci graficznej. Kolejnym skutkiem jest ogólna poprawa jakości grafiki.

● Renderuj wieloprzebiegowo tam gdzie to możliwe! Optymalizacja GLSL

● Okazuję się, że jakość wbudowanego kompilatora GLSL jest bardzo kiepska (ale coraz lepsza z kolejnymi wersjami sterowników). ● Jego jakość zależy mocno od implementacji w sterowniku. Implementacja jest albo szybka albo generująca dobry microkod. ● Ten sam problem występuje zarówno w GLSL dla Desktop (rzadziej) jak i Mobile (bardziej). Optymalizacja GLSL #2 Optymalizacja GLSL #3

● Ten problem nie występuje w przypadku HLSL. Microsoft wymusza na deweloperze kompilowanie kodów shaderów w trakcie procesu kompilacji aplikacji. Nie ma żadnej możliwości przeprowadzenia dynamicznej kompilacji już na urządzeniu!

● Szczególnie daje o sobie znać we wszystkim systemach opartych o generowanie kodu jednostek cieniujących lub opartych o mechanizm konwertowania HLSL na GLSL. Optymalizacja GLSL #4

HLSL

GLSL

Opt. Optymalizacja GLSL #5

GLSL ES GLSL ES Optimized

iPhone 3G 236ms 36ms Motorola Droid 537ms 223ms Nexus One 155ms 155ms Optymalizacja GLSL #6

GLSL Optimizer jest używany w Unity od wersji 3.0. https://github.com/aras-p/glsl-optimizer http://aras-p.info/blog/2010/09/29/glsl-optimizer/ 6. Silniki gier Unity 3D

● Wieloplatformowe środowisko do tworzenia gier 3D (oraz 2D) na konsole, urządzenia mobilne, PC oraz jako rozszerzenia przeglądarek. ● Wykorzystuje do renderingu API DirectX, OpenGL, OpenGL ES. ● Obsługuje wszystkie najnowsze efekty renderingu: bump mapping, reflection mapping, parallax mapping, SSAO, shadow maps, HDR, itd. ● Całe środowisko deweloperskie jest zbudowane wokół wbudowanego edytora świata. Działa to bardzo podobnie do aplikacji do modelowania świata 3D. ● Gry mogą być pisane w C# (Mono), Boo oraz w JavaScriptcie. Unity 3D #2

Unity Unity PRO PC Free $1,500 iOS $400 $1,500 Android $400 $1,500 Flash $400 $1,500 Unity 3D #3 Unity 3D #Bladeslinger cocos2d-x

● Darmowy framework do pisania gier 2D. ● Obecnie jeden z najlepszych i najpopularniejszych. ● Jest implementacją w C++ frameworka cocos2d dla iOS. ● Posiada wbudowaną obsługę Lua i JavaScriptu. ● Prawdziwie wieloplatformowy: iOS, Android, Windows, Linux, Bada, BlackBerry, Windows Phone. ● Dostępne jest narzędzie do budowania scen: CocosBuilder ● Znakomita integracja z Visual Studio, Eclipsem oraz XCodem. cocos2d-x #2

Możliwości: ● Przejścia (animacje) między scenami ● Sprajty oraz obsługa animacji sprajtów ● Efekty (fale, flary itd.) ● Akcje (rotacja, przesunięcie, skalowanie) ● Interfejs użytkownika (menu, przyciski, listy) ● System cząsteczkowy ● System fizyczny (Box2D lub Chipmunk) ● Obsługa dźwięku (CocosDenshion) ● Obsługa dotyku oraz akcelerometru cocos2d-x #3

Podstawowe założenia:

● Scenes ● Director ● Layer ● Sprites cocos2d-x #sceny cocos2d-x #drygent cocos2d-x #warstwy cocos2d-x #duszki cocos2d-x #farmfrenzy cocos2d-x #deserttycoon CocosBuilder

● Darmowe narzędzie do szybkiego tworzenia gier z wykorzystaniem cocos2d lub cocos2d-x. ● Testowanie gry następuje poprzez uruchomienie CocosPlayer na urządzeniu: Android lub iOS a następnie przesłaniu danych gry poprzez WiFi. ● CocosBuilder obsługuje: animacje, tworzenie rozbudowanych interfejsów użytkownika, obsługę wielu rozdzielczości oraz automatyczne przeskalowywanie zasobów. ● CocosBuilder może służyć tylko jako narzędzie do tworzenia opisów warstw. Cała logika gry może zostać zaprogramowana w JavaScript lub natywnie w C++ (cocos2d-x) oraz Objective-C (cocos2d). CocosBuilder #2 CocosBuilder #3 Co dla dewelopera?

● Niestety, ale chyba najlepszym komputerem dla dewelopera aplikacji i gier mobilnych jest Mac. ● Mnogość środowisk programistycznych: ○ OS X: ■ iOS - XCode / Unity3D* ■ Android - Eclipse / Intellij / Unity3D* ○ BootCamp / Windows: ■ Android - Eclipse / Intellij / Unity3D* ■ Windows Phone 8 - Visual Studio / Unity3D* ○ Linux: ■ Android - Eclipse / Intellij / Unity3D* Co dla dewelopera? #2

● Gry TRZEBA testować na fizycznych urządzeniach. Emulator nie odzwierciedla ograniczeń sprzętu a co najwyżej oprogramowania. ● Emulator Androida wysyła oddzielnym kanałem polecenia API OpenGL, które są wykonywane na systemie operacyjnym ● Emulator Windows Phone wymaga obsługi SLAT (ang. Second Level Address Translation). Technologii wirtualizacyjnej pozwalającej na wirtualizację dostępu do karty graficznej. Intel od i3, AMD od Opteronów. Na zakończenie

● Według wielu firm z branży (m.in. NVIDIA) w perspektywie 2 lat mobilne akceleratory grafiki powinny osiągnąć wydajność obecnej generacji konsol (PS3, XBOX 360). ● Od paru lat dynamizm rynku mobilnego znacząco przewyższa ten obserwowany na rynku PC i konsol. Wzrost szybkości akceleratorów już nie jest tak spektakularny jak miało to miejsce na początku tysiąclecia. Spektakularny wzrost natomiast notuje branża mobilna, której dynamizmowi nie widać końca. ● Do wszystkich: zdecydowanie warto się zająć branżą mobilną a w szczególności branżą gier. Tu jest przyszłość ;) Przyszłość Dziękuję za uwagę!

Kamil Trzciński http://ayufan.eu / [email protected]