DirectX 10 i Shader Model 4.0

Od chwili premiery pierwszych kart graficznych zgodnych ze standardem DirectX 9 i cieniowania 2.0 (Shader Model 2.0) jesteśmy kuszeni obietnicami gier o "kinowej grafice". Już w roku 2002 nVidia w swojej premierowej serii GeForce FX szczyciła się 'potęgą grafiki kinowej jakości'. Co zabawne, hasło to padało również przy okazji kart FX 5200. Podejrzewamy, że żaden z dziesiejszych posiadaczy FX 5200 nie podziela tego optymizmu, jakim trzy lata tryskała nVidia ;)

Nie mniej spektakularne obietnice serwowała nam firma ATi jeszcze za czasów premiery kart Radeon X800 - The future of PC gaming, Hollywood style.

"Kinowa' Ruby w makijażu z ShaderModel 2.0

Mamy tymczasem rok 2006, minęły cztery lata od wprowadzenia DirectX9 i dwa od zaprezentowania sprzętu zgodnego z Shader Model 3.0. Tak po prawdzie nawet nie posmakowaliśmy jeszcze pełnych możliwości DirectX9c i tej 'kinowej jakości grafiki'.

Mimo to przemysł przygotowuje się na nadejście kolejnej odsłony DirectX. Premiera 'dziesiątki' niesie ze sobą olbrzymi potencjał dla graczy, ale także i spore koszty jakie musi ponieść, jeżeli weźmie się pod uwagę maksymalne możliwe wrażenia, które DirectX 10 jest w stanie nam zaoferować.

Dawno dawno temu w komputerowym średniowieczu istniało kilka sposobów na osiągnięcie sprzętowej akceleracji grafiki trójwymiarowej. Dwie najbardziej powszechne metody obejmowały OpenGL i Glide 3dfx. Glide wymagał użycia specjalnego sprzętu 3dfx, podczas gdy OpenGL stanowił otwartą platformę obsługiwaną przez społeczność, która działała także pod Linuxem.

Za sprawą Windowsa, Microsoft postanowił skorzystać na nowych multimediach. Opracował zestaw API (interfejsów programowych aplikacji), które pozwalały twórcom oprogramowania i sterowników, odwoływać się do sprzętu i jego konkretnych funkcji. DirectX stał się ogólnym pojęciem, które obejmowało określone składniki takie jak Direct Sound, Direct Input, Direct 3D i inne.

DirectX ewoluował. DirectX 3, DirectX 5 (nie było DirectX 4 od razu przeskoczono na 5), DirectX 6, 7, 8, a teraz 9. Każda wersja oferowała nowy zestaw funkcji i większe możliwości.

DirectX 8 uznawany jest za początek programowalnych shaderów. Zanim nadszedł, wszystkie programowane funkcje były funkcjami ustalonymi, co oznaczało, że twórcy gier mogli korzystać jedynie z efektów 3D, które obsługiwał dany układ graficzny. Na przykład, jeśli układ graficzny (nie nazywamy stało-funkcyjnych procesorów graficznych procesorami GPU, ponieważ nie są one programowalne) nie obsługuje 'dot3 product bump mapping', nie ma możliwości, aby producent wykorzystał w swojej grze taki efekt.

Wszystko zmieniło się za sprawą programowalnych procesorów graficznych. Od tej chwili producenci gier mogli korzystać z dowolnego efektu, który tylko przyszedł im do głowy. Jednakże w pierwszych wersjach DirectX istniały pewne ograniczenia dotyczące liczby stałych, rejestrów i długości programu, który mógł być wykorzystany. DirectX 8 i 8.1 wprowadziły nas w świat GPU, czyli graficznych jednostek przetwarzania i zawierały Shader model 1.1 - 1.4. (tylko DX8.1 miał SM 1.4). Shader Model odnosił się do cech i możliwości programowania API.

dawno dawno temu, podczas premiery kart Radeon 8500, porównywaliśmy różnicę pomiędzy Shader Model 1.3 a 1.4 :)

DirectX 9 usamodzielnił GPU. W chwili wprowadzenia, DirectX 9 zawierał Shader Model 2.0. Stanowił on milowy krok w porównaniu do Shader Model 1.4. Mimo tego, DirectX 9 ma jeszcze większy zapas. Wraz z nim 9.0c nadszedł Shader Model 3.0. Nowsza wersja oznaczała w zasadzie nieograniczone długości programów i możliwości, o których można było dotąd tylko marzyć w przypadku GPU. Jednakże nigdy nie widzieliśmy, aby ten potencjał był w pełni wykorzystany w grach, ze względu na ograniczenia w wydajności sprzętu. API wciąż zapewnia większe możliwości niż sprzęt jest w stanie obsłużyć.

Mimo, że wciąż w DirectX 9 i Shader Model 3.0 pozostawiono zapas funkcji, które można wykorzystać w grach, pora, aby przedstawić kolejną odsłonę oprogramowania, mianowicie...

W przeciągu ostatnich kilku lat nazywano go w różny sposób, co wywoływało sporo nieporozumień. API był znany jako DirectX Next, Windows Graphics Foundation 1.0 i 2.0, ale także pod przezwiskiem DX10. Teraz, skoro wiemy już co i jak się nazywa, powstaje pytanie gdzie go można dostać?

DirectX 10 będzie dostępny dla użytkowników systemu Windows Vista w momencie jego premiery. Na próżno szukać wersji wypuszczonej dla Windowsa XP. DirectX 10 jest głęboko osadzony w sposobie działania Windowsa Vista i z tego co wiemy Microsoft nie ma planów, które obejmowałyby oficjalną obsługę nowego API przez Windows XP.

W Windows Vista wbudowano także DirectX 9.0L, który ma zapewnić kompatybilność ze składnikami DirectX 9. Należy o nich myśleć jak o dwóch odrębnych systemach. DirectX 9.0L otrzymamy dla sprzętu zgodnego z DirectX 9, a DirectX 10 dla sprzętu kompatybilnego z DirectX 10.

To oznacza, że jeśli chcecie korzystać z DirectX 10, prawdopodobnie będziecie musieli zdecydować się na Windows Vista. Rzecz jasna konieczny będzie sprzęt zgodny z DirectX 10 i oczywiście gry napisane pod jego kątem.

Oczywiste pytanie, które nasuwa się graczom, brzmi: czy ten wyjątkowo drogi i uciążliwy proces 'upgrade'u' dostatecznie wyraźnie poprawi doznania, aby zrównoważyć koszty modernizacji? To niestety dopiero się okaże. Póki co, możemy bazować tylko na istniejących grach. Możemy za to przeanalizować możliwości DirectX 10 oraz zunifikowanej architektury i zastanowić się jak mogą one przysłużyć się graczom.

Zanim zaczniemy mówić o nowościach w DirectX 10, powinniśmy zrozumieć na czym polega i jak działa DirectX 9. Mimo, że DirectX 9 stanowił olbrzymi krok naprzód w porównaniu do 'ósmeki', wciąż miał swoje ograniczenia.

Jednym z największych i najbardziej dotkliwych ograniczeń jest API 'object overhead' (narzut obiektów API). W rzeczywistości twórcy gier są ograniczani przez owy narzut. Spośród wszystkich poprawek i udoskonaleń, które mogły być wprowadzone do DirectX 10, sprawą najwyższej wagi dla większości producentów gier było zmniejszenie 'object overhead'.

Przez API 'object overhead' rozumiemy proces, w którym API wykorzystuje cykle procesora, aby wykonać zadania wymagane do renderowania zanim zostaną one przesłane do karty wideo i narysowane. Zanim API w ogóle wejdzie w interakcję z GPU karty graficznej podczas renderowania gry, aplikacja musi najpierw odwołać się do API, a ten do sterowników. Wszystkie te odwołania obsługiwane są przez CPU przy wykorzystaniu cennych zasobów co wywołuje potencjalne spowolnienie procesu.

czas wykonania w przypadku DirectX 9

- i czas wykonania w przypadku DirectX 10

W skład tych procedur wchodzą ograniczenia dotyczące liczby obiektów, które mogą być wyświetlone równocześnie w jednej klatce na ekranie. W grze obiekt może stanowić cokolwiek. Może to być postać lub na przykład drzewo. Obecne ograniczenia przewidują do 500 obiektów w jednej klatce. Jeśli limit ten zostanie przekroczony będziemy mieli do czynienia z poważnym korkiem. Twórca musi zręcznie żonglować obiektami w grze, tak aby ich limit nie został przekroczony i nie zostały one zahamowane przez ograniczenia w oprogramowaniu i procesorze.

Niesie to ze sobą szerokie limity w doznaniach oferowanych przez grę. Weźmy pod lupę dla przykładu drzewa. W chwili obecnej większość drzew tworzy się poprzez kopiowanie przykładowego egzemplarza; możliwa jest też zmiana jego koloru i liczby liści. Tak tworzy się lasy. Ograniczeniem w tym momencie jest fakt, że nie da się wyświetlić tysięcy różnych drzew w jednej klatce w czasie rzeczywistym. DirectX 10 zniesie to ograniczenie.

przykładowy poziom ilości obiektów w jednej scenie, w nadchodzącej grze zgodnej z DX10 - World in Conflict

Na ilustracjach poniżej można zobaczyć w jaki obiekt jest przekazywany z aplikacji do API, a następnie do sterownika.

W czasie swojej podróży niesie on ze sobą pewien narzut (overhead). Narzut ten wydłuża czas wykonania, co w praktyce oznacza mniejszą wydajność. Problem ten jest potocznie zwany 'Small Batch Problem', czyli problemem małych porcji.

Kolejnym ograniczeniem związanym z DirectX 9 i obecnymi procesorami graficznymi, jest natura ustalonych ścieżek przetwarzania potokowego. W GPU przetwarzanie vertexów i pikseli jest oddzielone za pomocą odkreślonej liczby procesorów przeznaczonych dla obu. Dla przykładu, w obecnej technologii X1900 XTX jest 8 ustalonych jednostek vertex i 48 ustalonych jednostek przetwarzania pikseli. W przypadku tej architektury można popaść w tarapaty w scenach, które wymagają dużej mocy obliczeniowej dla vertexów, szczególnie jeżeli ma się do dyspozycji tylko 8 jednostek.

tradycyjny GPU z ustalonymi jednostkami Vertex i Pixel Shader:

czasami może 'marnować' się moc jednostek Pixel, a czasami nie są wykorzystywane wszystkie jednostki Vertex Shader

Powszechnym zjawiskiem we współczesnych grach staje się takie konstruowanie poszczególnych scen, aby miały one duże wymagania przetwarzania pikseli i vertexów. Przy obecnych ograniczeniach sprzętu, silnik vertex może być niemiłosiernie obładowany (w obszernych w vertexy sceneriach) podczas gdy procesory pixel shader będą bezczynne. Może też mieć miejsce odwrotna sytuacja, w której scena wymaga wielu obliczeń pixel shader, a jednostki vertex nie mają nic do roboty. Powstaje przez to niewyważony silnik przetwarzania. Nadchodzące tytuły będą miały coraz więcej scen, które wykorzystują dużą liczbę przetwarzania zarówno vertex shaderów jak i pixel shaderów.

Ponieważ DirectX 10 jest nowym API, napisanym całkowicie od podstaw, spora część poprzedniego narzutu może być zredukowana. Narzut obiektów jest znacząco obniżony, dzięki czemu więcej obiektów może zostać równocześnie wyświetlonych na ekranie.

W świecie rzeczywistym nie istnieją dwa identyczne obiekty, nawet jeśli wyglądają tak samo. W chwili obecnej w grach spotyka się przedmioty, które wyglądają identycznie. To samo tyczy się trawy, drzew i każdego innego obiektu. Patrzenie na wierne kopie odbiera twórcom gier poczucie realizmu, do którego tak usilnie dążą.

'Matrixowy' las w grze Oblivion

W tej chwili większość trawy widocznej na przykład na polu bitwy to po prostu kopie jednego źdźbła. Podobnie ma się rzecz z inną roślinnością, która również jest tylko kopią jakiegoś wzoru. Jedynie proste zmiany w nasyceniu i kolorze służą do różnicowania obiektów.

... i las w nadchodzącej grze Crysis - DX10

W grach przyszłości możliwe będzie wykorzystanie setek, jeśli nie tysięcy odrębnych obiektów. Dzięki możliwościom DirectX 10 uda się pokazać więcej unikalnych obiektów, które stworzą bardziej złożone i realistyczne środowiska. Oczywiście sprzęt będzie nadal stanowił barierę w obliczeniach i renderingu, ale przynajmniej producenci gier nie będą ograniczani przez API. Wydajność graficznych procesorów stanie się decydującym czynnikiem, przynajmniej w przewidywalnej przyszłości.

Przy mniejszym narzucie, czas wykonywania jest znacznie redukowany. W chwili obecnej w większej części DirectX 9, API i sterownik pożerają do 40% czasu wykonywania. W przypadku DirectX 10 wartość ta obniżona jest o połowę, dając tym samym więcej czasu dla gier lub aplikacji. W praktyce oznacza to, że twórcy gier mogą je naszpikować większą liczbą unikatowych obiektów i poprawić wrażenia wizualne.

Jedną z nowych cech dodanych do DirectX 10 jest nowa faza w przetwarzaniu potokowym nazywana Geometry Shader. Na poniższej ilustracji można zobaczyć jak została ona wpasowana w schemat architektury ustalonego przetwarzania potokowego.

Została ona umieszczona pomiędzy jednostkami Vertex i Pixel. Nowy shader może 'brać' trójkąty i traktować je jak obiekty, kontrolując ich wierzchołki. Podstawowe dane przesyłane są następnie do Pixel Shadera. Umożliwia to niektóre efekty takie jak 'Displacement Mapping' w czasie rzeczywistym, 'Stencil Shadow Extrusion', generownie 'Point-Sprite' z punktów, 'Motion Blur' i wiele innych, które możliwe są teraz dzięki sprzętowi DirectX 10.

Geometry Shader to nowa, bardzo, jeśli nie najbardziej interesująca funkcja wchodząca w skład DirectX 10, którą zainteresowani będą przede wszystkim twórcy gier.

DirectX 10 został stworzony pod kątem zunifikowanej architektury. Zunifikowana architektura API i GPU, zamiast stosować osobne jednostki, łączy jednostki tradycyjnego vertexu, geometrii i pikseli w jedną fazę przetwarzania. Tak więc API obsługuje wszystkie jednostki za pomocą pojedynczej fazy GPU, zamiast kilku, jak działo się to do tej pory.

W miejsce shaderów vertex, pixel i geometry mamy teraz jedną jednostkę, która zajmuje się wszystkimi zadaniami. W dzisiejszych czasach często jesteśmy świadkami marnowania możliwości jednostek przetwarzających w GPU przez aplikacje, które 'korkują' inne jednostki. Przed chwilą widzieliśmy jednostki Vertex Shader, które odpoczywały i czekały aż jednostki Pixel Shader uporają się ze swoim zadaniem lub na odwrót. Zunifikowana architektura powinna zaradzić takim sytuacjom i zredukować czas oczekiwania, a także marnowanie cyklów krzemu.

Podczas gdy DirectX 10 jest w stanie w pełni wykorzystać zunifikowaną architekturę procesorów graficznych, zunifikowany GPU nie musi wcale spełniać wymogów specyfikacji DirectX 10. Dlatego też można spotkać GPU z osobnymi jednostkami odpowiedzialnymi za vertex, geometrię i piksele, który jest w pełni zgodny z DirectX 10. Kluczowym elementem, który musi być obsługiwany przez niezunifikowany GPU jest nowy Geometry Shader, mogący pracować w architekturze ustalonego przetwarzania potokowego, tak jak pokazuje to powyższa ilustracja.

Jednym z pomysłów leżących u podstaw zunifikowanej architektury jest zmiana GPU z jedynie renderującego procesora, na układ zdolny do wszelkich obliczeń. W chwili obecnej procesor graficzny rysuje grafikę 3D i wyświetla ją na ekranie. Oczywiście ma więcej zadań na głowie, takich jak grafika 2D, czy wideo, ale dla potrzeb tego artykułu mamy na myśli przede wszystkim grafikę trójwymiarową. Za sprawą zunifikowanej architektury GPU staje się czymś więcej. Staje się procesorem, który jest w stanie zrobić prawie wszystko co wymaga przetwarzania kodu. Oznacza to, że GPU może przejąć takie funkcje jak fizyka, sztuczna inteligencja, animacja, a także wiele innych procesów, które wzbogacają doznania gracza. DirectX 10 i zunifikowana architektura GPU pomagają karcie wideo zmienić się we wszystkopotrafiący układ. Takie są przynajmniej założenia. Jak to będzie wyglądało w rzeczywistości zależy od twórców gier.

Na powyższej ilustracji widać, że pojawił się nowy arbiter wątków. Jednostka arbitra wysyła wątki do rdzenia, który stwierdza ile zasobów pixel, vertex i geometry shaderów potrzebuje dana scena. Jednostka ta pełni funkcję policjanta drogówki, który zajmuje się całym ruchem zmierzającym do GPU. GPU z kolei zajmuje się wszystkim co jest związane z renderowaniem sceny. Pozwala to na skorzystanie ze wszystkich zasobów podczas przetwarzania scen, bardzo obciążonych przez cieniowanie vertex i pixel. Arbiter wątków jest w stanie wysyłać wiele wątków równocześnie, tak jak ma to miejsce w przypadku wielowątkowości w CPU. Można zobaczyć jak wszystko to łączy się ze sobą na przykładzie wielowątkowego rdzenia wprowadzonego w technologii serii Radeon X1000. Seria X1000 może być uznawana za hybrydową Zunifikowaną Architekturę, ponieważ tylko mały kroczek dzieli ją z całkowicie Zunifikowaną Architekturą.

Widać także jak cała technologia została połączona w konsoli XBOX 360. XBOX 360 wykorzystuje technologię GPU ATI i należy do zunifikowanej architektury. Dlatego też ATI ma już na rynku pierwszą generację zunifikowanej architektury GPU. Jasną sprawą jest, że XBOX 360 jest daleko przed desktopowymi GPU jeżeli chodzi o technologię.

Ponieważ XBOX 360 reprezentuje pierwszą generację zunifikowanej architektury ATI, ich kolejna generacja desktopowego GPU będzie drugim pokoleniem technologii zunifikowanej architektury ATI. Oznacza to, że ATI skorzystała na tym czego nauczyła się w trakcie opracowywania zunifikowanej architektury XBOXa 360 i wprowadziła poprawki, aby stworzyć jeszcze lepszą zunifikowaną architekturę dla PC w postaci kolejnej generacji desktopowych GPU. Oznacza to także, że przenoszenie gier pomiędzy XBOXem 360, a desktopowymi sprzętem GPU ATI powinno być łatwiejsze.

DirectX 10 ma do zaoferowania graczom potencjał, który pozwoli na tworzenie bardziej unikatowych obiektów w grach. Oznacza to zwiększenie realizmu, głębokości i stopnia pochłonięcia przez grę.

Nowe cechy umożliwią powstanie nowych efektów w grach. W pełni programowalna zunifikowana architektura może otworzyć przed procesorami graficznymi nieograniczone możliwości, pozwalając im przetwarzać inne typy danych, a nie tylko renderowanie trójwymiarowego obrazu. GPU stopniowo staje się głównym obliczeniowym procesorem. Można sobie wyobrazić co wydarzy się w przeciągu kilku następnych lat w królestwie gier. Z pewnością będzie jeszcze bardziej ciekawie niż jest w tej chwili.

Firma ATi ściśle współpracuje z Microsoftem, aby mieć pewność, że API DirectX 10 i programowalność ich GPU będą dostępne dla twórców gier. Wygląda na to, że pałeczka została przekazana i w tej chwili wszystko zależy od producentów gier. Bez gier korzystanie z tych wszystkich dobrodziejstw nie ma sensu. Część potencjału DirectX 10 i zunifikowanej architektury dla gier obejmuje więcej różnorodnych obiektów, więcej materiałów, bardziej unikatową roślinność, więcej cieni, więcej fizyki (woda, zderzenia, materiały, włosy, cząstki), więcej efektów (oświetlenie, wolumetryczne efekty), animację postaci. Wszystkie te cechy da się skalować.

Cóż zatem to wszystko oznacza dla graczy? Potencjał kryjący się za nową technologią wygląda świetnie na papierze. Ponieważ DirectX10 jest związany z Windowsem Vista, korzystanie z dobrodziejstw i fajerwerków gier 3D opartych na DirectX 10 będzie wymagało systemu Windows Vista, karty wideo zgodnej z DirectX 10 i gry napisanej dla DirectX 10.

Jeśli wziąć pod uwagę koszty i rozmiar modernizacji, którą trzeba przeprowadzić, aby posiąść obsługę DirectX 10, graniu będą musiały towarzyszyć niespotykane dotąd efekty i doznania. Tylko one przyspieszą rozwój i przejście na DX10, a także pojawienie się odpowiedniego sprzętu.