Windows 10 to nie tylko pulpitowe „bajery”. Direct3D 12 jest nową erą grania na PC

Problemy z wydajnością, jakich doświadczyli gracze Assasin'sCreed: Unity nawet na najmocniejszych,kosztujących tysiące złotych kartach graficznych, jeszcze bardziejuwidocznił, jakim problemem są współczesne wysokopoziomoweinterfejsy grafiki. Te API powstałe po to, by poradzić sobie z dużąróżnorodnością sprzętu i ułatwić programowanie, sprawiajązarazem, że nawet najnowsze karty graficzne z coraz większym trudemradzą sobie z nowymi produkcjami. Problem tkwi nie w wydajnościsamych kart, wciąż rosnącej w imponującym tempie, ale wwydajności procesorów głównych, która rośnie dziś bardzopowoli. Tymczasem korzystając z wysokopoziomowych graficznych APIjesteśmy skazani na przygotowywanie danych dla GPU właśnie przezCPU, liczących to zwykle w jednym wątku (zadania te rzadko kiedydobrze się paralelizują).

Tak było przynajmniej do czasów DirectX 9 – w większościjednordzeniowe procesory rozmawiały sobie z kartami graficznymi wjednym, głównym wątku. W DirectX 10 sytuacja się niecopolepszyła, możliwe stało się przesyłanie przez wiele rdzeni CPUdanych do GPU. Problem w tym, że cały potok grafiki i tak byłszeregowy, więc w danej jednostce czasu jeden rdzeń CPU rozmawiałz jednym rdzeniem GPU. Tak to niestety wygląda – najpotężniejszekarty graficzne, takie jak np. GTX 980, mają tysiące rdzenigraficzych, a jednak wskutek ograniczeń Windows, w danym momenciemożna komunikować się tylko z jednym z nich.

Dla twórców gier najlepszym sposobem na to, by pozbyć się tegowąskiego gardła była rezygnacja z wysokopoziomowych interfejsówgrafiki, takich jak Direct3D czy OpenGL – tak robiono to nakonsolach. W świecie tych przewidywalnych urządzeń o dobrze znanejkonstrukcji od dawna programuje się tak „blisko” sprzętu, jakto jest tylko możliwe, by uzyskać możliwie najwyższą wydajność.Właśnie dzięki temu konsole były w stanie rywalizować zeznacznie wydajniejszymi od nich pecetami. Niskopoziomowy stylprogramowania oznacza, że niepotrzebne stają się „ciężkie”dla procesora głównego interfejsy, a pozostałe zadania łatwiejrozłożyć na wiele rdzeni procesora.

Niskopoziomowe programowanie grafiki na PC to temat modny odzeszłego roku, kiedy to AMD pokazało po raz pierwszy swójinterfejs Mantle. Pomysł „czerwonej drużyny”, mimozachęcającego wzrostu wydajności, nie zdołał wejść domainstreamu, jedynie nieliczni producenci zdecydowali się naprzepisanie swoich silników grafiki pod nowe API. Problem bowiem wtym, że mimo dobrejwoli AMD, póki co pozostali producenci GPU Mantle się nietykają.

Zupełnie inaczej jest w wypadku microsoftowego DirectX 12. Nietylko pozwala ono na jednoczesną, równoległą komunikację międzyrdzeniami CPU i GPU, ale też umożliwia bezpośrednie zarządzanieprzez program zasobami sprzętowymi karty graficznej i działana praktycznie wszystkich używanych dziś przez graczy PC układach.Wspiera zintegrowaną grafikę procesorów Intel Haswell i nowszych,układy graficzne Nvidii w architekturze Fermi, Kepler i Maxwell,oraz Radeony z rdzeniami GCN 1.0, 1.1 i 1.2. Pierwsze benchmarkipotwierdzają już efektywność rozwiązania Microsoftu, szczególnietam, gdzie karty graficzne zmuszone są obsłużyć dziesiątkitysięcy wywołań rysowania jednocześnie.

Podczas pierwszej oficjalnej prezentacji DirectX 12 mogliśmyzobaczyć wyniki dla dema Star Swarm, znanego już wcześniej ztestów Mantle. To oczywiście optymalny dla niskopoziomowych APIscenariusz testowy, wykorzystujący fakt, że wysokopoziomowe API nieradzą sobie z rozłożeniem wywołań rysowania na wiele rdzeni.Przy szczytowym obciążeniu Star Swarm potrafi wygenerować ponad100 tysięcy wywołań, co ubić potrafi nawet Core i7 z GTX 980.Uzyskane FPS-y robiły wrażenie – w ekstremalnej jakości GTX980pod kontrolą DX 11 uzyskał ok. 26,7 FPS, podczas gdy pod kontroląDX 12 aż 66,8 FPS. Radeon R9 290X zdołał pod DX 11 uzyskać ledwie8,3 FPS, zaś pod DX 12 42,9 FPS. Co ciekawe, to wynik niewielegorszy niż w wypadku Mantle, z którym wspomniany Radeon uzyskał45,6 FPS.

Jak więc widać, dzięki niskopoziomowemu API możliwe jestznaczące zwiększenie wydajności, dzięki któremu nawet karty zniższej półki, a nawet grafika zintegrowana, będą mogłyzachwycić efektami, po których dotychczasowe gry zaczną wydawaćsię nam czymś retro. Nic więc dziwnego, że producenci gier wolelipoczekać z adaptacją swoich silników pod niskopoziomowe API. Jeśliróżnice w wydajności między Mantle a DX 12 sprowadzają się dokilku procent, a ten ostatni będzie działać na wszystkich GPU, torachunek jest prosty.

Za spektakularny wzrost wydajności grafiki, zapewniany przezDirectX 12, odpowiadają daleko posunięte zmianyarchitektoniczne. Nowy niskopoziomowy interfejs grafiki 3D dlaWindows pod wieloma względami jest podobny do Mantle. Nie możnajednak powiedzieć, że jest to po prostu klon Mantle, podobieństwoto raczej wynika z potrzeby rozwiązania tych samych problemów.Najważniejszą zmianą jest oczywiście pełna paralelizacjakomunikacji między CPU a GPU, ale to nie koniec. Nowa wersjabiblioteki przynosi cztery interesujące mechanizmy, dzięki którymznacznie wzrasta wydajność algorytmów związanych z ustawianiemprzezroczystości, wykrywaniem kolizji czy nierysowaniem niewidocznejgeometrii.

W D3D 11 możemy manipulować stanem potoku na wszystkich jegoetapach za pomocą wzajemnie niezależnych mechanizmów. Tooczywiście bardzo wygodne dla programisty, ale już nie dla sprzętu.Wysokopoziomowe abstrakcje potoku grafiki nie przekładają się naarchitekturę sprzętową, gdyż oddzielone w API etapy często mająjedną realizację sprzętową. Dlatego sterownik grafiki nie możeniczego zrobić do momentu wyliczenia całego stanu tuż przedrozpoczęciem rysowania. To prowadzi do sporego narzutu i ograniczaliczbę wywołań rysowania na klatkę.

W D3D 12 używane są obiekty stanu potoku (ang. pipeline stateobjects – PSO), łączące większość stanu potoku wniezmienne struktury, finalizowane w momencie ich powołania. PSO sąod razu przekształcane w polecenia procesora graficznego. Wciąż jemożna dynamicznie zmieniać, ale w tym celu wystarczy skopiować doGPU wstępnie wyliczony stan, zamiast wyliczać go „na żywo”.Pozwala to na znaczne zmniejszenie narzutu CPU i zwiększenie liczbywywołań rysowania w klatce.

D3D 11 pozwala na jeden strumień poleceń, które trafiająbezpośrednio do GPU. Stosowane są oczywiście różne sztuczki,pozwalające na odroczenie przesłania wcześniej przygotowanych napozostałych rdzeniach CPU poleceń, ale skuteczność ich działaniajest ograniczona. W D3D 12 obciążenie robocze dla karty graficznejjest przygotowywane zupełnie inaczej. Wykorzystuje się tzw. listypoleceń (ang. command lists). Każda taka lista zawierainformacje o tym, na którym PSO pracuje, jakich zasobów potrzebujei z jakimi argumentami ma wywoływać rysowanie. Jako że listy takiesą od siebie niezależne, mogą być wstępnie wyliczane – iprzekazywane do kolejki poleceń GPU według aktualnejpotrzeby. Obok list poleceń, D3D 12 pozwala też nastosowanie zestawów (ang. bundles).Zestawy obsługują dziedziczenie stanów, dzięki czemu można jewielokrotnie wykorzystywać. Zamiast np. stosować kilka różnychlist do narysowania obiektów o takiej samej geometrii, różniącychsię tylko teksturami, można zapisać zestaw wykorzystujący danągeometrię i teksturę, a następnie odtworzyć go tyle razy, iletrzeba, za każdym razem ze zmienionym zasobem tekstury. Sterownikzajmie się przekładem poleceń zawartych w pakiecie tylko raz.

W D3D 11 proces łączenia obiektów z zasobami jest bardzoabstrakcyjny. To wygodne dla programistów, ale mało efektywnesprzętowo. Aplikacja tworzy sobie widoki zasobów, a następniewiąże te widoki do (ograniczonych w liczbie) slotów na różnychetapach potoku grafiki. Gdy przychodzi czas na rysowanie, shaderyodczytują dane ze wskazanych im powiązanych slotów. Gdy trzebazmienić wykorzystywane zasoby, trzeba powiązać je na nowo zeslotami i wywołać rysowanie.

D3D 12 jest tu jeszcze lepsze, niż mikroarchitekturaKepler Nvidii, która jako pierwsza zerwała z ograniczonąliczbą slotów dla zasobów. Rozwiązanie Microsoftu nie tylkopozwala na zastosowanie ograniczonej jedynie pojemnością pamięciliczby zasobów, ale eliminuje narzut związany z ich wiązaniem. Wtym celu wykorzystywane są sterty deskryptora (ang. descriptorheaps), na których aplikacja może sobie układaćwidoki, będące natywnym dla GPU opisem zasobów, który możnauprzednio przenieść do pamięci i wywoływać w razie potrzeby. Gdytrzeba wybrać konkretny zasób, aplikacja zmienia jedynie tabelęzawierającą zakres sterty do wykorzystania, co jest obliczeniowozdecydowanie mniej kosztowne.

Twórcy Direct3D 12 zwracająuwagę na jeszcze jedną ciekawą nowość w tej kwestii: wshaderach można teraz będzie dynamicznie indeksować zasoby, bezkonieczności stosowania jakichś pośrednich buforów,przechowujących tekstury czy obiekty. Do tej pory programiścimusieli uważać, by do bufora takiego nie trafiało zbyt wielezasobów, bo jego przeszukiwanie znacząco zwalniało renderowanie.Renderowanie sceny korzystającej z setek różnych materiałów mabyć równie szybkie, co renderowanie sceny z ledwie kilkomamateriałami.

Kilka lat temu w OpenGL zadebiutował algorytm ASTC– stratny blokowy mechanizm kompresji tekstur, dający programistomznacznie lepszą kontrolę nad stosunkiem jakość/rozmiar bitmapyniż w normalnych algorytmach kompresji. Dzięki niemu można wskazaćte obszary, którym należy się lepsza jakość, wyższa głębiakolorów itp. Wygląda na to, że Direct3D 12 zapewni wsparcie nietylko dla ASTC, wspieranego przez większość nowych GPU, ale teżwsparcie dla sprzętowej kompresji formatu JPEG, dziś w sprzęcienieobecnej.

W czasach, gdy rozmiary nowych gier idą w dziesiątki gigabajtów(a spora tego część to właśnie nielekkie tekstury), efektywnakompresja przyniesie same korzyści – mniejsze obciążenie sieci,mniejszy rozmiar aplikacji w pamięci komputera i mniejsze obciążeniepamięci procesora podczas wywoływania zasobów.

Jak widać, Direct3D 12 to wielki krok naprzód – sama tylko tabiblioteka uzasadniałaby dla graczy kupienie licencji na Windows 10.Trzeba jednak powiedzieć to jasno, w pierwszych miesiącach odpremiery pożytku z niej wielkiego nie będziemy mieli.Zainstalowanie Windows 10 nie sprawi, że nasze gry, na czele zWiedźminem 3, znacznie przyspieszą. Tak stanie się dopiero wwypadku nowych tytułów, pisanych z myślą o DirectX 12, i to przezprogramistów, którzy nauczyli się paralelizować styk CPU-GPU, takby cztery i więcej rdzeni współczesnych procesorów miały corobić. Na pewno noweniskopoziomowe API spodoba się ludziom piszącym gry na konsole –oni przyzwyczajeni są do pracy blisko sprzętu, by pisać na DX12będą musieli się nauczyć jedynie składni tego interfejsu, alewiększość deweloperów zajmujących się PC będzie miałatrudniej – przecież wciąż większość gier nie potrafiefektywnie wykorzystać wielordzeniowej architektury.

Na szczęście w większości wypadków robota ta spadnie nie tylena twórców gier, co twórców silników grafiki gier. Pierwszedostosowane do DX12 silniki już powstają, na czele z Nitrous,na bazie którego działa wspomniane demo Star Swarm, i który jestwykorzystywany w niecierpliwie wyczekiwanej grze Star Control. NoweDirectX 12 wspierane jest też przez deweloperską wersję słynnegosilnika UnrealEngine 4.

To samo tyczy się Xboksa One. Dziś konsola Microsoftu korzystaze zmutowanej odmiany DirectX 11, z pewnymi dodatkami pozwalającymina bezpośredni dostęp przez interfejs do zasobów sprzętowych.Zapewne na pewnym etapie życia konsoli doczekamy się aktualizacjiprzynoszącej zmodyfikowane pod nią DirectX 12, ale nie oznacza to,że nagle PlayStation 4 stanie się przestarzałe. Do tego czasu Sonyalbo opracuje coś własnego, albo skorzysta z Mantle API,licencjonowanego od AMD, które na Radeonach jest przecież niecowydajniejsze.

Finalnie trzeba podkreślić, że realny wzrost wydajności wgrach zawsze będzie niższy, niż w specjalizowanych demach. Wteorii na samej paralelizacji komunikacji między CPU a GPUpowinniśmy uzyskać wyniki lepsze o (n-1)*100%, gdzie n to liczbawykorzystanych przez grę rdzeni CPU, ale trzeba pamiętać, że niewszystkie operacje się równie dobrze paralelizują, nie zawsze teżbędziemy mieli zawsze wolne rdzenie GPU do dyspozycji. Jedno jednakjest pewne – tegoroczne targi GDC 2015, podczas których możemysię spodziewać oficjalnej premiery DirectX 12, będą bardzociekawe. I to nie tylko dla fanów rozwiązań Microsoftu, gdyżczłonkowie Grupy Khronos, w tym AMD, intensywnie pracują nad OpenGLNext. Jest to przepisana na nowo wersja tego otwartego API,które również zapewnić ma niskopoziomowy dostęp do sprzętu.Wypracowane przez Khronosa rozwiązania pomogą nie tylko Linuksowiczy Makowi, ale też wpłyną na większą wydajność grafiki wprzeglądarkach (przez WebGL) czy urządzeniach mobilnych (przezOpenGL ES).