Z pohledu vývojářů tvořících multiplatformní aplikace s využitím grafické akceleraci, byl rok 2016 rozhodně přelomový. Nová grafická API nepochybně nevychází každý den a když vyjdou, často s námi setrvávají i několik desetiletí. A právě záčátkem roku 2016 byla dokončena finální specifikace grafického API Vulkan 1.0 a nové API tak začíná prosakovat do běžných, stabilních verzí grafických ovladačů. Konečně si tak na něj sáhne i běžný uživatel. Protože Vulkan bude rozhodně mít v nadcházejícím období nejrůznějších rozšířených/virtuálních realit, a samozřejmě multiplatformního hraní svoje slovo, rád bych mu zde věnoval alespoň dva posty. Coby člověk odkojený OpenGL, budu článek směřovat k porovnávání obou rozhraní a k popisu toho co pro OpenGL vývojáře přechod na Vulkan vlastně znamená.
Co je to Vulkan?
…aneb letmý úvod pro náhodné kolemjdoucí nikdy neuškodí. Vulkan je o první nezávislé, multiplatformní, low-level grafické API, které aspiruje na pozici náhradníka legendárního OpenGL. Jde tedy o jakýsi návod podle kterého komunikuje vaše aplikace a grafický ovladač. Vulkan API patří stejně jako OpenGL mezi open-standard a je tedy volně dostupný k implementaci do vašich projektů (Vulkan ani OpenGL není open-source, jde opravdu jen o „návod“, implementace Vulkanu v ovladačích je obvykle proprietární a uzavřená). Funkčně lze srovnat s DirectX12, jehož použití je ovšem omezeno pouze na jedinou verzi jediného operačního systému.
Uživateli nové API přinese zejména vyšší výkon, tedy možnost vyššího FPS nebo vyšší kvality renderované scény při zachování FPS. Ovšem samozřejmě jen v případě podpory ze strany grafického hardwaru a provozované aplikace. Zajímavější a klíčovější změny samozřejmě proběhnou pod kapotou.
Výhody Vulkanu oproti OpenGL by se daly shnout do několika bodů:
- Jde o low-level API. API tedy snižuje míru abstrakce a tím dává uživatelské aplikaci více svobody v provádění optimalizací.
- Přidává nativní podporu pro volání vykreslovacích funkcí z více vláken.
- Přináší nový intermediární jazyk pro shadery – SPIR-V.
- Eliminuje zastaralé koncepty práce s GPU.
- Sjednocuje API pro desktop platformy (OpenGL) a jeho ořezanější verzi pro mobilní platformy (OpenGL ES).
Přináší také ovšem některé nevýhody:
- Zvyšuje komplexnost uživatelské aplikace, přenáší vyšší zodpovědnost na uživatelkou aplikace.
- Není kompatibilní s platformami od Apple.
Proč vznikl Vulkan?
Čtenář si teď může pomyslet: OK, Vulkan je efektivní, low-level a low-overhead. Proč ale nebylo low-level a low-overhead už původní OpenGL? Naprvní pohled působí ironicky jak programovací jazyky začínaly na low-level úrovni a nyní uhánějí k čím dál větší abstrakci, zatímco grafická API se ubírají opačným směrem.
OpenGL vzniklo již v roce 1992 a to je, zvlášť v měřítkách výpočetní techniky, již velmi dávno. V té době většina spotřebních grafických karet ještě nedisponovala 3D akcelerací (často ani 2D akcelerací) a renderování 3D scény tak bylo výsadou grafických pracovnách stanic a technologicky bylo stále ještě v plenkách. Později nastal rozmach 3D akcelerátorů a trh zaplavily první karty s napevno „zadrátovaným“ procesem 3D rederingu – tedy s tzv. Fixed Function Pipeline. Výrobců bylo hodně ona renderovací pipeline tak nabývala různých, mnohdy velmi exotických podob. OpenGL musel v té době uspokojit všechny a spolehlivě konvertovat džungli různých hardwarových řešení na jednotné API pro každého programátora (ve stejné době si CPU programátoři užívali unifikovaného X86).
Později renderovací pipeline přešla do druhé fáze – některé její části začaly být programovatelné a přišly Shadery. Následně se renderovací pipeline začala skládat z univerzálních výpočetních jednotek a nastala doba unifikovaných shaderů. Architektura grafických karet tedy se tedy do určité míry unifikovala a množství výrobců se značně snížilo – v desktopovém světě prakticky na 3. OpenGL za tu dobu prodělalo hodně změn ale i přes to s sebou stále vláčelo spoustu notně zastaralých přístupů a spoustu legacy volání vnitřně již muselo vnitřně emulovat právě pomocí shaderů. Také mu úplně chyběla podpora vícejádrových CPU. I když vykreslování z více vláken je možné, vyžaduje přepnutí OpenGL kontextu a reálně tedy paralelně volat draw calls nelze.
Výrobci grafických karet se snažili od samého začátku vymanit z okovů příliš abstraktních API a nasadit vlastní low-level API kdekoliv to bylo možné (nebylo potřeba univerzálnost API). Konzole a arkádové automaty tak disponovaly rozhraními jako PSGL, GNM či Glide a tradičně dosahovaly s obdobným hardwarem výrazně lepších výkonů než PC. Stejná motivace dohnala k vydání vlastního API také společnost AMD a tak vzniklo API Mantle. Jenže pouhé vydání dalšího proprietárního API problém neřeší. Pokud mají nové API vývojáři akceptovat musí ho používat ideálně všichni významní výrobci. Mantle bylo tedy darováno nezávislé třetí straně – konsorciu Khronos a na jeho základech vznik Vulkan. První univerzálně akceptované low-level grafické API.
Podpora Vulkanu
Vulkan není novou iterací grafického stávajícího API (spíš takový reparát) a tak nutně nevyžaduje nový grafický hardware. Vystačí si se schopnostmi grafické karty podporující OpenGL 4.x popř. OpenGL ES 3.1.
Samozřejmě je nutná také podpora v ovladači grafické karty a je na svobodném rozhodnutí výrobce jestli ji do ovladače zahrne. Nyní na přelomu roku 2016 a 2017 máme dostupný Vulkan pro grafické karty AMD a nVidia. Grafické čipy Intelu mají podporu stále jen prostřednictvím ovladačů v beta verzi. Ve světě alternativního open-souce ovladače Mesa 3D je ovšem Intel napřed, zde jsou jeho GPU zatím jedinými podporovanými. (Edit: Stabilní podpora na grafických čipech Intel přidána od verze 15.45.14.4590). Windows podporuje Vulkan od W7, Android přidává podporu Vulkanu od verze 7.0 – Nougat. Aktuální mobilní čipsety by měly být již vesměs na Vulkan připraveny. Apple bohužel podporu zatím neplánuje – prosazuje vlastní low-level API Metal. Existují ovšem projekty jejichž úkolem je umožnit běh Vulkanu nad Metal API – například MoltenVK. Na Vulkan lze tedy pohlížet jako na skutečně velmi multiplatformní API.
Tolik trochu obecný úvod. Příště to bude o to bude více o vývojářském pohledu – vláknech, command bufferech, a SPIR-V.
Napsat komentář