r   e   k   l   a   m   a
r   e   k   l   a   m   a

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

Strona główna AktualnościOPROGRAMOWANIE

Jak do tej pory większość prezentowanych przez Microsoft ulepszeń w Windows 10 jest dość powierzchowna, związana nie tyle z samym systemem, co z interfejsem użytkownika i wspomagającymi aplikacjami. Nie znaczy to jednak, że wystarczy starszym wersjom Windows doinstalować kilka dodatkowych programików, by dorównywały nowej wersji systemu. Wiemy już na pewno, że biblioteki DirectX 12 będą tylko w Windows 10, choćby ze względu na wprowadzony nowy model sterowników graficznych. I właśnie ze względu na te biblioteki, Windows będzie długo mógł utrzymać swoją pozycję najlepszego systemu operacyjnego dla pecetowych graczy – obecnie ani OS X, ani desktopowy Linux nie mają niczego porównywalnego do Direct3D 12, odpowiedzialnego za trójwymiarową grafikę komponentu Direct X.

Czy komputer do gier musi kosztować grube pieniądze?

Problemy z wydajnością, jakich doświadczyli gracze Assasin's Creed: Unity nawet na najmocniejszych, kosztujących tysiące złotych kartach graficznych, jeszcze bardziej uwidocznił, jakim problemem są współczesne wysokopoziomowe interfejsy 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 trudem radzą sobie z nowymi produkcjami. Problem tkwi nie w wydajności samych kart, wciąż rosnącej w imponującym tempie, ale w wydajności procesorów głównych, która rośnie dziś bardzo powoli. Tymczasem korzystając z wysokopoziomowych graficznych API jesteśmy skazani na przygotowywanie danych dla GPU właśnie przez CPU, liczących to zwykle w jednym wątku (zadania te rzadko kiedy dobrze się paralelizują).

Tak było przynajmniej do czasów DirectX 9 – w większości jednordzeniowe procesory rozmawiały sobie z kartami graficznymi w jednym, głównym wątku. W DirectX 10 sytuacja się nieco polepszyła, możliwe stało się przesyłanie przez wiele rdzeni CPU danych 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ężniejsze karty graficzne, takie jak np. GTX 980, mają tysiące rdzeni graficzych, a jednak wskutek ograniczeń Windows, w danym momencie można komunikować się tylko z jednym z nich.

r   e   k   l   a   m   a

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

Niskopoziomowe programowanie grafiki na PC to temat modny od zeszłego roku, kiedy to AMD pokazało po raz pierwszy swój interfejs Mantle. Pomysł „czerwonej drużyny”, mimo zachęcającego wzrostu wydajności, nie zdołał wejść do mainstreamu, jedynie nieliczni producenci zdecydowali się na przepisanie swoich silników grafiki pod nowe API. Problem bowiem w tym, że mimo dobrej woli AMD, póki co pozostali producenci GPU Mantle się nie tykają.

Zupełnie inaczej jest w wypadku microsoftowego DirectX 12. Nie tylko pozwala ono na jednoczesną, równoległą komunikację między rdzeniami CPU i GPU, ale też umożliwia bezpośrednie zarządzanie przez program zasobami sprzętowymi karty graficznej i działa na 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 benchmarki potwierdzają już efektywność rozwiązania Microsoftu, szczególnie tam, gdzie karty graficzne zmuszone są obsłużyć dziesiątki tysięcy wywołań rysowania jednocześnie.

Podczas pierwszej oficjalnej prezentacji DirectX 12 mogliśmy zobaczyć wyniki dla dema Star Swarm, znanego już wcześniej z testów Mantle. To oczywiście optymalny dla niskopoziomowych API scenariusz testowy, wykorzystujący fakt, że wysokopoziomowe API nie radzą sobie z rozłożeniem wywołań rysowania na wiele rdzeni. Przy szczytowym obciążeniu Star Swarm potrafi wygenerować ponad 100 tysięcy wywołań, co ubić potrafi nawet Core i7 z GTX 980. Uzyskane FPS-y robiły wrażenie – w ekstremalnej jakości GTX980 pod 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ć ledwie 8,3 FPS, zaś pod DX 12 42,9 FPS. Co ciekawe, to wynik niewiele gorszy niż w wypadku Mantle, z którym wspomniany Radeon uzyskał 45,6 FPS.

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

Wszystko co trzeba wiedzieć o Direct3D 12, ale wstyd o to pytać

Za spektakularny wzrost wydajności grafiki, zapewniany przez DirectX 12, odpowiadają daleko posunięte zmiany architektoniczne. Nowy niskopoziomowy interfejs grafiki 3D dla Windows pod wieloma względami jest podobny do Mantle. Nie można jednak powiedzieć, że jest to po prostu klon Mantle, podobieństwo to raczej wynika z potrzeby rozwiązania tych samych problemów. Najważniejszą zmianą jest oczywiście pełna paralelizacja komunikacji między CPU a GPU, ale to nie koniec. Nowa wersja biblioteki przynosi cztery interesujące mechanizmy, dzięki którym znacznie wzrasta wydajność algorytmów związanych z ustawianiem przezroczystości, wykrywaniem kolizji czy nierysowaniem niewidocznej geometrii.

Obiekty stanu potoku (PSO)

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

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

Listy poleceń i zestawy

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 na pozostałych rdzeniach CPU poleceń, ale skuteczność ich działania jest ograniczona. W D3D 12 obciążenie robocze dla karty graficznej jest przygotowywane zupełnie inaczej. Wykorzystuje się tzw. listy poleceń (ang. command lists). Każda taka lista zawiera informacje o tym, na którym PSO pracuje, jakich zasobów potrzebuje i z jakimi argumentami ma wywoływać rysowanie. Jako że listy takie są od siebie niezależne, mogą być wstępnie wyliczane – i przekazywane do kolejki poleceń GPU według aktualnej potrzeby.

Obok list poleceń, D3D 12 pozwala też na stosowanie zestawów (ang. bundles). Zestawy obsługują dziedziczenie stanów, dzięki czemu można je wielokrotnie wykorzystywać. Zamiast np. stosować kilka różnych list do narysowania obiektów o takiej samej geometrii, różniących się tylko teksturami, można zapisać zestaw wykorzystujący daną geometrię i teksturę, a następnie odtworzyć go tyle razy, ile trzeba, za każdym razem ze zmienionym zasobem tekstury. Sterownik zajmie się przekładem poleceń zawartych w pakiecie tylko raz.

Sterty deskryptora oraz tabele

W D3D 11 proces łączenia obiektów z zasobami jest bardzo abstrakcyjny. To wygodne dla programistów, ale mało efektywne sprzętowo. Aplikacja tworzy sobie widoki zasobów, a następnie wiąże te widoki do (ograniczonych w liczbie) slotów na różnych etapach potoku grafiki. Gdy przychodzi czas na rysowanie, shadery odczytują dane ze wskazanych im powiązanych slotów. Gdy trzeba zmienić wykorzystywane zasoby, trzeba powiązać je na nowo ze slotami i wywołać rysowanie.

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

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

Kompresja zasobów

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

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


Czary z mleka? Niestety nie, Wiedźmin 3 dalej będzie mordował sprzęt

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

Na szczęście w większości wypadków robota ta spadnie nie tyle na twórców gier, co twórców silników grafiki gier. Pierwsze dostosowane do DX12 silniki już powstają, na czele z Nitrous, na bazie którego działa wspomniane demo Star Swarm, i który jest wykorzystywany w niecierpliwie wyczekiwanej grze Star Control. Nowe DirectX 12 wspierane jest też przez deweloperską wersję słynnego silnika Unreal Engine 4.

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

Finalnie trzeba podkreślić, że realny wzrost wydajności w grach zawsze będzie niższy, niż w specjalizowanych demach. W teorii na samej paralelizacji komunikacji między CPU a GPU powinniśmy uzyskać wyniki lepsze o (n-1)*100%, gdzie n to liczba wykorzystanych przez grę rdzeni CPU, ale trzeba pamiętać, że nie wszystkie operacje się równie dobrze paralelizują, nie zawsze też będziemy mieli zawsze wolne rdzenie GPU do dyspozycji. Jedno jednak jest pewne – tegoroczne targi GDC 2015, podczas których możemy się spodziewać oficjalnej premiery DirectX 12, będą bardzo ciekawe. I to nie tylko dla fanów rozwiązań Microsoftu, gdyż członkowie Grupy Khronos, w tym AMD, intensywnie pracują nad OpenGL Next. 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 Linuksowi czy Makowi, ale też wpłyną na większą wydajność grafiki w przeglądarkach (przez WebGL) czy urządzeniach mobilnych (przez OpenGL ES).

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.