17-07-2009

Biblioteki graficzne DirectX 10, DirectX 10.1 i DirectX 11

Od dziesiątki do jedenastki
 
O bibliotekach graficzny DirectX słyszał chyba każdy użytkownik peceta, który choćby w najmniejszym stopniu interesuje się komputerowymi grami. Bez DX-ów nie obejdzie się dziś nawet najmniejsza napisana pod Windows aplikacja multimedialna. Może nie wszyscy o tym wiedzą, ale są one również niezbędne do uruchomienia graficznej powłoki systemu Windows Vista – interfejsu Aero. W specyfikacjach kart graficznych podkreśla się zaś sprzętową zgodność z taką czy inną ich wersją. Spróbujmy zatem odpowiedzieć na pytanie, czym są owe tajemnicze DirectX-y, za co odpowiadają one w systemie i co przyniosły ich nowe wersje DX10, DX10.1 oraz czego można się będzie spodziewać po wersji 11?
 
Wraz z rozwojem kart graficznych rozwijały się również biblioteki DirectX. Ich pierwsza wersja pojawiła się już w 1995 roku wraz z debiutem Windows 95. Stanowiły one wówczas duży przełom ułatwiający programistom tworzenie aplikacji działających w ten sam sposób na wszystkich dostępnych wówczas modelach kart graficznych i to bez potrzeby korzystania ze specyficznego dla różnych producentów akceleratorów 3D kodu.
 
Gdy Microsoft ogłosił premierę systemu Windows Vista, do użytkowników trafiła kolejna, mocno zmodyfikowana wersja DX-ów – DirectX 10. W lutym zeszłego roku gdy opublikowany został dodatek Service Pack 1 dla Visty, biblioteki DX zostały ponownie uaktualnione. Pierwszymi obsługującymi sprzętowo kartami zgodnymi z DirectX 10.1 były akceleratory ATI z serii Radeon 3800 HD. Obecnie do grona producentów sprzętu zgodnego z DX 10.1 dołączyła również Nvidia, która niecały miesiąc temu zaprezentowała nowe, 40-nanometrowe układy graficzne dla komputerów przenośnych. Chodzi tu o kości GTS 260M, GTS 250M, GT 240M, GT 230M oraz G210M. Tymczasem Microsoft kończy prace nad kolejną wersją bibliotek DirectX. DX 11. Znajdą się one w nowej odsłonie Windowsa – systemie Windows 7. Co więcej, zarówno programiści, twórcy gier komputerowych, jak i producenci sprzętu już od kilku miesięcy mogli skorzystać z odpowiedniego pakietu deweloperskiego SDK, który Microsoft udostępnił na swoich stronach (http://www.microsoft.com/downloads/details.aspx?FamilyId=5493F76A-6D37-478D-BA17-28B1CCA4865A&displaylang=en).
 
DirectX – a cóż to takiego
 
Na początku wyjaśnijmy czym są w ogóle biblioteki graficzne. Obecnie powszechnie wykorzystywane są dwa standardy takich graficznych bibliotek – wspomniany DirectX i OpenGL. Obydwie aplikacje to tak naprawdę (z punktu widzenia programisty) moduły graficznego interfejsu programistycznego API (Application Programming Interface). Jak część z Was z pewnością wie, w dowolnym API zawarte są wszystkie procedury, funkcje i interfejsy pozwalające, korzystającej z danego API aplikacji (np. grze lub programowi multimedialnemu), na sprawną komunikację zarówno z systemem operacyjnym, różnego rodzaju bibliotekami systemowymi, jak i sterownikami urządzeń. Innymi słowy w uproszczeniu, zarówno DirectX, jak i OpenGL pośredniczą w wymianie informacji pomiędzy np. grą, a sterownikami karty graficznej zainstalowanej w komputerze.

Źródło: GameProgramer.org

Nowym, niezależnym elementem w API DirectX 10 jest DirectX Graphics Infrastructure (na rysunku: DXGI), który pośredniczy w wymianie danych między aplikacją, a sterownikami. DXGI przejął na siebie część funkcji realizowanych wcześniej przez moduł Direct3D (na rysunku D3D).

Co więcej, DirectX i OpenGL unifikują jednocześnie przy tym możliwy do wykorzystania zestaw poleceń, rozkazów i instrukcji oraz wszelkie procedury związane ze wszystkimi aspektami tworzenia obrazu 3D. Mało tego, istnienie takich bibliotek jest bardzo ważne z punktu widzenia programistów przede wszystkim z jednego względu. Mogą oni skorzystać bowiem wyłącznie z poleceń zawartych w API i nie muszą wówczas pisać kilku niekompatybilnych ze sobą wersji tej samej aplikacji na powiedzmy karty firm Nvidia, AMD/ATI lub układy Intela. Po prostu, wystarczy, że programista posłuży się poleceniami i formatami danych dopuszczonymi przez dany interfejs API, a wynik na ekranie będzie zawsze (przynajmniej w teorii, o czym za chwilę) ten sam, niezależnie od typu akceleratora 3D znajdującego się w pececie.

OpenGL i DirectX działają na tym samy poziomie i realizują zbliżony schemat generowania grafiki.
Źródło: OpenGL.org

W tym miejscu warto dodać, że DirectX jest najpopularniejszą biblioteką graficzną wśród twórców gier. Znacznie mniej firm stosuje konkurencyjnego, bazującego na otwartych standardach OpenGL (pełna nazwa to: Open Graphics Library). Najbardziej znana, posługująca się nią „growa” firma to id Software, która stworzyła m.in. legendarnego Quake’a i Dooma. OpenGL jest zaś znacznie bardziej popularny w zastosowaniach profesjonalnych. Większość zaawansowanych aplikacji inżynierskich i naukowych, ze względu na otwartość standardu i jego obecność na różnych platformach systemowych, korzysta z OpenGL-a.
 
Sterowniki
 
Jak można się domyślić, „po drugiej stronie” bibliotek graficznych takich jak DirectX czy OpenGL znajduje się sterownik karty. Do zadań driverów należy przede wszystkim zamiana instrukcji i danych płynących z interfejsu API na informacje zrozumiałe bezpośrednio dla danego urządzenia. W wypadku kart graficznych, sterownik powinien zostać dostarczony przez producenta procesora graficznego. Wynika to z faktu, że producenci najlepiej wiedzą jak poszczególne funkcje graficzne i dane przetwarzane są w potoku graficznym, który realizowany jest bezpośrednio w GPU. Co więcej, ze względu na bardzo ostrą konkurencję, nie udzielają oni tego typu informacji firmom trzecim. Stąd praktycznie nie istnieją tworzone niezależnie od producenta sterowniki np. dla systemu Linux, lub są one nie do końca tak wydajne i funkcjonalne jak firmowe drivery.

Umiejscowienie sterowników i graficznych API w warstwowym modelu systemu operacyjnego.
Źródło: Wikipedia

Z drugiej strony należy pamiętać też o tym, że sterownik powinien mieć możliwie jak najmniej „do roboty”. Jeśli tylko coś się da bezpośrednio lub z jak najmniejszą ingerencją driverów przenieść z API do potoku graficznego realizowanego w procesorze graficznym, tym lepiej, ponieważ operacje graficzne będą przez kartę wykonywane wówczas najszybciej. Wynika to z faktu, że nie trzeba w takim wypadku zbyt mocno angażować do transformacji danych i instrukcji jednostki centralnej komputera. Z tego właśnie powodu producenci układów 3D starają się, żeby ich kości były jak najbardziej sprzętowo zgodne z bibliotekami graficznymi DirectX lub OpenGL. Co więcej, dobrze zaprojektowane sterowniki potrafią znacząco przyspieszyć działanie karty. Bywa, że kolejna, lepiej zoptymalizowana wersja sterowników może być szybsza od poprzedniej wersji nawet o kilkanaście procent! Źle napisany sterownik potrafi zaś spowolnić generowanie grafiki o 30–40%.

Źle pojęta optymalizacja sterowników pod względem ich wydajności prowadzi czasem do gubienia części efektów 3D. U góry, słynna kilka lat temu sprawa, gdy firma ATI w sterownikach do Radeona 8500 wprowadziła „optymalizację” polegającą na tym, że w grze Quake III celowo zmniejszono dokładność filtrowania tekstur po to, aby osiągnąć wyższą wydajność liczoną w fps-ach. Rysunek na dole przedstawia prawidłowo wygenerowaną klatkę obrazu w grze Quake III.

Z powyższych powodów inżynierowie projektujący układy graficzne, niezależnie od tego jak bardzo ich firmy ze sobą konkurują, zawsze ściśle współpracują z programistami tworzącymi taki czy inny API. Współpraca ma miejsce zarówno przy tworzeniu OpenGL-a, jak i DirectX-a. Co więcej, wspólne, międzyfirmowe zespoły inżynierów z Nvidii, AMD/ATI i Intela oraz programistów z Microsoftu i firm tworzących gry decydują również o tym, jak będzie wyglądała kolejna wersja bibliotek DirectX i czy należy wprowadzić już do niej nowe efekty graficzne, nowe elementy potoku graficznego, kolejne shadery, rejestry, sposoby kompresji tekstur, algorytmy oświetlenia itp. Mało tego, w takim gronie zapadają też decyzje o tym jak powinny być realizowane i z jaką dokładnością poszczególne efekty. Oczywiście nikt nie narzuca producentowi układu graficznego drogi realizacji danego efektu. Dlatego na przykład efekty oświetlenia sceny mogą być realizowane zarówno przez jednostkę T&L (Transform and Lighting), tak jak to miało miejsce w starszych kartach, bądź przez Vertex i Piksel Shadery, bądź zunifikowane shadery. Programista piszący grę wydaje komendę zgodną z API, sterowniki przekształcają ją na ciąg instrukcji odpowiednich dla danej karty, a na wyjściu otrzymujemy założony efekt – np. transformację piksela.
 
Określenie dokładności realizacji poszczególnych algorytmów wykorzystywanych w API do tworzenia sceny 3D jest istotne przede wszystkim z jednego powodu. Otóż, jak już wspomniałem, szczegółowa droga do tego, aby na ekranie uzyskać odpowiedni efekt graficzny, zależy tylko i wyłącznie od funkcji zaimplementowanych w strukturze danego GPU. Programista w ogóle nie musi wiedzieć jak realizowana jest w strukturze GPU dana instrukcja i czy dane przetwarzają np. moduły T&L czy jednostki zunifikowane – on programuje element zgodny z API na przykład zaimplementowany w API vertex shader o ściśle określonej liście rozkazów i rejestrów, mimo, że karta takowych w ogóle nie musi fizycznie mieć. To właśnie określenie dokładności realizacji poszczególnych efektów 3D sprawia, że mimo unifikacji wprowadzonej przez DirectX czy OpenGL, obraz wygenerowany przez różne modele procesorów graficznych, nawet pochodzących od tego samego producenta, może wyglądać zawsze nieco inaczej. Różnice te nie są zwykle duże (trudno je czasem wręcz zauważyć), ale zawsze muszą mieścić się w założonych przez standard granicach. Oczywiście, projektanci układów graficznych wiedząc jak ma wyglądać dany efekt, dążą też do tego, aby to co zobaczymy na ekranie, jak najbardziej zbliżone było do założonego w specyfikacji wzorca.
 
Co ciekawe, niewiele osób o tym wie, ale część funkcji obsługiwanych przez biblioteki może w ogóle nie zostać zaimplementowana w danej kości graficznej. Okazuje się bowiem, że do osiągnięcia zgodności z daną wersją bibliotek graficznych wystarczy to, że karta wykonuje przewidziane w specyfikacji podstawowe instrukcje i obsługuje najważniejsze formaty danych. W takim wypadku, bardziej zaawansowane instrukcje mogą być albo pomijane, albo realizowane za pośrednictwem emulacji efektu w sterownikach, bądź też, co ma miejsce najczęściej, zastępowane są innymi operacjami, z którymi radzi już sobie sprzętowo dany model GPU. Nie trzeba chyba dodawać, że w takim wypadku końcowy obraz nie zawsze wygląda już tak dobrze, jak założyli sobie twórcy gier. Co więcej, emulacja efektu w sterownikach trwa zwykle znacznie dłużej niż w wypadku jej sprzętowej implementacji.

Mimo, że formalnie dana karta graficzna jest zgodna z konkretną wersją bibliotek DirectX, to nie musi ona wspierać wszystkich efektów. Wówczas wyświetlany obraz odbiega od tego, generowanego przez kartę z pełnym wsparciem dla tej wersji DX-a. Widać to wyraźnie na poniższym przykładzie. U góry FarCry (DirectX 9.0c) na wbudowanym w chipset Intel 915G module graficznym GMA 900, który teoretycznie jest zgodny z DX 9.0c, ale nie ma dla tych bibliotek pełnego wsparcia sprzętowego oraz (u dołu) ta sama scena wyświetlana na Radeonie 9800.

Od DX 1.0 do DX 10
 
Jak już wspomniałem wcześniej, pierwsza wersja bibliotek graficznych DirectX zadebiutowała w sierpniu 1995 roku wraz z premierą systemu Windows 95. Najważniejszą, rewolucyjną, jak na owe czasy właściwością DX-ów było to, że porządkowały one sposób wyświetlania grafiki w ówczesnych aplikacjach 2D/3D i umożliwiły pisanie gier dla systemu Windows zastępując przy okazji znany z Windows 3.11 stosunkowo prosty graficzny interfejs 2D o nazwie WinG. Z dzisiejszej perspektywy wydaje się to dziwne, ale trzeba pamiętać, że ówczesne gry komputerowe korzystały z DOS-u i własnych, pisanych oddzielnie dla kart różnych producentów, procedur obsługi i generowania grafiki 3D.
 
Przełomem w generowaniu grafiki 3D okazały się jednak biblioteki DirectX 6.1 i 7.0, które pojawiły się odpowiednio w lutym i we wrześniu 1999 roku. Wprowadzono w nich po raz pierwszy elementy klasycznego już dzisiaj modelu generowania grafiki, polegającego na obsłudze potoków renderujących (DX 6.1) i sprzętowego wspomagania operacji geometrycznych i kalkulacji oświetlenia T&L (Transform and Lighting) – DX 7.0. Od tego czasu możemy tak naprawdę mówić o akceleratorach 3D, w takim znaczeniu jak rozumiemy to obecnie. Karty graficzne przejęły wówczas od CPU część, ale nie wszystkie, głównych elementów procesu generowania trójwymiarowej grafiki – wcześniej odpowiadały jedynie za akcelerowanie grafiki 2D, a przy tworzeniu grafiki 3D pełniły jedynie funkcje bufora ramki.
 
Warto w tym miejscu przypomnieć również, że pierwszą zgodną z DirectX 7.0, kartą graficzną obsługującą sprzętowo T&L był GeForce 256 (nazwa GeForce to akronim od angielskich słów Geometry Force). Wówczas to Nvidia wymyśliła też termin GPU (Graphics Processing Unit), analogiczny do skrótowca określającego procesor, CPU (Central Processing Unit). Nazwa GPU miała wówczas sugerować użytkownikom pecetów i komputerowym graczom, że układy graficzne są jednostkami samodzielnie przetwarzającymi większość operacji w strumieniu graficznym, co jak się okazało po latach nie było wcale dalekie od prawdy, choć z dzisiejszego punktu widzenia używanie zadomowionego już na dobre terminu GPU w stosunku do GeForce’a 256 było co nieco naciągane.

Nvidia GeForce 256 to pierwsza karta z wbudowanym modułem T&L i pierwszy akcelerator zgodny z DirectX 7.0.
Źródło: Asus

W 2000 roku pojawiła się kolejna wersja bibliotek DirectX – DirectX 8.0. Wprowadziła ona do kart graficznych model przetwarzania grafiki bazujący na cieniowaniu i programowalnych jednostkach Vertex i Pixel Shader. Co ciekawe, DX 8.0 powstała przede wszystkim ze względu na potrzeby pierwszej wersji konsoli do gier Microsoft Xbox. Jednostki Vertex i Pixel Shader mogą w dowolny, wymyślony przez programistę sposób modyfikować szkielet sceny, zmieniać nakładane na poszczególne obiekty tekstury, czy przekształcać pojedyncze piksele. Wszystko to odbywa się już w trakcie przetwarzania tych elementów w potoku graficznym. Co więcej, obiekty te mogą być też zmieniane na gotowej scenie 3D. Aby zmodyfikować przetwarzane obiekty programista musi się tylko posłużyć krótkimi programami shaderowymi. Za pomocą tych małych programików (proces programowania shaderowego przypomina proces programowania w języku C) twórca gry może stworzyć własne, nieosiągalne w inny sposób efekty graficzne – wszystko jest ograniczone tylko umiejętnościami i fantazją programisty. Oczywiście, nic nie stoi na przeszkodzie aby cały czas korzystać z zaszytych w DirectX standardowych funkcji. Są one dostępne również w najnowszych bibliotekach DirectX 11 – kolejne wersje bibliotek są zawsze pod względem programistycznym, ale niekoniecznie sprzętowym, kompatybilne wstecz ze starszymi graficznymi API.

Wracając na chwilę do terminu GPU, to tak naprawdę dopiero od chwili pojawienia się bibliotek DirectX 8.0 i zgodnych z nimi sprzętowo kart graficznych można mówić o przejęciu wszystkich istotnych funkcji strumienia graficznego przez układ graficzny. Dlatego też z czystym sumieniem mianem graficznego procesora GPU można nazywać tylko te układy, które są zgodne z tą lub wyższą wersją graficznego API Microsoftu.

Sukcesywnie pojawiające się na rynku nowe wersje bibliotek graficznych DirectX, a więc 8.1, 9.0, 9.0a, 9.0b i 9.0c oraz zgodnych z nimi kart, wprowadzały kolejne ulepszenia i modyfikacje do architektury cieniowania. Pojawiały się, co oczywiste, też implementacje nowych funkcji 3D, rozszerzenia rejestrów, rozszerzenia języka shaderowego (np. zwiększenie liczby argumentów, pojawienie się skoków warunkowych, pętli itp.) – wszystko to po to, aby ułatwić programistom tworzenie gier 3D i pozwolić na coraz to większe urealistycznienie generowanej przez karty trójwymiarowej grafiki. Nie będę tych zmian omawiał szczegółowo, gdyż artykuł musiałby się bardzo mocno rozrosnąć. Z niektórymi z nich możecie zapoznać się zerkając do poniższej tabelki. Jednak na następną dużą zmianę przyszło nam czekać do 30 listopada 2006 roku. Wtedy to oficjalnie zaprezentowano biblioteki DirectX 10, które znalazły się w systemie Microsoft Windows Vista.

Różnice między API DirectX 9.0c wykorzystywanym w Windows XP (u góry), a API DirectX 10 z Windows Vista (u dołu).
Źródło: Microsoft

Tabela 1: Ewolucja modeli cieniowania w bibliotekach DirectX - źródło: Nvidia

DirectX 10 – przepisane na nowo
 
Biblioteki DirectX w wersji 10, jak zapewne pamiętacie zostały napisane praktycznie zupełnie od nowa. Projekt ten znany były wcześniej pod trzema równolegle funkcjonującymi nazwami – Windows Graphics Foundation, DirectX 10 oraz DirectX Next. Ostatecznie przyjęta została ta druga nazwa, której z przyzwyczajenia używała większość osób.

O napisaniu bibliotek od nowa zadecydowały przede wszystkim trzy fakty. Po pierwsze były one tworzone od początku wyłącznie z myślą o nowym systemie operacyjny Windows Vista (bibliotek DX 10 i DX 10.1 nie ma dla Widows XP, podobnie nie będą dostępne również dla tego systemu DX 11). Po drugie, chciano maksymalnie zmniejszyć narzut interfejsu API na tworzenie grafiki (jest to tzw. API overhead), co w znaczący sposób pozwala przyspieszyć generowanie grafiki. Obsługa bibliotek graficznych, co oczywiste, wymaga zawsze pewnej mocy obliczeniowej procesora. Jak twierdzi Microsoft, dotychczas narzut na graficzny API zajmował ok. 40 procent cykli procesora przeznaczonych na generowanie grafiki, w DX10 jest to tylko ok. 20 procent.

Narzut ze strony sterownika w DirectX 9 i DirectX 10.
Źródło: ATI/AMD

Trzecim istotnym faktem wpływającym na to, iż postanowiono napisać graficzny API Windowsów od nowa było to, że chciano się przy okazji pozbyć wszystkich kumulujących się od czasów DirectX 6.1, trudnych do usunięcia w inny sposób ograniczeń i ciężkich do wykrycia drobnych błędów powodujących niedokładności i niejednoznaczności w generowaniu na różnych kartach trójwymiarowego obrazu. Co więcej, jeśli chodzi o obsługę sprzętu to DirectX 10 różnią się na tyle od swoich poprzedników, że nie zachowano w nim kompatybilności z poprzednimi bibliotekami graficznymi.
 
No dobrze, to w jaki zatem sposób Windows Vista współpracują ze starszymi kartami graficznymi? Problem ten rozwiązano w najprostszy możliwy sposób. Okazuje się bowiem, że w Vistę wbudowano specjalne, bazujące na DX 9.0c biblioteki DirectX 9.0L (L od legacy – dziedziczenie), które to właśnie odpowiadają za współpracę ze wszystkimi kartami poprzednich generacji. Co ważne, DirectX 9.0L i DirectX 10 nie mają ze sobą żadnych wspólnych elementów. Innymi słowy, należy je po prostu traktować jako dwa odrębne interfejsy API – DirectX 9.0L służy jedynie do obsługi starszych kart, a DirectX 10 to API współpracujący tylko i wyłącznie ze zgodnymi z nim akceleratorami nowej generacji.
 
DX10 – w środku w zasadzie bez zmian
 
Jeśli chodzi o nowości wprowadzone przez Microsoft w DirectX 10, to z punktu widzenia programisty można je nazwać kosmetycznymi. Wszystkie efekty realizowane w DX 10 można bowiem z powodzeniem zrealizować również korzystając z bibliotek DX 9. Programista musi się tutaj pisząc aplikację trochę więcej napracować. Wymagana jest też niekiedy większa liczba operacji realizowanych przede wszystkim przez CPU. Niemniej uzyskany efekt w DX9 będzie dokładnie taki sam jak w DX10, z tą różnicą, że w tym drugim wypadku gra powstanie znacznie szybciej.
 
Większość publikowanych w Internecie i w prasie zrzutów porównujących możliwości DX10 i DX9 (dwa z nich pokazujemy poniżej) należy zatem uznać za nieco naciągane pod względem marketingowym – podobnie jak porównania DX10 i DX11, o czym nieco dalej. Programy w DX9 i DX10 oferujące podobne efekty będą zatem działały mniej więcej z podobną wydajnością (oczywiście, jeśli będą uruchamiane na tym samym typie karty zgodnej zarówno z DX9, jak i DX10). Z punktu widzenia użytkownika nie ma zatem różnicy, które biblioteki zostały użyte. Natomiast duże różnice są właśnie od strony programowej. Po prostu żeby uzyskać ten sam efekt w DX10, programista musi się znacznie mniej namęczyć niż w wypadku DirectX 9. Gra na DX10 powstanie też szybciej. Wyjątek od tego co napisałem powyżej stanowią tylko efekty fizyczne realizowane przez pojawiające się w DirectX 10 Geometry Shader, o czym za chwilę.

Porównanie efektów graficznych uzyskanych za pomocą bibliotek DirectX 9.0 i DirectX 10.
Źródło: Techland

Najważniejszą wprowadzoną w programistycznych mechanizmach DirectX 10 zmianą jest wprowadzenie nowych pojemniejszych tablic tekstur (texture arrays), mieszczące do 512 pojedynczych tekstur oraz zaimplementowanie dodatkowych mechanizmów obsługi strumienia danych (stream out). Te ostatnie pozwalają wysłać w dowolnej chwili rezultaty pracy jednostek przetwarzania geometrii wprost do pamięci karty. Zoptymalizowano również algorytmy zarządzania dostępnymi również w DirectX 9 nieco mniej pojemnymi tablicami tekstur (do 128 lub 256, w zależności od formatu), zmieniono i przyspieszono procedury rysowania z wyprzedzeniem (predicated draw) i wysyłania strumienia danych. Co ważne, wymagają one teraz znacznie mniej „obsługowych cykli” ze strony jednostki centralnej.

W DirectX 10 niezachowano kompatybilności sprzętowo-programowej z wcześniejszymi wersjami graficznego API. Wynika to przede wszystkim ze zmienionej architektury systemu Windows Vista. Dzięki temu udało się wyeliminować wiele problemów związanych z dziedziczeniem błędów komunikacyjnych na styku sterowników, API i procedur zarządzających zasobami systemowymi.

We wcześniejszych niż DX 10 API obowiązywał też, nazwijmy go może „nieformalnym limitem” liczby obiektów wyświetlanych jednocześnie na scenie 3D oraz operacji wykonywanych na obrazie, takich jak zamiana tekstur, formatu danych dla jednostek Vertex i Pixel Shader i trybów mieszanych. Istotne jest tutaj to, że za obiekt uważa się w takim wypadku nie tyle pojedynczy trójkąt, czy wielokąt, ale złożoną z nich większą bryłę np. całą postać lub jej fragment (typu ręka, noga, głowa), kamień, drzewo, samochód, górę, rzekę itp. Wszystko co na scenie 3D można skalować przesuwać i obracać, traktowane jest tutaj jako całość. Każdy z tych obiektów może zaś składać się z dowolnej, nielimitowanej liczby (przeważnie kilkuset tysięcy lub nawet paru milionów) trójkątów. Ograniczenie zaś tych obiektów do podawanej w wielu źródłach liczby pięciuset, spowodowane było tylko i wyłącznie niewydolnością procedur komunikacyjnych między kartą graficzną i CPU, w których to pośredniczył API. Oczywiście można było wstawić na scenę więcej obiektów, ale procesor zbyt mocno się wówczas „przytykał”. Przepisanie na nowo DX-a wyeliminowało ten błąd i obecnie nie trzeba już np. tworzyć gęstego lasu z kilku modeli drzew, kopiując rośliny w różne miejsca, ale każde drzewo może być teraz oddzielnym, niepowtarzalnym obiektem. Jedynym ograniczeniem w tworzeniu liczby obiektów jest obecnie wyłącznie rzeczywista wydajność tandemu GPU i CPU, a nie sztuczny limit narzucony przez API.

Shader Model 4.0
 
Wraz z DirectX 10 pojawił się również nowy model cieniowania – Shader Model 4.0. Przede wszystkim jest on znacznie bardzie elastyczny niż zaimplementowany w bibliotekach DX 9.0. Shader Model 3.0. Programiści tworzący programy shaderowe mają w nim do dyspozycji znacznie więcej rejestrów – ich liczba wzrosła z 256 do 65536. Rejestry te zostały pogrupowane w bloki 16 buforów z 4096 rejestrami każdy. Wzrosła też liczba rejestrów tymczasowych – z 32 do 4096.
 
Kolejną modyfikacją wprowadzoną w modelu cieniowania SM 4.0 jest zwiększony rozmiar obsługiwanych tekstur. W DirectX 9.0c tekstury mogą mieć maksymalny rozmiar 4096×4096 pikseli, a w DX10 jest to 8192×8192 punktów. Jeśli chodzi o tekstury to, zwiększona została również liczba obiektów, które mogą być jednocześnie renderowane z wykorzystaniem techniki MRT (Multiple Render Targets), polegającej na nakładaniu tej samej bitmapy jednocześnie na wiele obiektów znajdujących się na scenie 3D. W DX 9.0 jedna tekstura mogła być nakładana jednocześnie na cztery obiekty, w DX 10 obiektów może być osiem. W DX 10 wprowadzono też tablice tekstur (texture arrays) mieszczące do 512 pojedynczych bitmap. Wprowadzono również dwa nowe formaty danych używanych podczas renderingu HDR (High Dynamic Range). Pierwszy z nich oznaczony symbolem R11G11B10 dostosowany jest do tekstur. W formacie tym barwa czerwona i zielona zapisane są z 11-bitową dokładnością. Kolor niebieską nadal opisany jest z 10-bitową dokładnością. Drugi format HDR jest nieco bardziej skomplikowany w opisie. Używa się tutaj bowiem używa cyfr o pięciobitowej dokładności, stanowiących wykładnik potęgi opisującej każdy kolor mantysą o dziewięciobitowej dokładności – uff, brzmi to nieco skomplikowanie :-). Niemniej, w rezultacie oba formaty pozwalają na lepsze „kolorowe” odwzorowanie obiektów podczas renderowania sceny z wykorzystaniem techniki HDR.

Przykład wykorzystania nowy formatów tekstur.
Źródło: ATI/AMD

Efekty, efekty, efekty
 
W bibliotekach DirectX 10 pojawiło się też kilka nowych efektów 3D. Oczywiście, porównywalne rezultaty osiągnie się też innymi metodami np. korzystając z Pixel i Vertex Shaderów, niemniej zaimplementowane w DX10 procedury dają oczekiwane rezultaty znacznie szybciej i prościej niż w wypadku korzystania z mechanizmów zawartych w starszych wersjach DX-ów. Lista dodanych efektów nie jest duża, omówmy je zatem w całości po kolei.
 
Przegląd nowych efektów zacznijmy od instancingu, który co prawda pojawił się już w bibliotekach DirectX 9, ale w DX10 został znacznie usprawniony. Instancing to nic innego, jak mechanizm pozwalający na rysowanie obiektów na scenie 3D w założonych przez programistę lub przypadkowych miejscach przy wykorzystaniu przygotowanych uprzednio obiektów, które mogą być zmniejszane, obracane, przechylane itp. Innymi słowy, wystarczy przygotować sobie np. (patrz: rysunek) jeden obiekt w postaci drzewa, po czym w buforze instancingu zawrzeć listę zadań do wykonania, które mają być zrealizowane podczas rysowania każdej kopii tegoż obiektu na scenie 3D.

Karta graficzna automatycznie, zgodnie z zawartymi w buforze instrukcjami np. wygina przygotowane przez nas drzewo, obróci je, zmniejszy, wydłuży, przeskaluje itp. dzięki czemu „za jednym zamachem” możemy rozmieścić na scenie 3D cały las, w którym każde drzewo będzie nieco inne. Co ważne, przy użyciu instancingu da się przesłać dane dotyczące drzewa w jednej paczce, za pomocą jednego wywołania CPU. Procesor graficzny rysuje sobie wówczas nasz przykładowy las składający się z kilku tysięcy drzew, sam bez pomocy CPU, który w tym czasie może zająć się innymi zadaniami. Znika tu zatem konieczność oczekiwanie przez procesor komputera na narysowanie każdego obiektu oraz za każdym razem pojedynczego ustawiania parametrów dotyczących rysowanego obiektu w karcie graficznej przez procesor. Jest to ogromny zysk. Usprawnienie technologii instancingu w DX10 polega na tym, że do automatycznego rysowania obiektów można teraz wykorzystywać różne tekstury.

Działanie instancingu. Źródło: Microsoft/Nvidia

Podobnie działa wprowadzony z DirectX 10 mechanizm proceduralnej symulacji wzrostu (Procedural Growth Simulation). Dzięki niemu można renderować rośliny należące do wodnych ekosystemów (niestety, wzrost roślin lądowych jest bardziej skomplikowany i jego symulacja wymaga interwencji CPU) oraz, co ważne, symulować ich wzrost i zachodzące w nich zmiany za pomocą dosłownie kilku instrukcji obsługiwanych przez DirectX 10 bez udziału jednostki centralnej komputera – symulacją zajmuje się jedynie GPU.

Proceduralna symulacja wzrostu. Źródło: Microsoft

Kolejnym efektem, który znalazł się w bibliotekach DirectX 10 jest punktowe mapowanie przemieszczeń (Per-pixel Displacement Mapping). Jest to modyfikacja znanego z DirectX 8 mapowania kierunkowego (Parallax Mapping). W pierwszym kroku obliczana jest mapa wysokości. Obrazuje ona wszystkie nierówności i chropowatość powierzchni obiektu. Mapę tą łączy się następnie z nakładaną na przedmiot teksturą. Punktowe mapowanie przemieszczeń różni się od tradycyjnego mapowania kierunkowego tym, że odwzorowuje nierówności wyłącznie w tych miejscach, które są widoczne dla obserwatora. W ten sposób końcowy efekt uzyskiwany jest znacznie szybciej, co nie znaczy, że starą techniką nie osiągniemy porównywalnych efektów końcowych.

Punktowe mapowanie przemieszczeń. Źródło: Microsoft

Ostatnim z wprowadzonych w DX10 efektów jest Alpha to Coverage. Metoda ta jest wykorzystywana do wygładzania krawędzi drobnych obiektów znajdujących się wewnątrz półprzezroczystych tekstur. Tego typu półprzezroczyste tekstury wykorzystuje się do rysowania siatek ogrodzeń, różnych wiszących oraz drobnych roślin, takich jak na przykład źdźbła trawy. Alpha to Coverage pozwala bardzo szybko wygładzić krawędzie wspomnianych obiektów bez angażowania dużej mocy obliczeniowej. Co ważne, wygładzanie obiektów znajdujących się wewnątrz tekstury wykonywane jest przed nałożeniem ich na scenę 3D. Dzięki temu, antyaliasingowane półprzezroczyste tekstury z małymi obiektami mogą być wielokrotnie nakładane na scenę lub, dzięki umieszczaniu ich w pamięci karty, użyte do mapowania kolejnych scen.

Przykład wykorzystania techniki Alpha to Coverage na krawędzi kory drzewa.
Źródło: Nvidia

Clou programu – zunifikowane shadery i shadery geometrii
 
Jedną z najważniejszych zmian wprowadzonych w bibliotekach graficznych DirectX 10 jest możliwość optymalnego wykorzystania architektury kart graficznych bazujących na zunifikowanych shaderach (Unified Shaders). Zunifikowane shadery mogą wykonywać, w zależności od potrzeb, zarówno operacje przetwarzania wielokątów, jak i pikseli, które realizowane do tej pory były przez jednostki Vertex i Pixel Shader. Innymi słowy operacje werteksowe i pikselowe w bibliotekach graficznych DirectX 10 połączono w jedną fazę przetwarzania sceny 3D. Nie znaczy to jednak, że programista pisząc grę czy inną aplikację „widzi” zunifikowane jednostki. Przy programowaniu korzysta on dalej z tradycyjnego modelu Vertex i Pixel Shaderów, zaś o wykonywaniu danej zunifikowanej jednostki do obróbki werteksów czy pikseli decyduje sterownik karty i mechanizmy przydziału zadań zawarte bezpośrednio w graficznym procesorze.

Idea wykorzystania zunifikowanych shaderów.
Źródło: Nvidia

W tym miejscu warto dodać, że nie każda karta graficzna zgodna z DX10 musi koniecznie korzystać ze zunifikowanej architektury shaderów. Bez problemu może ona być wykonana w tradycyjnej architekturze z oddzielnymi jednostkami Vertex i Pixel Shader. W takim wypadku za rozseparowanie ciągu operacji geometryczno-pikselowych odpowiadać sterownik urządzenia. Niestety wiąże się to z dodatkowym obciążeniem CPU, który też będzie musiał emulować operacje wykonywane na shaderach geometrii, o których za chwilę.
 
Architektura zunifikowanych shaderów zadebiutowała wraz z GeForce’m 8800. Owa architektura to nic innego jak architektura i jednocześnie technologia CUDA (Compute Unified Device Architecture), w której to wykorzystuje się znajdujące się w GPU specjalne jednostki obliczeniowe Jeśli chodzi o karty AMD/ATI to podobne rozwiązanie o nazwie Unified Shaders znalazło się po raz pierwszy w Radeonie HD 2900 XT. W sumie, zdecydowana większość współczesnych kart graficznych, nawet tych zgodnych tylko z bibliotekami graficznymi DirectX 9.0 korzysta z technologii zunifikowanych shaderów. Można powiedzieć, że DirectX 10 usankcjonował tylko to rozwiązanie technologiczne.
 
Jednak DX 10 to nie tylko zunifikowane shadery zastępujące we wnętrzu układu graficznego Vertex i Pixel Shadery. Jak się okazuje biblioteki DirectX 10 wymagają jeszcze bowiem dodatkowych jednostek cieniowania, zaimplementowanych w GPU. Zgodnie ze specyfikacją nowego DX-a, w potoku graficznym między Vertex a Pixel Shaderem musi się znaleźć moduł obliczeń geometrycznych – Geometry Shader. Ta nowa jednostka obliczeniowa odpowiada m.in. za łączenie wierzchołków, a także może scalać szereg tworzących scenę 3D trójkątów w pasy (lub bardziej skomplikowane struktury), a następnie przeprowadzać obliczenia fizyczne związane z ich ruchem. Takie połączone ze sobą paski mogą zostać np. wykorzystane do odtworzenia falowania trawy, zachowania się włosów, tkanin, powiewania flag na wietrze, układania się dymu itp. Shadery geometryczne odpowiadają też, że generowanie tzw. cieni szablonowych (Stencil Shadow). Wszystkie wymienione powyżej operacje wykonywane były dotąd, czyli np. w wypadku kart zgodnych z DX 9.0c na CPU. Dzięki Geometry Shaderom znacznie łatwiejsze (i szybsze) stało się odwzorowanie przemieszczeń (Displacement Mapping), wytłaczanie cieni szablonowych (Stencil Shadow Extrusion) czy tworzenie obiektów „duszków” (point-sprite).

Potok graficzny w DirectX 10. Źródło: Nvidia

Oczywiście, symulacja Geometry Shadera przez sterowniki i procesor komputera jest jak najbardziej możliwa – w zasadzie operacje geometryczne w bibliotekach DirectX 9 w ten sposób są cały czas realizowane, ale przy bardziej skomplikowanych grach czy programach pisanych już pod DX10, emulując operacje geometryczne na procesorze może się bardzo szybko okazać, że zabraknie nam po prostu mocy obliczeniowej CPU do wykonywania innych zadań.
 
Inżynierowie zajmujący się kartami graficznymi i twórcy bibliotek DirectX 10, podkreślają dwie zalety połączenia w jedną fazę obliczeniową wszystkich kalkulacji geometrycznych i operacji prowadzonych na pikselach (patrz: powyższe schematy). Okazuje się bowiem, że w dotychczasowym modelu generowania sceny 3D bardzo często wszystkie jednostki Vertex Shader były zajęte obliczeniami, a Pixel Shadery bezczynnie przez kilkanaście cykli zegarowych oczekiwały na potrzebne dane geometryczne. Zdarzają się też sytuacje odwrotne, gdzie na informacje czekają jednostki werteksowe. W zunifikowanej architekturze shaderów, teoretycznie nie powinno być tego typu przestojów, gdyż każda jednostka w GPU w zależności od potrzeb może zająć się jednym lub drugim typem obliczeń. Dzięki temu w prosty sposób zwiększa się nie tylko sumaryczna wydajność całego procesora graficznego, ale również drastycznie maleje liczba pustych przebiegów.
 
Drugą przyczyną wprowadzenia, i usystematyzowania zunifikowanej architektury shaderów jest możliwość wykorzystania niezależnie programowanych i uniwersalnych jednostek do zaawansowanych obliczeń w ogóle nie związanych z grafiką – patrz: artykuł o technologii CUDA (http://www.frazpc.pl/artykuly/704/Technologia/Obliczenia/prowadzone/za/pomoca/kart/graficznych).

Przykład wykorzystania zunifikowanych shaderów do obliczenia fizyki zachowania się wody (u góry) i dymu (u dołu).
Źródło: Nvidia

Czas DirectX-a 10.1
 
Po tym obszernym omówieniu bibliotek DirectX 10, przejdźmy teraz do przedstawienia ich nowszej wersji. Pojawiła się ona na rynku wraz z Service Packiem 1 do systemu Windows Vista. Uprzedzając pytania, DirectX 9.0L nie uległ przy tym żadnym modyfikacjom. Pierwszymi kartami graficznymi zgodnymi stały się DX 10.1 akceleratory 3D firmy ATI/AMD z serii Radeon 3800 HD. Nvidia bardzo długo „broniła się” przed nowym standardem, dopiero, jak wspomniałem na początku nowe graficzne układy mobilne GTS 260M, GTS 250M, GT 240M, GT 230M oraz G210M są z nimi kompatybilne. Kolejne, nowe rodziny układów zarówno Nvidii, jaki i ATI/AMD, jak też kości Larrabee Intela mają być już zgodne wyłącznie z nowym API – DirectX 11, który, wszystko już na to wskazuje, zadebiutuje tegoroczną jesienią.
 
Wróćmy jednak do obowiązującego obecnie standardu DX 10.1. Patrząc na dokumentację, wyraźnie widać, że wprowadzone zmiany miały uściślić precyzję realizowanych przez API funkcji i obliczeń, udoskonalić operacje cieniowania i nakładania tekstur oraz usprawnić procedury antyaliasingu. Co ważne, w nowej rewizja bibliotek graficznych DX 10.1 określono sporą listę funkcji, które w DX 10 karty graficzne mogły dotąd obsługiwać opcjonalnie, a teraz muszą być one zaimplementowane obowiązkowo.
 
Precyzja obliczeniowa
 
Najważniejszą zmiana dotyczącą precyzji wykonywanych przez kartę graficzną obliczeń podczas generowania sceny 3D, jest to wprowadzenie zmiennoprzecinkowego filtrowania 128-bitowych tekstur przy wykorzystaniu 32-bitowej dokładności. W DX 10 stosowana jest precyzja 16-bitowa. Kolejnym zwiększeniem dokładności jest wprowadzenie 16-bitowej precyzji przy określaniu przezroczystości pikseli opisanych 64-bitowymi liczbami całkowitymi. Taka dokładność, w bibliotekach DX 10 była właściwością tylko opcjonalną.
 
Ważnym zwiększeniem precyzji obliczeń realizowanych przez karty graficzne zgodne z DX 10.1 jest zwiększenie we wszystkich operacjach zmiennoprzecinkowych takich jak dodawanie, odejmowanie, mnożenie i dzielenie dokładności zaokrągleń ostatniego miejsca po przecinku o pół wartości w górę. Są to operacje 0.5 ULP (Unit in the Last Place), których wymaga uzyskanie zgodności z normami IEEE dotyczącymi dokładności obliczeń numerycznych realizowanych na procesorach obliczeniowych. Zgodność tą wprowadzono ze względu na coraz częstsze stosowanie kart graficznych w obliczeniach nie związanych z grafiką.
 
Z precyzją obliczeniową związane są też nowe algorytmy wygładzania krawędzi. Karty graficzne zgodne z DX 10.1 musza obowiązkowo obsługiwać antyaliasing wykonywany metodą multipróbkowania MSAA (Multi-Sample Anti-Aliasing) pobierając przynajmniej cztery próbki wartości sąsiednich pikseli przypadające na jeden wygładzany punkt obrazu. Obliczenia te muszą być prowadzone niezależnie, czy piksele są zapisane z 32-, czy z 64-bitową precyzją. Zestandaryzowane zostały też szablony służące do próbkowania punktów wykorzystywanych przy pełnoekranowym antyaliasingu (FSAA – Full Scene Anty-Aliasing). Szablony te obowiązują w trybach FSAA 2x, 4x, 8x i 16x. Dzięki temu wygładzanie powinno wyglądać teraz tak samo niezależnie od modelu z DX 10.1 realizującego je układu graficznego.

Zwiększona dokładność antyaliasingu. Źródło: ATI/AMD

W tym miejscu trzeba też wspomnieć o tym, że w bibliotekach graficznych DirectX 10.1 wprowadzono trzy nowe funkcjonalności związane z atyaliasingiem. Pierwszą z nich jest bufor zapisu/odczytu danych przy wygładzaniu krawędzi wykorzystującego multipróbkowanie. Pozwala on na przechowywanie indywidualnych wartości odczytanych dla każdego punktu. W kartach graficznych zgodnych z DX 10 przechowywana była jedna wartość średnia otrzymana dla wszystkich próbkowanych pikseli. Drugą jest funkcją Pixel Coverage Masks. Ma ona za zadanie pomóc programiście w stworzeniu własnych metod antyaliasingu, które będą realizowane przez Pixel Shadery. Podobną funkcje mają do spełnienia szablony używane przy antyaliasingu, które programista sam może w dowolny sposób stworzyć i modyfikować. Funkcja ta nazywa się Programmable Anti-Aliasing Sample Patern. Dzięki niej osoba programująca shadery uzyskuje całkowitą kontrolę nad próbkowaniem punktów wykorzystywanych do wygładzania krawędzi.
 
Shader Model 4.1
 
Jak można się domyślić, w DirectX 10.1 pojawił się też nowy model cieniowania – Shader Model 4.1. Spośród wprowadzonych w SM 4.1 funkcji wymienić należy przede wszystkim Cube Map Arrays (macierz map kubicznych), która pozwala nanieść w jednym przejściu wiele kubicznych map. Mapy kubiczne to nic innego, jak specjalne przygotowywane w trakcie generowania obrazu 3D tekstury powstające z połączenia pierwotnie nakładanej na obiekt tekstury z mapami środowiska (np. odbiciami światła od przedmiotów). Nowa realizowana sprzętowo funkcja ma, oczywiście za zadanie przyspieszyć generowanie sceny 3D.
 
Funkcja przyspieszającą generowanie grafiki jest też możliwość określanie przezroczystości punktów w trybie MRT (Multiple Render Target) osobno dla każdego obiektu na scenie 3D, dla którego nakładana jest ta sama tekstura. Przy jej wykorzystaniu nie trzeba zmieniać przezroczystości w kilku krokach już po nałożeniu tekstur na obiekty na scenie 3D, po prostu tekstury o już odpowiednio ustalonej przezroczystości od razu nakładane są na obiekty w jednym przebiegu procesu renderingu.
 
Jedną z najważniejszych zdaniem Microsoftu wprowadzonych cech w SM 4.1 jest funkcja obliczeniowa Gather4. Pozwala ona na wprowadzenie niefiltrowanych bloków tekstur o wymiarach 2×2 teksele (teksel to punkt tekstury) do obliczeń filtrowania dwuliniowego. Co więcej obliczenia te dokonywane są z wyprzedzeniem na podstawie zaimplementowanych algorytmów przewidujących operacje w potoku graficznym. Na poprawę szybkości wykonywania programów shaderowych wpływają też ulepszone algorytmy wprowadzania danych wejściowych i odbierania danych wyjściowych do/z Vertex Shadera. Wedle zapewnień, mają one dwukrotnie przyspieszać szybkość przepływu informacji 16, 32 i 128 bitowych danych. Ostatnią modyfikacją wprowadzoną do SM 4.1 jest dodanie instrukcji LOD (Level Of Detail). Pozwala ona programiście określić szczegółowość filtrowania tekstur. Dzięki łatwiej bilansować realistyczność odwzorowania obiektów względem wymaganej szybkości generowania sceny.

Przykładowa demonstracja firmy ATI/AMD dotycząca wykorzystania modelu cieniowania SM 4.1 do uzyskania efektu globalnego oświetlenia.
Źródło: ATI/AMD

Oprócz wspomnianego wcześniej zwiększenia precyzji i powtarzalności obliczeń związanych z antyaliasingiem, w bibliotekach DirectX 10.1 wprowadzono trzy nowe cechy funkcjonalne związane z poprawą wygładzania krawędzi. Pierwsza z nich to wprowadzenie obsługi bufora zapisu/odczytu danych przy wygładzaniu krawędzi wykorzystującego multipróbkowanie. Bufor ten pozwala na przechowywanie indywidualnych wartości odczytanych dla każdego punktu (a nie jak dotychczas jednej wartości średniej dla wszystkich próbkowanych pikseli) i pozwala na bezpośredni dostęp do tych danych programom shaderowym (wykonywanym przez Pixel Shader).
 
Ciekawą funkcją jest Pixel Coverage Masks, która za zadanie pomóc programiście w stworzeniu własnych metod antyaliasingu, które będą realizowane przez Pixel Shadery. Podobną funkcje mają do spełnienia szablony używane przy antyaliasingu, które programista sam może w dowolny sposób stworzyć i modyfikować (Programmable Anti-Aliasing Sample Patern), Dzięki temu uzyskuje on całkowitą kontrolę nad próbkowaniem punktów wykorzystywanych do wygładzania krawędzi.
 
Czekając na DirectX 11
 
Jak widać, wprowadzone w DX 10.1 nie wyróżniają się niczym szczególnym. Co prawda usprawniają one obliczenia wykonywane przez kartę podczas generowania sceny 3D, ale nie wniosły jakiś szczególnie istotnej nowej funkcjonalności. Duże zmiany Czekaja nas dopiero w przygotowywanych właśnie bibliotekach DirectX 11, które mogą wywołać znacznie większą rewolucję w procesie tworzenia trójwymiarowej grafiki, niż pojawienie się bibliotek DirectX 10, które do dziś przez wielu programistów są traktowane z pewna rezerwą i wola oni wciąż korzystać z wersji 9.0c.

Porównanie możliwości DirectX 10 i DirectX 11. Źródło: Microsoft

Gra Assassin’s Creed w wersji dla DX10 (u góry) i DX 11 (na dole)

Jak już wspominałem na początku artykułu, biblioteki DirectX 11 znajdą się w finalnej wersji systemu Windows 7, ale, na szczęście, będą również dostępne dla Windows Vista. Co więcej, zarówno programiści, twórcy gier komputerowych, jak i producenci sprzętu już od kilku miesięcy mogli skorzystać z odpowiedniego pakietu deweloperskiego SDK (http://www.microsoft.com/downloads/details.aspx?FamilyId=5493F76A-6D37-478D-BA17-28B1CCA4865A&displaylang=en).

DirectX 11 dostępne są już w pakiecie SDK dla developerów.
Źródło: Microsoft

Jak zapowiada firma ATI/AMD już w listopadzie powinny pojawić się na rynku pierwsze akceleratory 3D zgodne z nowym API. Przedstawiciele tej firmy twierdzą, że pod tym względem wyprzedzą Nvidię, która swoje produkty zgodne z DX 11 pokaże na rynku znacznie później – cóż, pożyjemy, zobaczymy.
 
Nacisk na teselację
 
W czerwcu firma ATI/AMD przedstawiła szereg dokumentów dotyczących nowych bibliotek graficznych Microsoftu. Podczas tej, odbywającej się na targach Computex 2009 konferencji zaprezentowano też pierwsze wafle krzemowe z nowymi układami zgodnymi z DX 11. zaprezentowano też algorytmy teselacji na działającej karcie graficznej zgodnej z DirectX 11, na którą to funkcję największy nacisk położyli właśnie przedstawiciele ATI/AMD – i nie ma co się im dziwić. Sprzętowy teselator i związana z nim technologia TruForm pojawiła się w kartach ATI/AMD w 2002 roku, a konkretnie w Radeonie 8500. Niestety, przez długi czas nie zyskała ona większego uznania. Do najbardziej znanych, pierwszych gier korzystających z technologii TruForm należy „Return to Castle Wolfenstein” (od wersji z patchem 1.33).

Return to Castel Wolfenstain – jedna z pierwszych gier wykorzystujących teselację.

Teselacja to etap, który w potoku graficznym 3D związany z dzieleniem wygenerowanych podczas tworzenia wirtualnej sceny 3D wielokątów na mniejsze fragmenty – nie był on do tej pory obowiązkowy. Dzięki teselacji generowany wyświetlany na ekranie obiekt może być automatycznie, bez dużego udziału programisty, znacznie bardziej precyzyjnie narysowany. Programista wskazuje jedynie bryły lub ich fragmenty, które mają być dokładniej podzielone, a za pozostałe działania odpowiadają już sterowniki i karta graficzna. Wskazany obszar, fragment bryły, lub wielokąt jest następnie dzielony przez teselator na kilkanaście mniejszych trójkątów. Co więcej, na podstawie dodatkowych informacji o położeniu obrabianego trójkąta względem innych należących do tego obiektu, np. do kuli, wielokątów, ustala się współrzędne wierzchołków mniejszych trójkątów. Chodzi o to, aby wystawały one nad powierzchnię dzielonego trójkąta tak, aby był on bardziej gładki i obły, dzięki czemu mapowane tekstury znacznie lepiej oddadzą jego kształt. Przy automatycznej teselacji z uzyskanymi dodatkowo trójkątami nie są powiązane żadne dane w pamięci karty. To sprawia, że, ilość przesyłanych między pamięcią karty i układem 3D danych nie zwiększa się i nie obciąża dodatkowo magistrali danych i pamięci. Okazuje się też, że niektóre animacje, np. falowanie wody czy mięcie tkaniny, mogą być tworzone wyłącznie na podstawie bazowej siatki składającej się ze stosunkowo niewielkiej liczby wielokątów.

TruForm – Teselacja realizowana na kartach ATI. Źródło: ATI/AMD

Hull i domain shader
 
Analizując dokumenty Microsoftu i prezentacje firmy ATI/AMD widać wyraźnie, że bardzo istotnymi zmianami w DirectX 11 jest wprowadzenie kolejnych modyfikacji do modelu cieniowania realizowanego przez kartę graficzną i jednocześnie do potoku renderingu. Są to sprzętowo realizowane etapy: hull oraz domain shader nazywane również czasem po polsku odpowiednio shaderem powłoki i shaderem dziedziny. Uwaga, poniżej trudny fragment :-).
 
Hull Shader przekształca wszystkie dane wejściowe w taki sposób, że są one traktowane podczas numerycznych obliczeń jako siatka (macierz) powiązanych ze sobą danych wejściowych o różnych częstotliwościach – jest to tak zwana siatka typu control mesh frequency. Taka matematyczna transformata zmienia jedną reprezentację (czyli jej matematyczny opis – np. do opisania położenia w przestrzeni 3D punktu potrzebne są jego trzy współrzędne X,Y,Z lub np. promień i kat wektora wodzącego (r,f) – to jest inna reprezentacja tegoż punktu) powierzchni na drugą. W grafice 3D stosuje się zamianę powierzchni opisanej czterowymiarową siatką punktów Catmulla-Clarka na powierzchnię, a raczej jej reprezentację opisaną powierzchniami Bziera (tzw. Bezier patch). W taki sposób operacje dotyczące zamiany matematycznej reprezentacji wykonywał dotychczas na potrzeby generowania grafiki 3D między innymi program Blender. Transformata z normalnej przestrzeni na przestrzeń opisana powierzchniami Beziera pozwala w znacznie bardziej naturalny (realistyczny) sposób przedstawić przedmioty o gładkich zaoblonych kształtach. Takie powierzchnie nazywa się w literaturze związanej z generowaniem obrazów 3D powierzchniami naturalnie gładkie.

Potok renderingu w DirectX 11. Źródło: Microsoft

Nieco inne zadanie ma domain shader. Ten shader używany jest praktycznie tylko raz dla każdego wierzchołka na generowanej scenie 3D. Domain shader ustala dziedzinę argumentów wejściowych (tzw. domenę) dla obliczeń wszystkich powierzchni parametrycznych wykorzystywanych na danej trójwymiarowej scenie. Mówiąc prościej, odpowiada on za to, że każdy obiekt na scenie 3D zostaje wygenerowany tylko raz, a wszelkie związane z nim zmiany – np. zgniecenie błotnika wirtualnego samochodu, są tylko uaktualnieniami fragmentów jego bryły, a nie efektem wygenerowania całego obiektu od nowa.

Zmiany w DirectX 11. Źródło: Microsoft

Shader Model 5.0
 
DirectX 11 nie byłby kolejną wersją bibliotek graficznych gdyby nie wprowadzono w nim, kolejnego tym razem już piątego modelu cieniowania. Shader Model 5.0 został zaprojektowany tak by jeszcze bardziej niż SM 4.1 ułatwić pracę programistom. Najważniejszą jego cechą jest wykorzystanie obiektowego modelu programowania, wzorowanego na C++. SM 5.0 pozwala też na wykonywanie obliczeń podwójnej precyzji, co w efekcie zwiększa dokładność renderingu. Pozostałe nowe funkcje SM 5.0 dotyczą przede wszystkim wymiany danych między poszczególnymi przetwarzanymi przez układ wątkami.
 
Istotną nowością w Shader Model 5.0 jest również zestaw instrukcji odpowiedzialnych za sterowanie strumieniowymi operacjami wejścia-wyjścia. Funkcje te w systemie Windows 7 wykorzystano przede wszystkim do zarządzania multimediami. W Windows 7 pojawi się multimedialny mechanizm drag&drop, który pozwoli na to, że po podłączeniu do komputera przenośnego urządzenia takiego jak odtwarzacz MP4, konsola PSP, czy telefonu komorkowego i wybraniu w eksploratorze Windows znajdującego się na dysku komputera materiału wideo i przeciągnięciu go do mobilnego urządzenia spowoduje, ze automatycznie rozpocznie się proces transkodowania filmu na odpowiedni dla mobilnego sprzętu format danych wideo. Transkodowanie to wykorzystuje procesor graficzny i strumieniowe operacje wejścia-wyjścia zaszyte w SM 5.0.

Transkodowanie materiałów wideo z pomocą DirectX 11
Źródło: ATI/AMD

Kompresja tekstur
 
W DirectX 11 pojawią się też dwa nowe formaty kompresji tekstur. Są to formaty BC6 oraz BC7. Pierwszy stworzono w celu znaczącej poprawy jakość wyświetlanego obrazu HDR (High Dynamic Range) bez zauważalnego spadku szybkości generowania obrazu 3D. Z kolei format BC7 powstał do obsługi 8-bitowych tekstur LDR (Low Dynamic Range) przy zachowaniu ich wysokiej jakości. Format ten kompresuje teksturu w proporcji 3:1, a BC6 pozwala na skompresowanie tekstur w stosunku 6:1.

Nowe formaty tekstur obsługiwane przez DX 11.
Źródło: Microsoft

Shadery obliczeniowe
 
Moim zdaniem najważniejszą, rewolucyjną zmianą, której konsekwencji nie jesteśmy jeszcze w tej chwili sobie nawet do końca sobie obecnie uświadomić jest wprowadzenie w DirectX 11 shaderów obliczeniowych (Compute Shader). Element ten nie jest jednak bezpośrednio wykorzystywany podczas generowania obrazu, dlatego dość często jest w wielu opracowaniach pomijany. Compute Shader jest bowiem elementem pozwalającym na prowadzenie na karcie obliczeń nie związanych w ogóle z generowaniem grafiki – jest to rozwinięcie opisanej wcześniej przy opisie DX 10 architektury zunifikowanych. Powiem więcej, tak naprawdę jest to wprowadzona do DirectX implementacja obliczeniowych technologii Nvidia CUDA i AMD Stream! (patrz: http://www.frazpc.pl/artykuly/704/Technologia/Obliczenia/prowadzone/za/pomoca/kart/graficznych). Lub jeszcze inaczej Microsoftowi odpowiednik bibliotek OpenCL – podobnie jak DirectX jest odpowiednikiem OpenGL-a.

No dobrze, ale co w nim tak naprawdę takiego rewolucyjnego. Otóż podstawową zaletą modelu Compute Shader jest to, że o ile technologie CUDA i AMD Stream nie są ze sobą kompatybilne, o tyle Compute Shader będzie, podobnie jak OpenCL, wspólny dla wszystkich platform sprzętowych wykorzystujących do obliczeń karty graficzne. Konsekwencje tego faktu naprawdę trudno w tej chwili przecenić. Do tej pory główną barierą rozwoju oprogramowania zgodnego z CUDA i AMD Stream było to, że były to technologie przeznaczone do obsługi sprzętu wyłącznie jednego producenta, teraz gdy karty graficzne chcąc uzyskać zgodność z DX 11 będą musiały być też zgodne z Compute Shader, co sprawi, że obliczenia nie związane z grafiką wykonywane na kartach graficznych zagoszczą na dobre w naszych pecetach przyczyniając się do znacznego przyrostu możliwej do wykorzystania mocy obliczeniowej.

Wykorzystanie Compute Shadera do obliczeń związanych z fizyką. Na rysunku będącym fragmentem większej animacji, dzięki szaderom obliczeniowym niemu uzyskano realistyczny efekt falowania wody.
Źródło: Nvidia

Jak można wyczytać w dostępnej dokumentacji Microsoftu, shader obliczeniowy będzie przede wszystkim odpowiedzialny za szeroko pojęte obliczenia związane z fizyką w grach. Z jego pomocą obliczane mają być takie zjawiska fizyczne jak: interakcja przedmiotów, trajektoria ruchu, eksplozje, zachowanie się dymu (efekty cząsteczkowe), falowanie i przepływ cieczy, zachowanie się tkanin i ubrań, fizyka ciał miękkich itp. Mało tego, planuje się też, że DX 11 będzie wspomagał algorytmy sztucznej inteligencji (AI) w grach, co pozwoli na bardziej realne zachowanie się postaci, którymi steruje komputer. Oczywiście, shader obliczeniowy będzie mógł również zostać wykorzystany w programy inżyniersko-naukowych, tak jak ma to obecnie miejsce w wypadku CUDA i AMD Stream.
 
Pojawienie się Compute Shadera w DX 11 może moim zdaniem mieć jeszcze jedną poważną konsekwencję, tym razem dla firmy Nvidia. Zintegrowany z DirectX shader obliczeniowy pozwoli twórcom gier na przeniesienie znacznej części obliczeń z procesora na kartę graficzną, a jednocześnie kalkulacje te nie będą już więcej ograniczone do sprzętu tylko jednego producenta. Promowana przez Nvidię technologia CUDA, chodząca jedynie na kartach Nvidii, zaczyna więc dla twórców oprogramowania tracić powoli rację bytu. Mało tego, wkrótce pojawi się również nowa wersja silnika efektów fizycznych – Havok. Ten tworzony jest z kolei z myślą o również uniwersalnym środowisku OpenCL, co stawia pod dużym znakiem zapytania dalszą egzystencję promowanej przez Nvidię technologii PhysX. Należy zatem zastanowić się, który z twórców gier będzie chciał korzystać z rozwiązania technicznego przeznaczonego tylko dla sprzętu jednego producenta? DirectX 11 i nowy Havok mogą więc wpędzić Nvidię, jeśli nie zmieni ona swojej polityki dotyczącej systemów CUDA/PhysX, w poważne kłopoty i zepchnąć do defensywy – czy tak będzie, wkrótce się o tym przekonamy.
 
Wróżenie z fusów, czyli co nas czeka w przyszłości
 
Jak widać, biblioteki DirectX 10 i DirectX 11 konsekwentnie przenoszą coraz większą cześć obliczeń z procesora do karty graficznej. Windows 7 ma być też pierwszym systemem operacyjnym integrującym i w sposób płynny wykorzystującym moc obliczeniową procesora i procesora graficznego. Programistom Microsoftu tworzącym biblioteki DirectX 11 przyświecała bowiem chęć, dostarczenia wraz z Windows 7 wygodnego środowiska umożliwiającego jednolite wykorzystanie właściwości całego dostępnego w systemie komputerowym sprzętu w taki sposób, aby jak optymalnie wykorzystać ich potencjał obliczeniowy. DirectX 11 ma zapewnić przede wszystkim obsługę sprzętu przez system operacyjny na znacznie niższym poziomie i w znacznym stopniu udoskonalić sposoby przetwarzania wielowątkowego. Co ważne już wkrótce pojawią się pierwsze karty graficzne zgodne z DX 11.

Zapowiedź pierwszych układów graficznych zgodnych z DirectX 11.
Źródło: ATI/AMD

Pierwszy krok został zrobiony – model cieniowania Shader Model 5.0 w znacznym stopniu wykorzystuje już programowanie obiektowe i obliczeniowe jednostki karty graficznej do kalkulacji nie związanych z grafiką. Windows 7 ma maksymalnie korzystać z ujednoliconego środowiska GPU + CPU. Co więcej, jego następca będzie traktował wszystkie dostępne w pececie układy obliczeniowe (a więc np. procesor dźwiękowy, czy np. dodatkową kartę obliczeniową) w ten sam jednolity sposób. Za kilka lat programista pisząc grę nie będzie się przejmował na czym będzie się ona wykonywać, czy uruchomiona zostanie na CPU czy GPU.

Przykładowa scena otrzymana przy wykorzystaniu DirectX 11.
Źródło: Microsoft

Jednolity model programowania i środowisko programistyczne sprawią, że osoba pisząca aplikację wykorzystując procedury zawarte w przyszłym API (jak wynika z bardzo nieoficjalnych zapowiedzi Microsoftu może już chodzić nawet o DirectX 12) będzie mogła stworzyć uniwersalny program, w którym przydziałem dostępnej mocy obliczeniowej będzie się zajmował wyłącznie system operacyjny. Sprzęt stanie się dla programistów całkowicie „przezroczysty”. Czy tak się stanie, trudno w tej chwili ocenić. Dysponujemy w tej chwili zbyt mała ilością informacji, przez to przewidywanie przyszłych posunięć Microsoftu dotyczących możliwych scenariuszy w rozwoju API, w tym DirectX-a oraz rozwoju systemów operacyjnych staje się raczej zajęciem dla futurologów i przysłowiowym wróżeniem z fusów.

Autor: Marcin Bieńkowski

Komentarze (139)

___________________________
Więcej artykułów