Więcej standardów: nowe API 3D połączy DirectX 12, Vulkana i Metal
Narobiło się w ostatnich latach tych nowych niskopoziomowychinterfejsów programowania grafiki – i twórcy gier, a przedewszystkim silników gier, nie mają łatwego życia. W ślad zapionierskim (i dziś już zapomnianym) Mantle przyszedł nie jeden,lecz trzy standardy: bezpośrednio wywiedziony z Mantle Vulkan,DirectX 12 oraz Metal. Z tego zbioru dwa API standardami są tylko zewzględu na pozycję ich producentów na rynku. Twórcywieloplatformowego Vulkana, The Khronos Group, chcą pomóc wucieczce od własnościowych rozwiązań Microsoftu i Apple’a.Zapowiadają coś zaskakująco uniwersalnego, zarazem każąc zadaćnam pytanie – o co chodzi z tym Vulkanem?
Do multiplatformowości Vulkanowi troszkę jeszcze brakuje, ale itak nie ma w tej dziedzinie równych. Działa na Androidzie 7.0 inowszych, Windowsie 7 i nowszych, Linuksie z nowymi sterownikamigrafiki AMD, Intela i Nvidii, wspierany jest przez licznearchitektury sprzętowe, mobilne i desktopowe. Właściwie nie ma gotylko na platformie Apple, ponieważ firma z Cupertino musiaławymyślić swój „standard”. Zapewne pozazdrościła kolegom zRedmond, którzy przyjęli koncepcyjne założenia Mantle, alezamiast przyłączyć się do prac nad standardem branżowym, musielioczywiście tworzyć niekompatybilne z innymi systemami DirectX 12.
Tej fragmentacji (tak, wiemy, to okropne słowo) Grupa Khronoschce zaradzić stworzeniem nowego meta-interfejsu grafiki, którydziałałby jako nakładka na Vulkana, Metal i DirectX 12. Miałby ondziałać z wydajnością bliską natywnej i ułatwiać ogarnięcieróżnic w zakresach możliwości poszczególnych interfejsów. Jakto zrobić? No cóż, podejście jest dość toporne, dosłownietoporne. Nowe meta-API będzie obejmowało jedynie część wspólnąmożliwości wszystkich trzech interfejsów, porzuci przy tymspecyficzne optymalizacje wydajnościowe.
Po co jednak twórcy Vulkana chcą uszczęśliwić nas kolejnym,nie dość wydajnym interfejsem grafiki, który będzie ograniczony wmożliwościach względem wszystkich niskopoziomowych API? Czy tylkopo to, by w jakiś sposób coś z Vulkana przemycić na iOS-a? Wydajesię, że jedynym sensownym zastosowaniem będą tu gryprzeglądarkowe, dziś ograniczone do możliwości WebGL 2.0, czylipodzbioru OpenGL ES 3.0. To wysokopoziomowy interfejs, ze sporymnarzutem sterowników. Żaden z trzech obecnych dziś na rynkuinterfejsów niskopoziomowych nie nadaje się jednak do przeglądarek.Chyba nikt nie chce przecież, by przeglądarka miała takbezpośredni dostęp do sprzętu. Nikt też nie chce zmagać się waplikacjach webowych z niekompatybilnością tych API.
Propozycja The Khronos Group nie była tu jednak pierwsza. W lutymApple zaproponowało swoje nowe API graficzne dla przeglądarek, onazwie WebGPU.Ma to być standard grafiki 3D następnej generacji, rozwijany wramach W3C, działający jako nakładka na… Vulkana, Metal iDirectX12. Świetnie. Więcej niekompatybilnych standardów –właśnie tego potrzebujemy.
W tym kontekście zagranie The Khronos Group może być po prostumanewrem bardziej politycznym niż technicznym. To konsorcjum jestogromną potęgą świata grafiki, wśród swoich członków mającAMD, Nvidię, Intela, ARM Holdings, Imagination Technologies,Qualcomma, Sony, Samsunga, Huawei, Google i… Apple. Bez poparciaThe Khronos Group, firma z Cupertino nie ma jednak żadnych szans nawypromowanie swojego WebGPU. Jeśli zaś The Khronos Groupprzeforsuje swoje własne meta-API, Apple będzie musiało chcąc czynie chcąc wprowadzić je do WebKitu i przeglądarki Safari. Internetto bowiem nie App Store, tu Apple musi się liczyć z realnymistandardami – w przeciwnym wypadku użytkownicy jego wcale nie takpopularnych systemów zostaną pozbawieni dostępu do niektórychtreści.
Można więc sobie wyobrazić scenariusz, w którym The KhronosGroup przehandluje swoje poparcie dla apple’owego WebGPU, w zamianza otwarcie iOS-a i macOS-a na Vulkana. Wówczas Metal straciłbyznaczenie, pozostałby może przez kilka lat niszowym API, by zczasem zostać zapomnianym. Na rynku pozostałyby dwa niskopoziomoweinterfejsy grafiki, tj. Vulkan dla wszystkich i DirectX 12 dlasystemów z getta Microsoftu. Taki obrót sprawy byłby chybanajlepszym z możliwych, bo raczej trudno sobie wyobrazić, by wRedmond kiedykolwiek mogli zrezygnować z własnych, niestandardowychAPI grafiki.
