DirectX 10, DirectX 10.1 i DirectX 11 - Biblioteki graficzne

Redakcja, 2009-07-17 00:00 |

Czas 32 nanometrów

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 8.1 (Shader Model 1.1)

DirectX 9.0 (Shader Model 2.0)

DirectX 9.0c (Shader Model 3.0)

DirectX 10 (Shader Model 4.0)

Instrukcje werteksowe

128

256

512

64 000

Instrukcje pikselowe

4+8

32+64

512

Stałe rejestry werteksowe

96

256

256

16×4096

Stałe rejestry pikselowe

8

32

224

Tymczasowe rejestry werteksowe

16

16

16

4096

Tymczasowe rejestry pikselowe

2

12

32

Werteksowe dane wejściowe

16

16

16

16

Pikselowe dane wejściowe

4+2

8+2

10

32

Liczba jednocześnie renderowanych obiektów

1

4

4

8

Liczba jednocześnie pobieranych tekstur przez moduł Vertex Shader (uwaga: tekstury są pobierane z pamięci przez moduł Vertex)

niedostępne

niedostępne

4

128

Liczba jednocześnie przetwarzanych tekstur przez moduł Pixel Shader

8

16

16

Rozmiar tekstur 2D

2000×2000 pikseli

8000×8000 pikseli

Operacje wewnętrzne

tak

Pętle wewnętrzne

tak

Obliczanie pochodnych

tak

tak

Kontrola przepływu operacji werteksowych

niedostępna

statyczna

statyczna lub dynamiczna

dynamiczna

Kontrola przepływu operacji pikselowych

niedostępna

niedostępna

statyczna lub dynamiczna

dynamiczna

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

Tagi: Technologia,

Komentarze (139)

Skocz do ostatniej odpowiedzi | Pierwszy post na stronie

17.07.2009 00:05

Wątków: 413 | Odpowiedzi: 31305

SUPER!

coś do poczytania na długie zimowe wieczory... eee...ale przecie mamy pełnie lata!

Górski włóczykij

17.07.2009 00:37

Wątków: 737 | Odpowiedzi: 41186

xx

pierwszy od dluuugiego czasu art na fpc, ktory przeczytalem w calosci - a nie jak zwykle tylko rzucilem okiem na zdjecia i tabelki.
Very ciekawy - dzieki

Rzadko inteligencja idzie w parze z urodą ale u mnie tak się jakoś złożylo

17.07.2009 00:44

Wątków: 498 | Odpowiedzi: 8013

nie zmienia to faktu

że wg tego co piszesz każda karta dx 10 jest też kompatybilna z 10.1

całe życie człowiek uczy się na błędach, swoich, powielając błędy innych.

17.07.2009 00:47

Wątków: 737 | Odpowiedzi: 41186

Spuki

ja jakos inaczej zrozumialem... 10.1 w glownej mierze wprowadza jako wymagane to co bylo w 10 do tej pory opcjonalne.
Karty zgodne z DX 10 mogly operowac na prezycji wymaganej w DX 10.1 ale nie musialy - i wciaz byly w granicach standardu 10. A 10.1 to ujednolica - teraz trzeba dzialac na wiekszej precyzji.

Rzadko inteligencja idzie w parze z urodą ale u mnie tak się jakoś złożylo

17.07.2009 02:54

Wątków: 1 | Odpowiedzi: 85

...

Łał, super artykuł, trzeba go będzie jutro dokładniej przeczytać, ale już widzę, że korektor się nie popisał, np. Castel Wolfenstain i parę innych drobiazgów.

17.07.2009 07:43

Wątków: 590 | Odpowiedzi: 5604

...

No akurat wszystko się dobrze składa bo na przełomie roku chcę kupić desktopa Czyli będzie i winda7 i nowe karty z dx11, no i części tańsze

http://www.ciekawenoclegi.pl - Baza noclegów w Polsce, kwatery, hotele, pensjonaty, apartamenty, agroturystyka, od Bałtyku po Tatry! - Ciekawe Noclegi

  • Sprawdź bezpośredni link do posta

17.07.2009 07:55

Wątków: 316 | Odpowiedzi: 25516

...

fajny przekrojowy artykuł. z jednej strony jakby brakuje rozwinięcia niektórych tematów, z drugiej pewnie bym ich nie zrozumiał

  • Sprawdź bezpośredni link do posta

17.07.2009 10:42

Wątków: 1341 | Odpowiedzi: 41670

Z jednej strony

wszystko fajnie, ale z drugiej strony skoro DX10 jest tak dobry, to czemu jest tak zły?
Rozumiem, nowy system, niedopracowane stary itp. Ale minęło już sporo czasu a nadal wydajność w grach w DX10 jest tragiczna. Czyżby jeszcze absolutnie NIKT nie wykorzystał DX10 tak jak powinien?
Chyba raczej model sterowników w Vista dorzuca ogromny hamulec ręczny i mimo zalet przyspieszających wyświetlanie grafiki w DX10 i tak ogólnie jest gorzej...
No ale ja tylko strzelam. Nie jestem programistą silników graficznych.

Jeśli połamałeś sobie oczy na tekście posta wyżej, to przepraszam - czasem piszę skrajnie wyczerpany/niewyspany (lub nietrzeźwy,ale to rzadziej), poprawiam na szybko i "shit happens"

  • Sprawdź bezpośredni link do posta

17.07.2009 10:55

Wątków: 316 | Odpowiedzi: 25516

Ronson

przecież to właśnie napisał - DX10 do DX9+, korzyści niewiele a zawężenie grupy odbiorców spore (ludzie lubią XP). więc po co się starać skoro DX10 nic nowego tak serio nie wniosło? w ogóle się nie dziwię że go nie wykorzystują a ew. zyski z wydajności zostały pożarte przez większe teksturki itd.

17.07.2009 11:12

Wątków: 0 | Odpowiedzi: 37

Wszystkiemu winne sa konsole

ktore wyznaczaja tak naprawde ogranicznia w grach, a niestety technologicznie sa na poziomie dx9. Co do wydajnosci DX10 to fakt ze jest ona dosc kiepska, ale autor artykulu nie nadmienil ze glownym atutem DX10.1 jest jego predkosc. Jest on od 15% do 30% szybszy od poprzednika.

17.07.2009 11:33

Wątków: 6 | Odpowiedzi: 3391

cos

zjadlo "jest to rozwinięcie opisanej wcześniej przy opisie DX 10 architektury zunifikowanych." Ale ogolnie swietnie.

17.07.2009 11:58

Wątków: 4 | Odpowiedzi: 35

DirectX10/Windows ME/Vista

Dla mnie sprawa z DX10 wygląda analogicznie do wpadek MS pt. Windows ME oraz Windows Vista. Czyli miało być super, a wyszła lipa, która okazała się, jak ja to nazywam "przejściówką", formą pośrednią pomiędzy poprzednią popularną platformą (DX9, Win98, WinXP), a nową, NAPRAWDĘ lepszą platformą (DX11, WinXP, Win7). To jest tak symptomatyczne działanie w Microsofcie, że często zastanawiam się, czy aby nie celowe?

"Twice the pride - double the fall" - Count Dooku

17.07.2009 12:45

Wątków: 140 | Odpowiedzi: 826

,....


Plik graficzny pochodzi stąd



to musi być fake

17.07.2009 12:59

Wątków: 0 | Odpowiedzi: 68

xxx

Wyszło kilka gier w których implementacja dx10 przebiegła tak jak należy, chociażby farcry 2 czy devil Mc4. Olbrzymi skok wydajności po ustawieniu na dx10

17.07.2009 13:22

Wątków: 92 | Odpowiedzi: 6565

bardzo porządny artykuł

nie przeładowany jakimiś nic nie znaczącymi tabelkami, tylko wytłumaczone łopatologicznie.

"Wszystkiemu winne sa konsole" i masoni za głęboko drążysz, moim zdaniem nie wspierają bo nie przekłada to się na "żywą' gotówkę.

Panie Marcinie +10 Respect tylko tak dalej

17.07.2009 13:30

Wątków: 688 | Odpowiedzi: 33289

.

albo Assassins Creed :]

Zapach obietnicy mam... :O

17.07.2009 14:44

Wątków: 4 | Odpowiedzi: 236

infidel, to nie fake

już na dx9 dobrzy programiści robili rzeczy fotorealistyczne - daleko lepsze od tego. A odnośnie konsol - xbox ma zunifikowaną architekturę i stary tesselator (ten sam co w radkach 4xxx) - i M$ przygotowuje implementację dx11, co przy ograniczeniach konsoli powinno nawet dać developerom motywację do starania się

  • Sprawdź bezpośredni link do posta

17.07.2009 14:45

Wątków: 384 | Odpowiedzi: 27239

kurna

przed chwilą nabyłem sprzęt do dx 10.1 a tu crap
zaraz znowu wymianka ...

-.. ..- .--. .- .--- .- ...-...

17.07.2009 14:47

Wątków: 4 | Odpowiedzi: 236

sorry for bump

ale znalazłem coś na potwierdzenie moich słów. patrzcie i skaczcie

http://www.zbrushcentral.com/zbc/showthread.php?t=066278

17.07.2009 14:56

Wątków: 6 | Odpowiedzi: 3391

krkage

no i co z tego? To tylko jeden model - spróbuj stworzyć cały świat gry z taką dokładnością i każdy sprzęt umrze. Konsole faktycznie są ograniczeniem chociaż gry pisane od razu z przeznaczeniem na wiele platform są pisane w ten sposób aby dało się dostosować poziom grafiki do sprzętu - tylko konwersje z konsoli mogą cierpieć na przypadłość słabych tekstur.

17.07.2009 15:10

Wątków: 89 | Odpowiedzi: 1978

...

bardzo dobry art, senkju.

ostatnio coraz mniej gram, chyba się starzeję :/

17.07.2009 15:18

Wątków: 688 | Odpowiedzi: 33289

Kretos...

jeszcze przypadlosc gownianego dzialania na sprzetach innych niz wlasnie konsole... ;/ jak gta...

Zapach obietnicy mam... :O

17.07.2009 15:24

Wątków: 4 | Odpowiedzi: 236

właśnie - btw mam pytanie

odpalałem demka dx11sdk (win7rc) i compute shader 4 mi nie działa. Powinien działać csx4.1 (radeon 3650 dx 10.1) a tu klops. Ktoś na forum wspominał, że to trzeba zaimplementować w driverach dopiero i że użytkownicy ati jeszcze poczekają. To prawda? I czy ktoś próbował samemu te demka odpalić?

17.07.2009 16:31

Wątków: 62 | Odpowiedzi: 2573

.

Nice work

Przy okazji wróciły wspomnienia - gf 256, q3... ech

"Gorzałeczki przed wejściem do hulajgrodu? Czy może nie jedziesz po alkoholu?"

17.07.2009 17:41

Wątków: 27 | Odpowiedzi: 3197

...

Wielki szacun za art.

i3-4330 / Z87-G41 PC Mate / 4850 / 8GB RAM ... ble ble ble | 42.pl/u/wa9

17.07.2009 19:01

Wątków: 0 | Odpowiedzi: 1058

super hiper w zapowiedziach

Tak jak ktos domniemal ,nie ma wielu gier ( no moze 3-4 sztuki )
ktore to sensownie kozystaja z DX10 , przeciez wiekszosc silnikow wykozystanych w obecnych grach siega korzeniami do poczatku 21 wieku no jaja panowie , wiekszosc jesli nie 95% gier dalej liczy geometrie za pomoca CPU :/ jaja na maxa
Takie przecietne GPU z GF 9600 potrafi policzyc szybciej geometrie niz i7 3,5GHz.

Na sensowne gry z grafika godna DX11 poczekamy minimum 2 lata

Haswell 4770K @ 4,4GHz 8GB Ram 2133MHz 2x Sapphire 290 Tri-X CrossFire

17.07.2009 19:05

Wątków: 2 | Odpowiedzi: 130

Art

miodzio, niech młodzi poczytają jak kształtowała się historia xD

E8400 @ 3,6Ghz, A-DATA 2x 2GB, 2,5 TB HDD, ATI 5770 MSI w oczekiwaniu na .... 2012

17.07.2009 19:51

Wątków: 0 | Odpowiedzi: 1058

???

Co do realistycznego Rendera u gory ,to jest to jak najbardziej realny realtime render w DX11 moze i nawet dalo by rade zrobic cos podobnego w DX10 tyle ze pelna scena z tej klasy obiektami i trexturami to pewnie byla by liczona maxymalnie kilka klatek na sekunde za pomoca najnowszego radka z obsluga DX11

Smutne jest to ze na takie modele i obiekty w grach to pewnei karza nam czekac 4-5 lat

Haswell 4770K @ 4,4GHz 8GB Ram 2133MHz 2x Sapphire 290 Tri-X CrossFire

  • Sprawdź bezpośredni link do posta

17.07.2009 20:43

Wątków: 1341 | Odpowiedzi: 41670

MPA2k

Optymista z Ciebie.
Popatrz na to w ten sposób - głowa jednej z postaci to ile? Jedna setna poligonów/tekstur w scenie?
Obawiam się, że nie za 4-5 a raczej 15-25 lat. O ile nie wprowadzą szybciej jakiejś rewolucji, na co można mieć nadzieję czytając co rusz o jakichś przełomach w laboratoriach. Zakładam oczywiście brak level-of-detail -czyli nie chodzi mi o sytuację, gdzie na pierwszym planie, tuż przed kamerą stoi jedna postać, a cała reszta składa się z ułamka tej liczby szczegółów.

Popatrz na demka technologiczne sprzed 7-8lat (a teraz postęp mocno zwolnił. Bardzo mocno. Zwiększyć pobór karty z 20Watt do 150 można było. Ze 150 na 1000 już nie bardzo) i zauważysz, że dopiero teraz takie obiekty pojawiają się w grach (dema na GF4/radki 9700).

Oczywiście mogę się mylić. Może obsługa wielowątkowości i przeliczanie geometrii przez GPU da ogromny skok. Ale o tym się przekonamy dopiero za jakiś czas.

Jeśli połamałeś sobie oczy na tekście posta wyżej, to przepraszam - czasem piszę skrajnie wyczerpany/niewyspany (lub nietrzeźwy,ale to rzadziej), poprawiam na szybko i "shit happens"

  • Sprawdź bezpośredni link do posta

17.07.2009 20:47

Wątków: 3 | Odpowiedzi: 345

?

"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."

To jest bzdura. Nigdy nie było takiego limitu, nawet nieformalnie. A jeśli niby był wtedy to dlaczego miałoby go nie być w DX10 ? Rozumiem, że autor pisał artykuł na podstawie innych źródeł i sam nie posiada żadnego doświadczenia ale tu już odrobiona wyobraźni by wystarczyła. Limit jest taki sam w DX9, DX10, DX11. Czyli nie ma go Może jeśli wziąć to jako średnia ilość odwołań do karty graficznej w ramce to 500 było może w czasach 486/33MHz i PowerVR.

Zatem:
"Jedynym ograniczeniem w tworzeniu liczby obiektów jest obecnie wyłącznie rzeczywista wydajność tandemu GPU i CPU, a nie sztuczny limit narzucony przez API."
- to zdanie jest prawdziwe także dla poprzednich wersji DirectX !

http://grypa666.wordpress.com

17.07.2009 21:28

Wątków: 112 | Odpowiedzi: 5866

123

taaa... wszyscy pamietamy, jak recenzenci sikali na widok modelu strazy pozarnej z demka technologicznego wydanego przy okazji premiery GF256 - kazda srubka, wajcha i wytloczenie na karoserii. Lakier na wysoki polysk i technologiczny orgazm


Plik graficzny (zmniejszony z 640x480) pochodzi stąd



Dziwnym trafem nikt nie wydal gry, ktora polegalaby na obracaniu kamera wokol wozu strazackiego i rejestrowaniu detali. Tak, jak pisze Ronson - wiele tranzystorow jeszcze musi w krzemie utonac, azeby graficzne cuda z dem technologicznych zagoscily w grach.

.:: only happy when it rains ::. .:: x360 gamertag: n0onePL ::.

  • Sprawdź bezpośredni link do posta

17.07.2009 21:33

Wątków: 11 | Odpowiedzi: 5357

Pet

Z tego co się orientuję jesteś chyba bardzo w temacie tworzenia gier i DX, więc może spróbujesz nam odpowiedzieć dlaczego jest tak kiepsko z wydajnością „odciążonych” bibliotek DX10.
Marketingowy bełkot MS znamy chyba wszyscy, zresztą i tu pojawia się cytat o „zmniejszeniu narzutu i znacznym przyspieszeniu generowania grafiki 3D”, a jak Ty się na to zapatrujesz?
Dlaczego mimo generowania jakościowo praktycznie takiej samej grafiki DX10 nadal ma problemy aby być wydajniejszy od DX9?
Czy faktycznie sporo łatwiej i szybciej idzie tworzenie pod DX10?

  • Sprawdź bezpośredni link do posta

17.07.2009 22:13

Wątków: 3 | Odpowiedzi: 345

@Herbol

Grafika jakościowo jest podobna ale tworzy się ją łatwiej Narzut... Trudno powiedzieć. Wydaje mi się, że sama Vista z jakiegoś powodu daje olbrzymi narzut a samo DX10 nie jest takie ciężkie, tylko chodzi w zamulonym systemie.


Chyba wszystkie efekty pokazane w tym artykule to nie są żadne nowe efekty wbudowane w DX10. To są stare efekty zrealizowane za pomocą shaderów DX10. Per-pixel Displacement Mapping, Procedural Growth Simulation i inne to nie wbudowane efekty a jedynie inwencja programistów shaderów.

Obrazek obrazujący nowe formaty tekstur DX10 pochodzi z dema DX9 Toy Shop: http://tinyurl.com/nppae8
Na obrazku jest klatka z pozycji 1m:20s.

"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."
- Tu nie chodzi o jednoczesne nakładanie tej samej bitmapy na wiele obiektów. Tu chodzi o renderowanie jednocześnie na wielu powierzchniach. Czyli zamiast renderować od razu na ekranie to można renderować też na teksturach(konkretnie na jednej powierzchni tekstury). Dzięki MRT na wielu na raz.

http://grypa666.wordpress.com

  • Sprawdź bezpośredni link do posta

17.07.2009 22:50

Wątków: 11 | Odpowiedzi: 5357

Dzięki

Czyli najprawdopodobniej to sprawka cudownego nowego systemu, a nie samych bibliotek DX10.
Ktoś ma jeszcze jakieś pytania dlaczego nie było >żadnych< możliwości napisania DX10 na XP?

  • Sprawdź bezpośredni link do posta

17.07.2009 22:52

Wątków: 3 | Odpowiedzi: 345

A teraz hit :)

Czytając ten artykuł ciągle świtało mi, że już to gdzieś widziałem. I już przypomniałem sobie gdzie:
To artykuł "DirectX 10 bez tajemnic" opublikowany na łamach PCLab: http://pclab.pl/art26921.html
Jak widać pisał go ten sam autor! Ja również miałem okazję zjechać ten artykuł na PCLab w komentarzach o tutaj: http://tinyurl.com/mkh2xc
Jak widać wytknąłem podobne błędy. Po 2 latach tutaj ten sam autor, pomimo że poinformowany o błędach, powiela je tutaj znowu. Nie będę pisał co o tym myślę i niech każdy sobie sam to oceni.

http://grypa666.wordpress.com

  • Sprawdź bezpośredni link do posta

17.07.2009 22:55

Wątków: 3 | Odpowiedzi: 345

@Herbol

Wersja alpha DX10 była na WinXP. Sam posiadałem. Mogłem tylko uruchamiać programy na programowym rendererze bo nie było sterowników od producentów kart graficznych. A przynajmniej ja nie miałem. To DX10 alpha dla XP było w jednym ze starych SDK dla DirectX.

http://grypa666.wordpress.com

  • Sprawdź bezpośredni link do posta

17.07.2009 23:08

Wątków: 11 | Odpowiedzi: 5357

...

Tak sobie myślałem że jakieś prace musiały być, po czym MS mogło się zorientować w różnicy wydajności DX10 XP/vista, to już "się nie dało" zrobić. Kto by kupił nową vistę, jak na xp miał by to samo, a całkiem prawdobodobne (tak przypuszczam), że wydajniej?
Moim zdaniem nie kupił by nikt, więc zostało "nie da się" i po problemie ze sprzedażą (przynajmniej tak myśleli, ale się trochę pomylili ).
Spiskowa teoria? Dla mnie zupełnie nie.

17.07.2009 23:34

Wątków: 19 | Odpowiedzi: 217

Marcin_Bieńkowski

"rispekt"
praca(artykuł)wyczerpująca temat , czytając ma się pewność że autor wie o czym pisze.Jeden z najlepszych art. na frazie.
wielki szacun

### nie wychodź z siebie - możesz nie wrócić ###

18.07.2009 00:08

Wątków: 120 | Odpowiedzi: 19199

...

o dżizas... rozpisaliście się strasznie. A ja tylko dodam marka, żebym mógł sobie jutro na trzeźwo arta readnąć

MSI P35 Neo2-FR, E8400, 4x1GB Mushkin PC1066, Gainward GF 9800GTX, X-Fi, SP1604N, ST3320620A, HD502IJ ,226BW, DVR-215D, Chief 650W; HP nx7400 EY508ES

  • Sprawdź bezpośredni link do posta

18.07.2009 11:09

Wątków: 39 | Odpowiedzi: 1563

;-)

Sztuka czytania chyba zanika - mnie sie podobalo i powiem nawet, ze oczekiwalbym wiecej materialu. Thx

18.07.2009 13:31

Wątków: 498 | Odpowiedzi: 8013

oj pet czytam to co piszesz

przejrzałem sdk i na to wygląda ze masz racje (przynajmniej w tym co ogarniam ), powielony artykuł i do tego z błędami, hmm trochę trzoda.

całe życie człowiek uczy się na błędach, swoich, powielając błędy innych.

  • Sprawdź bezpośredni link do posta

18.07.2009 14:02

Wątków: 1 | Odpowiedzi: 1682

Historia napisana od nowa, w roku 2000 :)

Artykuł długi... szkoda że dużo w nim bzdur. Autor chyba kupił pierwszy komputer w okolicy roku 2000 skoro rozpoczął historię DX'a od wersji 6.1

Tekst że przed DX6 karta graficzna służyła tylko do obsługi ramki to chyba mu się przyśniła. Ciekawe co na to powiedzą użytkownicy np. 3DFX (podpowiedz da autora: 3dfx to taka "starożytna" karta graficzna ze sprzętowym! mapowaniem tekstur oraz wsparciem dla OpenGL'a zwanym Glide). A tak serio czy pamięta jeszcze ktoś na tym forum takie katy jak Riva128, GLQuake... demo FinalReality... czy tylko ja tutaj jestem taki stary

Jak zamieniłem swojego S3Virge3D na nową Rive128 to mi w FR liość klatek z 0.2fps wzrosła do ponad 20fps... Nigdy później żadna karta graficzna nie była takim przełomem (ponad 100x szybsza od poprzedniej popularnej karty na rynku)

  • Sprawdź bezpośredni link do posta

18.07.2009 14:12

Wątków: 1341 | Odpowiedzi: 41670

arval

nie jesteś stary. Młody jesteś.
Ja zmieniłem Tridenta 8900c 512 (nie magabajtów! pamięci brakło do wyświetlenia obrazka 2D w 1024x768 przy 256kolorach) na kartę na PCI. To była przepaść.
Potem S3 Virge, bo to akcelerator 3D. Za całe 350zł (odpowiednik dzisiejszych... hmm.. 600-1000zł).
Potem 3DFX i wreszcie MDK z rozmytymi teksturami, Turok (płynnie! na 3D Virge wyglądał strasznie i miał z 1fps).
I fakt. Sam mam do dziś mini-kierownicę InterActa która działa tylko na Win95 i Direc X 5.0 czy 5.1 - zainstalujesz nowsze (6.0) i już nie działa ) Może potrzymam jeszcze troszkę i oddam do muzeum albo wezmę jakiegoś kompa z tamtej epoki, zainstaluję TOCA i dam jakiemuś 5latkowi w prezencie. Zabawę będzie miał lepszą niż grając na biurowej integrze w dzisiejsze tytuły. "Grając" bo 5fps to nie to samo co 60fps w Toca z 1998r.

Jeśli połamałeś sobie oczy na tekście posta wyżej, to przepraszam - czasem piszę skrajnie wyczerpany/niewyspany (lub nietrzeźwy,ale to rzadziej), poprawiam na szybko i "shit happens"

  • Sprawdź bezpośredni link do posta

18.07.2009 14:28

Wątków: 1 | Odpowiedzi: 1682

Oj dawne czasy...

Ja pamiętam jak odpalałem wersję GL Quake.

Teoretycznie nie działała ona na karcie Riva128 ponieważ pisana była tylko pod 3dfx'a (Glide). Wystarczyło jednak zabrać opengl32.dll z katalogu systemowego i wgrać do folderu gry (nadpisać wersję dla 'glide'). I wszystko nabierało zupełnie nowego wyglądu, dało się też rozdzielczość zwiększyć ze standardowej 320-200, lub 400-300 na wysoką w stylu 640-480... Oj to były czasy.

Uczyłem się wtedy programować w OpenGL, aż łezka się dziś w oku kręci

  • Sprawdź bezpośredni link do posta

18.07.2009 14:49

Wątków: 1 | Odpowiedzi: 1682

@Ronson

Ja się na Tridenta nie załapałem. Przesiadałem się z Amigi bezpośrednio na Pentium z S3 Virge.

No ale wcześniej za to załapałem się na pisanie prostych programików na Commodore16. To był dopiero czad. Miałeś dwa tryby graficzne. Albo 320-200 w trybie dwukolorowym (kolor i tło) albo tzw. tryb graficzny. To był prawdziwy wypas. Jeżeli dobrze pamiętam to rozdzieczczość spadała do 160-200 (lub 160-100) i mogłeś używać nawet do 4 kolorów! Z założeniem jednak że w kwadracie 8-8 pixeli znajdą się tylko i wyłącznie 2 kolory.

Później pojawił się C64 ale tam to grafika już była zupełnie z innej bajki. A jak ktoś miał stację dysków to dodatkowo komputer dostawał kopa mocy obliczeniowej. Procesor w stacji dysków był szybszy niż jednostka centralna więc dema technologiczne na "scenie" ludzie liczyli na stacji dysków. To był chyba pierwszy prawdziwy akcelerator z technologią NVidia CUDA

  • Sprawdź bezpośredni link do posta

18.07.2009 15:09

Wątków: 316 | Odpowiedzi: 25516

arval

nie ty jeden taki stary ale w tamtych czasach to ja nie siedziałem na wyjątkowo gównianym i biednym PC, wówczas wypas to była Amiga... szkoda że marketing się popieprzył bo po latach widać że wizję mieli ok (specjalizowane układy do każdego zadania) tylko dupy dali.

18.07.2009 15:10

Wątków: 737 | Odpowiedzi: 41186

ronson

virge to nie nie byl zaden akcelerator 3D. Tez mialem... dzialal w tandemie z voodoo 1 - 4mb. Lacznie 8mb... To byla moc.

Rzadko inteligencja idzie w parze z urodą ale u mnie tak się jakoś złożylo

18.07.2009 15:30

Wątków: 10 | Odpowiedzi: 6445

...

Co by nie pisac o przelomach to jak narazie NIC nie przebije tego co wstawie ponizej, przeskok byl po prostu gigantyczny, na glide w sli to cos wygladalo po prostu nierealnie i tak sie nazywalo - moze doczekamy sie kiedys znow takiego przelomu, jak narazie nie widac konkurencji, i nawet wszelakie "kryzysy" moga conajwyzej ta gre pocalowac w "kod"



Nic dodać, nic ująć... jestem boski! :-)

  • Sprawdź bezpośredni link do posta

18.07.2009 15:33

Wątków: 1 | Odpowiedzi: 1682

@lukpep

S3Virge 3D był prawie akceleratorem. Wspierał sprzętowo mapowanie tekstur (choć bardziej nazwałbym to rozmywaniem tekstur).

Przykładowo mogłeś na tej karcie w trybie 'hardware' odpalić grę Tomb Rider 2. Niestety gra wymagała 4MB pamięci graficznej na tekstury a sprzedawana w sklepach była natomiast wersja 2MB (z możliwością rozbudowy pamięci graficznej do 4MB!). Od biedy jednak można było odpalić grę także na wersji 2MB jednak od czasu do czasu zdarzało się że znikały tekstury z otoczenia.

Inna sprawa to oczywiście wydajność. Karta s3 sprzętowo wykonywała tylko najprostsze operacje filtrowania. Przełomem był dopiero 3dfx który bez wątpienia zasłużył sobie na miano pierwszego prawdziwego akceleratora 3D.

  • Sprawdź bezpośredni link do posta

18.07.2009 15:57

Wątków: 2645 | Odpowiedzi: 40164

lukpep...

... ma racje, Virge to dupa a nie akcelerator tez taka mialem, tylko 2MB po zmianie na Rive128ZX z 8MB skok wydajnosci był kolosalny :]

edit
no to jednak nie mam racji

...

18.07.2009 15:59

Wątków: 737 | Odpowiedzi: 41186

ja mialem ze sklepu

normalna wersje 4mb. Rok 1998 to byl z tego co pamietam.
Pochodzila z 2-3 miesiace i poszla z dymem (doslownie - zasmierdziala palona elektronika i umarla - ladny babel sie zrobil na chipie) - wymienili mi na blizniacza S3 Trio 3D rowniez 4mb

Rzadko inteligencja idzie w parze z urodą ale u mnie tak się jakoś złożylo

18.07.2009 18:07

Wątków: 25 | Odpowiedzi: 1180

tyjty

Virge DX/GX/2 itd. był akceleratorem. Były specjalne sterowniki (a raczej plik *.dll), które pozwalały odpalić GLQuake.
Pierwszy Jedi na Virge'u też miał rozmyte textury, to była jazda
Tak jak piszecie - akceleracja sprowadzała się do filtrowania tekstur, dopiero VooDoo dostało sprzętowy culling (ucinanie niewidocznych powierzchni), który dał dodatkowo zwiększoną wydajność.

  • Sprawdź bezpośredni link do posta

18.07.2009 18:27

Wątków: 3 | Odpowiedzi: 345

.

Zgadzam się z osobami piszącymi wcześniej, że pisanie o tym, że akcelerator 3D to dopiero od DirectX 6, 7 to jakieś nieporozumienie. Sprzętowa akceleracja 3D, jeśli brać pod uwagę tylko DirectX, została wprowadzona już w DirectX 2. A pierwszą grą z tego korzystającą był prawdopodobnie Hellbender:
http://en.wikipedia.org/wiki/Hellbender_(video_game)
Pamiętam dobrze tą grę. Zagrywałem się w nią z akceleratorem 3D. Teraz sobie gram w Jedi Knight Dark Forces 2 pod DirectX 5, także z akceleracją 3D. Jeśli to nie jest prawdziwa akceleracja to ciekaw jestem jak wygląda ta prawdziwa.
Ja podejrzewam, że tak jak z poprzednimi rzeczami, to autor przepisał po prostu z materiałów reklamowych Nvidii od geforce1 to zdanie, że dopiero nadszedł prawdziwy akcelerator 3D i wziął to na serio

http://grypa666.wordpress.com

18.07.2009 18:50

Wątków: 275 | Odpowiedzi: 17250

...

Virge miał tego pecha że był pierwszy. Był taki sobie, nie był zły, może nawet był niezły, ale jakieś pół roku po tym jak się pojawił nadszedł 3DFX i zmiótł wszystko z powierzchni zostawiając tylko pogłos skomlenia konkurencji który niósł się po świecie jeszcze długo, bardzo długo.

Mówię właśnie o Virge 2MB (bodajże "325 2MB PCI"), rozszerzalny do 4MB ale kto by kupował 2MB za cenę wyższą niż cała karta w sklepie, żadna gra oprócz Croc i tak nie chodziła na tym normalnie w okolicach hi-res.

Po tym Virge wyszedł DX/GX/GX2 czy jeszcze inne wariacje Virge, 4MB - i to były już naprawdę przyzwoite karty, parę gierek chodziło na tym zupełnie znośnie.

Nie pamiętam który to chip od S3... OK pamiętam.
Savage (Savage4) pamiętacie? Z S3TC? To była niezła rewelacja, skończyło się na tym że oczywiście karty S3 zdechły, ale technologia przeszła do innych i to samo S3TC oglądałem w demku technologicznym GeForce2 dłuuugo później jako sprzętową rewelację.
Nota bene, dla Unreala pokazała się łatka S3TC. Quake3 też dawał z tym radę i dostawał kopa jak po redbullach, ogólnie to był kawał niezłej technologii.

Ta stara zapomniana firemka S3, do dzisiaj mam do niej sentyment przez mój pierwszy, podkręcalny o 80% (chip i mem oczywiście synchro) "akcelerator 2D/3D".

adsm.pl

18.07.2009 18:51

Wątków: 275 | Odpowiedzi: 17250

errata

S3TC w akcji (Unreal)


Plik graficzny pochodzi z HDD usera (Zobacz oryginał)

adsm.pl

18.07.2009 18:58

Wątków: 6 | Odpowiedzi: 3391

s3

mialo problem ze sterami - mialem savage4 i pamietam miliony kombinacji sterownikow - w koncu bylem tym zmeczony i chetnie pozbylem sie tej karty. Ale faktycznie tam gdzie mozna bylo wlaczyc metal (API s3) to karta dzialala swietnie. Z S2000 dali d... i tyle. A historie z komputerami zaczynalem od XT:) Lezka sie w oku kreci.

  • Sprawdź bezpośredni link do posta

18.07.2009 19:44

Wątków: 1 | Odpowiedzi: 1682

@jory

Savage4 - Jezu co to była za tragedia.

Programowałem kiedyś pod tą kartę na studiach prostą gierkę w OpenGL. Tragedia. Podstawowe polecenia z OGL zachowywały się zupełnie nieprzewidywalnie. W dodatku co pojawiała się nowa wersja sterowników to coś ktoś poprawił a coś innego przestawało działać. Do tego stopnia że testowałem program u znajomego ponieważ nigdy nie byłem pewny wyniku u siebie. Męczyłem się tak ponad pół roku zanim uzbierałem na GF2MX - karta idealna

  • Sprawdź bezpośredni link do posta

18.07.2009 20:44

Wątków: 384 | Odpowiedzi: 27239

arval

dla mnie best eva to gf3 ti
cudo
potem to już tylko klonowanie ... i tak już po dziś dzień

-.. ..- .--. .- .--- .- ...-...

  • Sprawdź bezpośredni link do posta

18.07.2009 23:27

Wątków: 1341 | Odpowiedzi: 41670

heh

jasne, że virge to dupa a nie akcelerator, ale jak go kupowałem to BYŁ akceleratorem wychwalanym w Secret Service. Nie stac mnie bylo na matroxes mystake to kupilem virge'a 4MB - poczatek 97r.
jedi,
monster madness
mdk
i pare innych, o ktorych teraz nie pamietam, chyba tez descent-dzialaly dobrze z akceleracja, choc obraz byl jakby przez sito i akceptowalna plynnosc 20-30fps uzyskiwalo sie tylko w 320x240 ew. 400x300.

Rok pozniej jechalem na gielde do Warszawy po Pentium 200MMX ale wrocilem z Helios 3D Voodoo.
Z dwoch powodow:
1. bo okazalo sie ze byly w rewelacyjnej, o polowie nizszej niz do tej pory cenie - tylko 300 czy 400zl.
2. bo kumplowi kupowalem czesci na pentium 2 i tez to kupil - wiedzialem jaka to rewelacja po recenzjach z gazet. wiedzialem ze jak zobacze gry na jego sprzecie to sie pewnie potne. Nie bylo dyskusji. Zmiana monitora musiala poczekac.
Wrocilem wiec do domu i podpialem 3dfxa do mojej- wtedy 7letniej 14"tki z widzialna w 640x480 na poziomie 11" bo to juz hires byl i nie dalo sie rozszerzyc obrazu na max na boki
Turok, Redline Racer, unreal, forsaken - tych chwil nie zapomne. Siedzielismy z kumplem nad jego rozbebeszonym nowym kompem i zamiast go montowac nie moglismy oderwac oczu od tego jakie cuda na monitorze ten akcelerator pokazywal.

BTW. Ja od tridenta nie zaczynalem tylko od Atari, ale o PC byla mowa. Tez uczylem sie pisac programy w basicu i wybierac tryb graficzny - widzialem na telewizorze piksel i wydawal sie on tak malutki, ze nie nie sadzilem ze kiedykolwiek bedzie potrzeba go zmniejszac. A to byla rozdzialka... nie wiem.. cos kolo 160x120 pewnie

Jeśli połamałeś sobie oczy na tekście posta wyżej, to przepraszam - czasem piszę skrajnie wyczerpany/niewyspany (lub nietrzeźwy,ale to rzadziej), poprawiam na szybko i "shit happens"

18.07.2009 23:32

Wątków: 10 | Odpowiedzi: 6445

...

Ronson nie badz taki skromny...
"1. bo okazalo sie ze byly w rewelacyjnej, o polowie nizszej niz do tej pory cenie - tylko 300 czy 400zl."

Nie 300zl a 3.000.000zl, tak, takie to byly czasy co czlowiek mogl sobie kupic co mu pasowalo... nowa karta? jest... nowy mercedes 600sl? jest... a zobacz co zrobily z nas rzady kaczynskiego i tuska? dziadujemy miliony odeszly w siną dal, a dzis zyjemy za "stówki" a kiedys "piecsetkami" sie tapetowalo pokoje






Nic dodać, nic ująć... jestem boski! :-)

19.07.2009 00:41

Wątków: 737 | Odpowiedzi: 41186

a wracajac do tematu

oby z tego DX11 korzystalo wiecej tytulow niz z dziesiateczki...

Rzadko inteligencja idzie w parze z urodą ale u mnie tak się jakoś złożylo

19.07.2009 10:11

Wątków: 4 | Odpowiedzi: 35

Czas leci

Jak człowiek czyta takie artykuły, a przede wszystkim komentarze pod nimi, to zdaje sobie sprawę, jak czas szybko i nieubłaganie zapierdziela przed siebie, a wszystko, co było kiedyś, ZAWSZE wydaje się być lepsze, niż to, co jest teraz .

Uczucia jakie przeżyłem, przesiadając się z Intela 720, czy jak jej tam było, na GeForce2 256 GTS, odpalając w 1024x768 Aliens Predator i FAKK2 w pełnych detalach, nigdy nie zapomnę. Człowiek czuł, że żyje w czasach, w których dokonują się rzeczy niezwykłe. Jak zainstalowałem 8800GTX i coś odpaliłem, to już było tylko "no, w końcu można se spokojnie popykać". Już nie było tych wypieków na twarzy, tej ekscytacji .

A jak odpaliłem Age of Conan pod DX10 i zobaczyłem 10fps to szybciutko wróciłem do DX9, gdzie ze z wszystkim na full spokojnie mam 30-50. I tak się sprawa ma pod Vistą . Pod Win7RC jest zdecydowanie lepiej.

"Twice the pride - double the fall" - Count Dooku

  • Sprawdź bezpośredni link do posta

19.07.2009 12:02

Wątków: 1 | Odpowiedzi: 1682

@bartphil

NV 8800 to był przełom po kilku latach stagnacji. Prawdziwy skok technologiczny który umożliwił zaistnienie takich silników jak Unreal Engine 3. Na 8800 po dwóch latach ciągle zagrasz w każdą nową grę na max detalach!

Myślę że kolejny przełom pojawi się dopiero po kolejnej edycji konsol. Mam nadzieję że ok 2011/2012. Sony swoje konsole zawsze wydaje dokładnie co 6 lat (1994, 2000, 2006) i dostarcza support 10lat. Konsola Microsoftu z 2005r też nie jest już nowością

PS: Fajny wywiad z założycielem Epic (Unreal) o historii gier można przeczytać pod tym adresem:

From The Past To The Future: Tim Sweeney Talks
http://www.gamasutra.com/view/feature/4035/from_the_past_to_the_...

19.07.2009 14:50

Wątków: 275 | Odpowiedzi: 17250

arval

Dokładnie, S3 samo pogrążało się nieumiejętnością stworzenia normalnych sterowników.

Kiedyś wyhaczyłem dla kumpla zestaw za parę groszy, w którym miała być bodajże Ati Rage 8MB, a okazało się że jest S3 Savage 4 lub 2000. No i cóż, naprawdę nieźle to chodziło, karta nie była zła.
Tyle że kumpel miał 2 ulubione gierki i by zagrać w jedną musiał wgrać starsze stery od S3, a by zagrać w drugą musiał wgrać nowsze stery od S3. Ale nie narzekał.

adsm.pl

19.07.2009 21:04

Wątków: 54 | Odpowiedzi: 4630

hmm

z gier na ViRGE nieźle działał AFAIR Terminal Velocity (z wyłączoną korekcją perspektywy)

sam ViRGE zyskał zaś sobie przydomek pierwszego "deceleratora"

20.07.2009 01:14

Wątków: 502 | Odpowiedzi: 14786

arval

No z tym że każda pójdzie na full to nie przesadzaj- pójść se może, ale z jakim FPSem i z jaką rozdziałką? Ale dla posiadaczy monitorów tak do 1440x to nadal spokojnie wystarczająca grafika

Cóż, pecetowcy marudzili że pomiędzy takim PS2 a PS3(czy analogicznie, X1 a X360) nie było takiej różnicy. Pecetowcy to se mogą gadać, bo zawsze se mogli ustawić natywną, a nowe konsole właśnie zdecydowanie(bo coś koło 4x) większą rozdziałką jakoś musiały se poradzić
Co kilka lat jest to samo. Po wyjściu nowej konsoli ohy ahy, po dwóch latach twórcy gier dochodzą do granic możliwości sprzętu, a pecetowcy tylko marudzą "Tylko na tyle was stać?"

Ale przyznaje- brakuje porządnej rewolucji na rynku kart graficznych. Chętnie wymienił bym za rok 8800GT na coś, co nie opróżni mojego portfela, i nie pożre całej elektrowni. Jednak 1920x1200 to nadal sporo dla nowoczesnych kompów

C2D E8200 2,66@3,6, Blood Iron P35, 4GB, F1 500GB + M4 64GB + 500GB zew, 460GTX, Xonar D1, Genius 5005, Creativ Aurvana Live!, Windows 7, PS3, Xbox 360, PSP, Panas 50G30, Galaxy S II

20.07.2009 09:39

Wątków: 498 | Odpowiedzi: 8013

ech

Ja też czynnie uczestnicze w tej historii, zaczynałem na kartach hercules i pamiętam, jak trzeba było wgrywać plik hcgfulll do gier żeby dało sie uruchomic;). Pierwszą kartą z prawdziwego wrązenia był paradise, a potem tseng. Kiedy w końcu uzbierałem kupiłem sobie s3 virge 4mb na agp! . Jaki to byl wypas, pierwszą gra, któą oglądałem u siebie w 3d to był monster truck madness, ktory chodził zajebiście i wyglądał naprawde lepiej. Potem przyszły czasy 3dfx (helios), ktory w tandemie z s3 działal naprawde bardzo dobrze. Riva 128 zx to był przełom na miarę pierwszego akceleratora, bo niedojrze dawał możliwość zmiany rozdzialki (3d fx nie), to już pojawial sie uniwersalny standard opengl, który działał na wszystkim (pamiętaj efekt ditheringu na tej karcie, z ktorym sie walczyło). ppote kiedy nadeszła tnt wszystko poszło z górki, największą bolączką tamtych czasów była nie technologia a sterowniki, które zabijały sprzet. Mialem karty z serii savage od 3d, 4 i savage 2000 i karty te jak już zaskoczyly prawidlowo to gniotły. Pamiętam savage 4 i unreala z s3tc, ktore po uruchomieniu po prostu miażdzyły płynnością i grafiką.
Na zakończenie dodam, ze czasem u kumpla, który do zabaw ma p3 500 z 512 ram, matrox millenium agp 8mb i 2 x voodoo 2 12mb i powiem, ze widzialem doom3 na tym, oraz unreala 2004 chodzącego plynnie, co tylko pokazuje jaki potencjal tkwi w tym sprzęcie(a potencjal ten wykorzystany jest dopiero teraz jak ludzie sami piszą sterowniki).

całe życie człowiek uczy się na błędach, swoich, powielając błędy innych.

  • Sprawdź bezpośredni link do posta

20.07.2009 09:50

Wątków: 64 | Odpowiedzi: 14932

hmm

prawda jest taka, że dopiero od DX7 i kart GeForce, no może Riva TNT zapanował ład w standardach i jakości 3D. Miałem S3 Trio 3D 4MB i praktycznie żadna gra, nawet najstarsza nie wyświetlała poprawnie obrazu. Brakujące tekstury, to był jedyny standard tych kart. Voodoo nie dorastało to do pięt. W momencie jak kupiłem GF256 to każda gra się uruchamiała poprawnie. Wynalazki typu Virge, czy Savage to ślepe zaułki ewolucji, eksperymentowanie na klientach przypominające HDDVD technologicznie niezłe, ale też bezużyteczne.

Yo, pick up da phone! Wassuuup...

20.07.2009 12:08

Wątków: 275 | Odpowiedzi: 17250

...

Trio 3D 4MB AGP to była biurowa karta na AGP. Tylko po to chyba wyszła, a 3D w nazwie zmyliło wiele osób.

S3 owszem, były złe ale przez sterowniki. Same karty, gdyby poprawnie radziły sobie z OpenGL/D3D albo z drugiej strony gdyby Metal miał więcej wsparcia, byłyby dobre.

Jaka to była karta od S3 która wyszła w czasach Radeon 9600? Chrome?
Pamietam z testow ze byla naprawde niezła i tania, tyle ze standardowo - spieprzone stery. Poprawimy w nastepnej wersji.. ktora nigdy nie wyszla.

adsm.pl

20.07.2009 13:11

Wątków: 22 | Odpowiedzi: 1717

miałem s3 trio 3d

fajnie, jak w grach brakowało jej ramu i wyświetlała gołe modele bez tekstur. Nie pamiętam jaka karta była w 286 mojego ojca;) Pamiętam, że po modernizacji kompa do 386, mieliśmy dysk 30 mb, kumpel mi przyniósł Mortal Kombat którąś tam, spakowaną na 15 dyskietkach, czy nawet więcej. Po rozpakowaniu nie mieściła się na dysku Pamiętam też jaki szał cenowy był z pierwszymi voodoo.

Asus Z77 Sabertooth / i5 2500K@4.8 GHz / 8Gb DDR3 G.Skill 1600 ECO / Asus GTX670 DCuII SLI / Samsung 840 Pro 256Gb / 2xSSD 120Gb / PS3

20.07.2009 13:12

Wątków: 737 | Odpowiedzi: 41186

potem przeskok

na GF2 MX mialem - jaka roznica

Rzadko inteligencja idzie w parze z urodą ale u mnie tak się jakoś złożylo

20.07.2009 14:03

Wątków: 498 | Odpowiedzi: 8013

hmmm

moja pierwsza prawdziwa karta grafiki to czysty renesans czyli creative geforce annihilator pro czyli gf 256 ddr, kupiony 2 tygodnie po premierze ale to był wypas. I co by nie mówić piwersze detonatory od nv ssały pałe na całej lini, długi czas byly problemy z tytułami. Dopiero od któres serii nagle wszystko zaczeło smigac jak ta lala i już tak zostało, sterowniki od nv staly sie wzorcowe

całe życie człowiek uczy się na błędach, swoich, powielając błędy innych.

20.07.2009 14:18

Wątków: 275 | Odpowiedzi: 17250

...

Tak jakby wzorcowe, pamietam mase zagrań NV w stylu obniżanie tekstur do żenującego poziomu (Det 43.11?).
Wszystko przez 3dmark.

adsm.pl

20.07.2009 14:27

Wątków: 502 | Odpowiedzi: 14786

.:.

Chyba ATI i NV miało takie desperackie posunięcia w swoich dziejach

C2D E8200 2,66@3,6, Blood Iron P35, 4GB, F1 500GB + M4 64GB + 500GB zew, 460GTX, Xonar D1, Genius 5005, Creativ Aurvana Live!, Windows 7, PS3, Xbox 360, PSP, Panas 50G30, Galaxy S II

20.07.2009 17:16

Wątków: 10 | Odpowiedzi: 6445

...

O widze ze ktos legende przypomnial. Zaden dzifors nie mial tak dlugiego "brania", bycia "na topie", wypowiadania sie w samych superlatywach jak pierwszy CLAP Creative Labs Annihilator Pro. Pamietam jak wpadlem do kumpla ktory kupil to cudo za chyba 15 baniek... bedac posiadaczem 2xV2-8mb troche mi mina zrzedla

Tak, pamietam wselakie Elsy, Herculesy, wspaniale karty ale CLAP to po prostu legenda

Nic dodać, nic ująć... jestem boski! :-)

20.07.2009 17:20

Wątków: 275 | Odpowiedzi: 17250

...

Moj kumpel wylal kiedys na swojego CLAP, 0.5 litra slodzonej herbaty. Komp byl wlaczony (buda pod nogami i otwarta).
I nic

CLAP rządzi.

Przypomnieliscie mi BTW jeszcze bump-mapping ktory wprowadzil bodajze.... matrox w G400. ;]

adsm.pl

20.07.2009 17:57

Wątków: 7 | Odpowiedzi: 138

...

Z tego wrzystkiego, to najsensowaniejsza z punktu widzenia grafika jest Tesselacja. Taki odpowiednik subdivision oraz zwiększenie textur z 2k na 4k.

Nie ma co ukrywać, że kolejne DX są robione z myślą o programistach.

Wszystkie screeny porównawcze to wałek, o tym wiadomo nie od dziś.

Karolinka GG:12909312

  • Sprawdź bezpośredni link do posta

20.07.2009 19:13

Wątków: 1 | Odpowiedzi: 1682

@jory

"Tak jakby wzorcowe, pamietam mase zagrań NV w stylu obniżanie tekstur do żenującego poziomu"

To było w czasach "super karty graficznej" zwanej suszarką. To nie byłą wina 3DMarka a po prostu nieudanego produktu GF5 FX. Pamiętam jak ludzie czekali na tą kartę (miało być to połączenie wiedzy zespołu NV z zespołem od 3DFX).

Już miała się pojawić aż tu nagle pojawił się ATI 9700 PRO. Karta NV była ponad dwukrotnie słabsza (nawet słabsza niż wcześniejsze GF4TI) więc NV zagrał na czas.

Najpierw opóźnili premierę karty o ponad pół roku robiąc na stronie licznik, demonstracje etc. Później pojawiła się karta i 3DMark ją po prostu zniszczył. Dołożyli się programiści niezadowoleni z konieczności ręcznego sterowania dokładnością operacji (były dwa tryby 16, 32bit - ATI miało tylko jeden 24bit). No ale zagranie na czas się opłaciło. Karta była na rynku niecałe pół roku i pojawił się nagle GF6 który działał już jak należy (w rok po premierze ATI)

GF5 FX to były ciężkie czasy dla NV, i ratunek dla tonącego od kilku lat ATI

20.07.2009 20:24

Wątków: 498 | Odpowiedzi: 8013

jory małe sprostowanie

bump mapping miał też gf 256, chodzi ci o enviroment bump mapping w g400 (wg mnie karta z potencjałem ktorego nie wykorzystano), z mappingu korzystały 2 gry slave zero i expendable o ile sie nie myle. Co do annihilatora pro to w wielu grach (szczególnie po podkręceniu) był szybszy od gf 2 mx 400, 4x1 potoków vs 2x2 , ja swojego annhihilatora zmieniłem na dopiero na gf 2 pro a potem na 2 ultre, na jej widok prawie mi stanął tak wielka to była karta:)

całe życie człowiek uczy się na błędach, swoich, powielając błędy innych.

  • Sprawdź bezpośredni link do posta

20.07.2009 21:49

Wątków: 3 | Odpowiedzi: 345

@Spuki

Gier z EMBM było o wiele więcej niż 2. Mi EMBM w Matroxie G400 bardzo się podobał i pamiętam, że miałem go w wielu grach. Koleś co miał GF1 tylko mi zazdrościł bo nie miał żadnej gry z takim efektem, a wrażenie jakie to robiło było kolosalne Lista gier z EMBM:
Aquarius
Battlezone II: Combat Commander
Battle Isle: The Andosia war
BITM
Carmageddon: TDR 2000
Colin McRae Rally 2
Descent 3
Descent 3: Mercenary
Destroyer Command
Drakan
Dungeon Keeper 2
Echelon
Echelon: Wind Warriors
Expendable
F1 World Grand Prix
Far Gate
Fur Fighters
Hard Truck II
Hired Team Gold
Hired Team: Trial
Incoming Forces
Parkan: Iron Strategy
Ka-52 Team Alligator
Kyodai
Off Road: Redneck Racing
Offshore2000: Pro Surf Tour
Planet Heat
Private Wars
Rollcage Stage II
Silent Hunter II
Silent Space
Slave Zero
Speed Busters
Spirit of Speed 1937
Sub Command
Jugular Street Luge Racing
Totaled
Warm Up
Wild Metal Country

To nie pełna lista bo ja pamiętam dodatkowo:
Kyodai Mah Jongg (fajna logiczna, chyba znana każdemu - do dziś gram w jakąś tam wersję tej gry).
I jeszcze dużo innych mniejszych shareware gierek miało ten efekt.

GF miały Dot-3 BM teoretycznie bardziej poprawne ale jednak wyglądało gorzej od EMBM i tak bardzo obciążało to kartę, że gier w czasach GF1, GF2 z tym praktycznie nie było. Pamiętam tylko jedną grę z Dot3 BM. Był to Giants: Citizen Kabuto. Poza tym karty już wcześniej robiły Emboss BM ale to już w ogóle było słabe.

http://grypa666.wordpress.com

  • Sprawdź bezpośredni link do posta

20.07.2009 21:53

Wątków: 1341 | Odpowiedzi: 41670

Spuki


Od razu widać, żeś też stary piernik.

Hercules to karta, na której uczyłem się obsługi DOSa u jednego "komputerowca" (wtedy "informatyk" nie było prawie znane).
Zabaw nie pamiętam, bo walnąłem z grubej rury po czytaniu recek w Top Secret - że dziś rządzi VGA, a nawet Super VGA. I pierwszy PC w kupiony zanim świat ujrzał Wolfensteina miał właśnie ten "hi-end". Co prawda nigdzie się to prawie w grach nie przydało. (Jakoś nie pamiętam aby cokolwiek w hi-res chodziło na tym znośnie - poza Windowsem 3.11, któremu wystarczało i 1FPS ) ale wśród kumpli był szpan - inni mieli EGA'i czy CGA'i.
Pamiętam za to kombinowanie z uruchamianiem gier tak, aby wymusić EGA zamiast CGA.
Ehh.. mało dziś aktywnych graczy którzy pamiętają czytanie recek w wychodzącym co 2 miesiące (teoretycznie) Top Secrecie:

IBM PC EGA/VGA

- to znaczyło, że potrzebny współczesny komp, a nie jakieś stare XT.

Dalej spieszę donieść, że Annihilatora PRO kupiłem jak tylko staniał (jako używkę) po dłuugim czekaniu (po premierze byłem na nią napalony jak na szczerbaty na suchary, ale ponad tysiak...)
Niestety w przeciwieństwie do GF2 MX nie oferował korekcji kolorów zwanej dziś "digital vibrance" lub "poświata cyfrowa" (WTF???)

Do tego zgadza się - bump mapping oferował tylko Slave Zero i Expandable na początku.

Ale GIANTS Citizen Kabuto męczyłem jeszcze na CLAPie i tam był piękny bump mapping.

Ale największe masz u mnie za to, że znasz te czasy, gdy karta PARADISE była obiektem westchnień.
Jak ja chciałem mieć kartę na Vesa Local Bus albo na PCI...
niestety upgrade z 386tki drogą zakupu płyty za granicą przez znajomego okazał się klapą, przez co przez prawie 2 lata nie miałem własnego peceta. Duke Nukem'a więc przeszedłem na pożyczonym 486 DLC z grafiką na PCI - co to był za wypas!
Duke Nukem w 400x300 czy 400x200 (ale wyżej niż VGA) w 60fps, Doom i Heretic też (wreszcie!), obsługa tego super extra zajebistego trybu hi-color i pierwsze rendery w POV-RAYu.
Apropo DLC - najlepsza recenzja sprzętu w historii - ta w Bajtku. Pamięta ktoś? Albo kurs POV-RAYa ?
To se ne vrati.

BTW. Chyba lekko niechcący zrobiłem "mały" offtopic w tym wątku. Oops...

Jeśli połamałeś sobie oczy na tekście posta wyżej, to przepraszam - czasem piszę skrajnie wyczerpany/niewyspany (lub nietrzeźwy,ale to rzadziej), poprawiam na szybko i "shit happens"

  • Sprawdź bezpośredni link do posta

20.07.2009 22:00

Wątków: 1341 | Odpowiedzi: 41670

tak mi coś właśnie

nie pasowało.
GF1 miał DOT bump mapping czy jakoś tak.
Prawdziwy EMBM miałem dopiero w GF4.
Ale bump mapping w giants i tak był. Ten metodą DOT.

Jeśli połamałeś sobie oczy na tekście posta wyżej, to przepraszam - czasem piszę skrajnie wyczerpany/niewyspany (lub nietrzeźwy,ale to rzadziej), poprawiam na szybko i "shit happens"

20.07.2009 22:42

Wątków: 498 | Odpowiedzi: 8013

ech maiem farta bo onciec pierw

pracował punkcie napraw sprzętu elektronicznego a potem miał firm ę komputerową, wiec sprzęt był. W ramach ciekawostki podam dla młodszych czytelników, ze pierwszy pixel shader zaaplikowała nv w karcie gf 2 . Był on w wersji 1.1 - nigdzie nie wykorzystanej (oprócz dema dino island - później far cry - swoją drogą długa drogę z wyspy dinozaurów do strzelałki przeszedł), rzeczywiste efekty wykorzystano dopiero w wersji 1.3 w gf3 co śmieszne tym razem ati poszło dalej dało ps w wersji 1.4 mimo ze technologiczne lepszy nie był nigdzie wykorzystywany oprócz 3d marka i kilku testów ati. Tak samo jak całkiem niegłupia jak na te czasy technologia truform, coś podobnego opublikowała nv jako vertex skinning bodajże. Może nie jest to samo w realizacji ale efekt był podobny (ati zwiększało ilość trójkątów, a nv łączyła wystające polygony w celu zaokrąglenia).

całe życie człowiek uczy się na błędach, swoich, powielając błędy innych.

  • Sprawdź bezpośredni link do posta

20.07.2009 23:02

Wątków: 1341 | Odpowiedzi: 41670

Spuki

Było kilka gier korzystało z PS 1.4
Były gry, które wymagały 2.0 ale od biedy dało się je zmusić do działania na 2.0 z większością efektów, czego nie dało się zrobić na 1.3 czyli gf3-4.



=======================================

Swoją drogą. Po tyyylu latach mamy w grach dopiero 1.3 w tym sensie w jakim miało być od początku - czyli dodatek, ulepszenie bez straty wydajności.
Może to wina konwersji z konsol, ale w co drugiej grze widzę wodę czy co innego na poziomie GF3. No ale to w elementach nie na pierwszym planie i w sytuacji gdy nawet x360 czy ps3 mogą sobie pozwolić na te "dodatkowe efekty" bez istotnego spadku wydajności.
Np. w wyścigach mijamy jakiś mostek ze strumykiem - nie ma sensu pakować tam wody z Crysis na v.high*. skoro widzimy to tylko przez chwilę. Podobnie demo RE5 - woda na poziomie PS 1.3-1.4 - ale to nie gra o bitwach morskich, woda jest tylko w oddali, nie jest istotna.


*) pomijając fakt, że nie widziałem jeszcze strumyka na którym byłyby takie duże fale

PS miały być tylko "dodatkiem" i dopiero zaczyną się w tej roli sprawdzać. To, że w jakiejś grze będzie super woda, ale tylko do 100m od kamery i gdy w scenie nie ma prawie nic poza tym nie oznacza od razu, że już mamy erę shaderów.
Zresztą taki prosty przykład: GF3 - 1, GF4 -2, 9700 (chyba) 4, a 6800 nagle 16 i nazwy "potwór" w recenzjach. Kilka lat od ogłoszonej rewolucją premiery pierwszych kart z PS i... zobaczcie jak wyglądają cienie w Battlefield2. Aż przypominają się czasy 486, bo piksele jak cegły.

Jeśli połamałeś sobie oczy na tekście posta wyżej, to przepraszam - czasem piszę skrajnie wyczerpany/niewyspany (lub nietrzeźwy,ale to rzadziej), poprawiam na szybko i "shit happens"

  • Sprawdź bezpośredni link do posta

20.07.2009 23:11

Wątków: 1 | Odpowiedzi: 1682

Listingi gier z Bajtka

A pamiętacie listingi w Bajtku?

Pamiętam jak jako dzieciak przepisywałem jedną taką gierkę linijka po linijce (okolice 86/87). Miała być jakaś skacząca żaba czy coś takiego. Przepisywałem całkowicie bez zrozumienia licząc że uda mi się tą gierkę uruchomić... nie udało się. Ale pamiętam akcję przepisywania do dzisiaj

Czy było coś przed Bajtkiem?

20.07.2009 23:21

Wątków: 10 | Odpowiedzi: 6445

...

Nie, byl pierwszy

Nic dodać, nic ująć... jestem boski! :-)

  • Sprawdź bezpośredni link do posta

20.07.2009 23:24

Wątków: 1341 | Odpowiedzi: 41670

arval

przed Bajtkiem było Domowe Przedszkole. W moim wypadku przynajmniej.

Ja przepisywałem z Tajemnic Atari - cały dzień wspólnie z bratem.
Miała to być gra "Pustynna Burza".

i na zmianę pisanie/dyktowanie:

-DATA... jeden, cztery, zero, zero, osiem, sześć, trzy, trzy, trzy, czte..
- ile tych trójek?
- trzy
- ok
- dalej: cztery, siedem.


I tak pół dnia.

Oczywiście nie zadziałało. "Error ...." . Ale już wtedy "wymiataliśmy" bo po kursie to potrafiliśmy zgrać to co wklepaliśmy na kasetę i biegiem z tym do naszego "guru". Skubaniec w 5 minut to uruchomił.
Radość była tak wielka że przyćmiła niemal doła jaki nas czekał po zobaczeniu jak wspaniała, piękna i grywalna owa gra była.

Jeśli połamałeś sobie oczy na tekście posta wyżej, to przepraszam - czasem piszę skrajnie wyczerpany/niewyspany (lub nietrzeźwy,ale to rzadziej), poprawiam na szybko i "shit happens"

  • Sprawdź bezpośredni link do posta

20.07.2009 23:37

Wątków: 1 | Odpowiedzi: 1682

@Ronson

Przypomniałem sobie przy okazji najlepszą grę w jaką wtedy grałem (C16).

Nazywało się to 'Spekulant'. Taki polski pierwowzór Frontira Tyle że zamiast planet były miasta: Wrocław, Katowice... a zamiast piratów 'Milicja Obywatelska'. Kupowało się coś na czarnym rynku i jechało do drugiego miasta pociągiem by to sprzedać. Zmienna ilość towarów, ceny... wszystko było super zrobione. A jak jeździłeś z dużą ilością towaru pociągiem to ryzykowałeś spotkanie z MO i więzienie na 'handel i spekulanctwo'

  • Sprawdź bezpośredni link do posta

21.07.2009 00:15

Wątków: 3 | Odpowiedzi: 345

@Ronson

Źle rozumiesz czym są shadery. Shadery to są programy, które wykonują się w karcie graficznej. Im nowsze tym mają więcej ciekawych instrukcji, które dają większe możliwości oraz możliwość zrobienia tego samego co wcześniej ale szybciej Od wielu lat nie istnieje gra, która nie używałaby shaderów. Wszystkie piksele na ekranie są rysowane za pomocą shaderów. Także pulpit Aero w Vista to też jest 100% praca shaderów. Narysowanie białego trójkąta można zrobić shaderem lub za pomocą wbudowanej funkcji. Dzisiaj robi się to tylko i wyłącznie shaderem. Po jakości wody nie da się poznać wersji shadera bo jakość tego co widać na ekranie zależy od tego jaki efekt chce uzyskać programista. Biała plamka może być też zrobiona shaderami 5.0. Dzisiaj silniki zwykle mają dynamicznie tworzone shadery w zależności od wielu parametrów jakie może ustawić artysta.

Cienie w grach oraz inne efekty to też inny problem. Otóż techniki robienia cieni i wielu innych rzeczy są w USA opatentowane. W ogóle całe programowanie tam jest opatentowane. Nie można tak sobie zrobić ładnych cieni albo ładnego FSAA itp. Wydawcy zwykle życzą sobie pogorszenie wielu efektów ponieważ nie mają na nie patentów. Zwłaszcza ci mniejsi. Niestety w USA rynek oprogramowania został zmonopolizowany przez wielkie korporacje, które trzymają go właśnie za pomocą patentów. Żaden nowy mały wydawca nie ma tam szans bo zostanie zniszczony patentami. Musiałby wykupić tysiące lub dziesiątki tysięcy patentów a to się nikomu nie opłaci. Więksi wydawcy mają umowy między sobą, że nie będą ich stosować lub stać ich na taki zakup od czasu do czasu.
Nawet Carmack, który zrobił ciekawy algorytm cieni i zastosował go w Doom3 był szantażowany przez Creative, które ten algorytm opatentowało. Carmack nie wiedział co robi jak publicznie ogłosił ten algorytm nie patentując go samemu. Zamiast opłaty Carmack zgodził się (nie miał wyjścia) na stosowanie we wszystkich grach tylko i wyłącznie biblioteki OpenAL z efaktami EAX dla kart Creative aby pokazać moc tych kart.

http://grypa666.wordpress.com

21.07.2009 09:24

Wątków: 112 | Odpowiedzi: 5866

123

Spuki, pierwsze Voodoo pozwalalo na zmiane rozdzielczosci - 512x384, 640x480 i 800x600 (po wylaczeniu bufora z, np. w Tomb Raider 2 mozna bylo ten myk wykonac)

.:: only happy when it rains ::. .:: x360 gamertag: n0onePL ::.

21.07.2009 09:39

Wątków: 498 | Odpowiedzi: 8013

Zgadza się ale

wtedy zawsze coś nie tak było z obrazem, wydaje mi sie że powinniśmy umowić sie, ze jest tylko jedna natywna rozdzielczość (dla voodoo). Pet mam pytanko, czy niektóre figury takie jak sześcian, walec itp, nie są sprzętowo zaszyte w instrukcjach karty? Wydawalo mi sie że niektóre kształt są dostępne bez odwoływania sie do zaawansowanych funkcji (pewnie sie myle, ale jestem ciekaw). Z tego co pamietam podobna sprawa była z kompresją s3tc, która stał sie po prostu tc, z powodu przepychanek patentowych i chęci właczenia ich do pakietu direct duzy wkład s3 w polepszenie wydajności wyświetlania tekstur). i tu kolejne pytanie na temat shaderowych funkcji pet to co ty mówisz chyba odnosi sie do opengl, bo przecież wszystkie funkcje realizowania obrazu w dx są dostępne w sdk, czy coś mylę?

całe życie człowiek uczy się na błędach, swoich, powielając błędy innych.

21.07.2009 09:40

Wątków: 737 | Odpowiedzi: 41186

kiedys sie troszke bawilem openGL

i z tego co pamietam oprocz takich podstawowych ksztaftow byl tam jeszcze.... czajnik Slynny teapot, ktory byl pierwszym chyba obrazem 3d uzyskanym na kompie

Rzadko inteligencja idzie w parze z urodą ale u mnie tak się jakoś złożylo

  • Sprawdź bezpośredni link do posta

21.07.2009 10:02

Wątków: 1341 | Odpowiedzi: 41670

pet

"Źle rozumiesz czym są shadery."
Może nie tak dobrze jak Ty, bo nie jestem programistą, ale do "źle" mi chyba dość daleko.

Nie chodzi mi o to, że woda w GRID czy RE5 jest robiona shaderem 1.3
Chodzi mi o to, że jest na poziomie 1.3 - czyli developer miał tak niską wydajność w danym miejscu do dyspozycji, że tylko coś co przypomina zamierzchłe czasy się tak dało upchać.

O patentach na cienie nie wiedziałem i nigdy bym o tym nie pomyślał. Co za beton.

Co do tego, że wszystko jest na shaderach - no tak, po wyłączeniu postprocessu i zjechaniu z cieniami i shaderami z max na medium w Crysis:Warhead nagle mam 3x tyle klatek. Na moje to jest to idiotyzm, że coś co miało być dodatkiem nadal, po tylu latach jest kulą u nogi.
OK, można dzięki shaderom zrobić więcej. Ale przecież gdyby nie fakt, że 3/4 tranzystorów w GPU zjadają shadery to o 4x więcej by się tam zmieściło potoków renderujących i teksturujących. Analogicznie w engine'ach gier.
Dla mnie lepiej jak jest płynniej, większy zasięg widzenia, mniej rozmytych tekstur niż odwrotnie, ale z przepalonym obrazem (HDRy) czy super cieniami. To ciut nie idzie równo ze sprzętem. Kiedyś ATI powiedziało, że nie zrobiło SM3.0 w X800 bo te karty są na to za słabe. I chyba mieli rację, skoro na 20x szybszej (patrząc na shadery) obecnej generacji nadal włączenie HDRów czy lepszych cieni kładzie kartę graficzną...
Np. taki GRID. Na kartach z 48 shaderami w porównaniu do 16tu w 6800 (licząc też taktowanie) czyli 7900gtx odpalam sobie gierkę -GRIDa, która z shaderów ma tylko takie pierdoły jak lepsze cienie (szczegół w wyścigach), beznadziejny HDR i rozmycia... czyli coś co powinno być drobnym dodatkiem. Ale nie jest, bo jak to wyłączę/zmniejszę to gra chodzi 3x tak szybko. Czy lepiej wygląda czy gorzej to już kwestia indywidualna (IMHO lepiej, ale ja nie lubię HDRów i blurrów). Ale jak to jest, że na karcie która ma 3x tyle ile karta okrzyknięta "przełomem i potworem w kwestii shaderów" sobie z tym nie radzi...
I ten problem jest do dziś. Seria Nvidii 88xx i ATI 48xx to postęp w tej dziedzinie ogromny a... nadal spadek wydajności jest znaczny.
Moda i programiści zdają się być ciągle o 5 lat przed sprzętem.
I ciągle na ekranie mam kanciaste figury, mały zasięg widzenia i rozmyte tekstury, ale za to piasek i fartuch baby w AOEIII świeci jakby był chromowany, twarze w RE5 wyglądają jak z podziurawionego metalu, a w co drugiej grze mam szaroburo i 3/4 obrazu to biała plama, bo przecież musi być HDR i blur...

Jeśli połamałeś sobie oczy na tekście posta wyżej, to przepraszam - czasem piszę skrajnie wyczerpany/niewyspany (lub nietrzeźwy,ale to rzadziej), poprawiam na szybko i "shit happens"

21.07.2009 10:50

Wątków: 6 | Odpowiedzi: 3391

no

fakt ze z HDR to ostro wszyscy przeginaja - nie da sie czasami patrzec na to. Ale cienie dodaja duzo realizmu.

  • Sprawdź bezpośredni link do posta

21.07.2009 11:03

Wątków: 1341 | Odpowiedzi: 41670

hehehe



http://www.wykop.pl/ramka/212939/directx-10-10-1-11-co-w-trawie-...
Ten art wleciał na Wykop.pl
Teraz masa ludzi będzie mogła poczytać kto jaką kartę miał sto lat temu

Jeśli połamałeś sobie oczy na tekście posta wyżej, to przepraszam - czasem piszę skrajnie wyczerpany/niewyspany (lub nietrzeźwy,ale to rzadziej), poprawiam na szybko i "shit happens"

  • Sprawdź bezpośredni link do posta

21.07.2009 11:09

Wątków: 3 | Odpowiedzi: 345

@Spuki

To co piszę odnosi do DirectX i do OpenGL. Są w SDK podstawowe funkcje generowania obrazu ale nikt od dawna ich nie używa bo mają małe możliwości. Są na poziomie DirectX 7. A karty dzisiaj i tak je muszą tłumaczyć na shadery bo karty od kilku lat nie mają już wbudowanych funkcji.
Te podstawowe kształty (prostokąt, cylinder, sfera, czajnik itp.) ciągle są w bibliotece directx. Ale to polega tylko na tym, że są to funkcje tworzące obiekt (bufor wierzchołków) o danym kształcie. To tylko takie ułatwienie dla programisty aby natychmiast stworzyć obiekt o podstawowym kształcie. Dokładnie na to samo wychodzi wczytanie wcześniej stworzonych danych, np. w 3dstudio, takiego obiektu z dysku. Do pamięci karty można wczytać dowolny obiekt. Nawet gigantyczny z milionami wierzchołków. A potem można go narysować wielokrotnie za pomocą jednej instrukcji. Oczywiście rysuje Pixel Shader, wspomagany obliczeniami z Vertex Shadera. Zwykle do Vertex Shadera podaje się pozycję obiektu w przestrzeni, obrót i skalę. Te parametry podaje się za pomocą odpowiednich macierzy. A te 3 macierze mnoży się przez siebie otrzymując jedną zwaną macierzą świata. Do tego jest jeszcze macierz widoku z przekształceniem kamery i macierz projekcji, która ustala rodzaj perspektywy i obcinanie z przodu i z tyłu(gdzie horyzont). Te macierze podaje się jako parametry do Vertex Shadera, który przekształca nimi wierzchołki obiektów. W samych wierzchołkach oprócz ich pozycji można trzymać też inne dane, np. ich kolor. Sami ustalamy jakie dane mają być potem podane do Pixel Shadera i co ma on robić. Może rysować tylko kolorem interpolowanym z wierzchołków. A może brać np. dodatkowo źródła światła też podane za pomocą parametrów i odpowiednio cieniować trójkąty. Albo nakładać tekstury lub robić bump mapping. Możliwości są nieskończone bo Vertex Shader i Pixel Shader to są zwykłe programy, które pisze się samemu. Ten model co podałem to tylko przykład i każdy może od zera samemu swój wymyśleć. To czysta matematyka. Większość programistów tylko powiela stare schematy - używa stare sprawdzone programy shaderów. Znaleźć takiego co umie pisać własne to już nie jest łatwo no i trzeba mu płacić o wiele więcej.

@Ronson
Pisząc shader trzeba robić to tak aby wykorzystać to, że GPU może robić wiele obliczeń jednocześnie. Czyli trzeba go odpowiednio optymalizować. Nawet prymitywna woda może być wolniejsza od takiej najładniejszej.
Nie dziwne, że ci przyspiesza jak wyłączasz efekty. Przecież GPU ma wtedy mniej roboty. Wyobraź sobie, że aby zrobić taki ładny wolumeryczny cień to trzeba od źródła światła wystrzelić tysiące promieni i patrzeć z czym to się przetnie. To jest dosłownie raytracing więc nie dziwne, że obciąża. Oczywiście to tylko przykład bo jest dużo technik. Jak pisałem shader to tylko program więc sam możesz wymyśleć lepszy, chętnie zobaczę
Efekty HDR(bloom, lens flare, star, korekcje gamma i koloru, motion blur, Depth of Field i inne) to jak pisałeś postproces. Przetwarza każdą ramkę, każdy piksel wiele razy na buforze zwykle 16 bitowym fp. Też bardzo obciąża ale też bardzo ułatwia. Kiedyś te efekty robiło się inaczej a teraz jest o wiele prościej Shader korzysta, ze wszystkiego co jest na karcie. Czyli jak wykonujesz jakieś operacje arytmetyczne to korzysta z jednostek ALU, jeśli odwołuje się do tekstur to pracują jednostki teksturujące. Zależnie ile czego GPU ma i jak to jest połączone oraz jak jest napisany shader to tak szybko to działa.

http://grypa666.wordpress.com

21.07.2009 11:38

Wątków: 498 | Odpowiedzi: 8013

Z tego co wiem prawda jest taka, że

nie liczy się ilosć detali na scenie ale realistyczne oświetlenie i cienie, co czyni obraz realistyczniejszym. Ilość klatek bez shaderów wzrata bo jak mówił przemdówca karta sie wtedy nie wysila, szczególnie jak większosc ukladów zajmują teraz wyspecjalizowane jednostki do obliczen na pixelach. W tej chwili bez problemu realizuje sie cieniowanie phonga (nadal jest ono mocno obciążajace), gdzie kiedyś ze względu na wydajnosć nie było o tym mowy.

całe życie człowiek uczy się na błędach, swoich, powielając błędy innych.

21.07.2009 14:30

Wątków: 0 | Odpowiedzi: 1

dx11 a CUDA

,,Pojawienie się Compute Shadera w DX 11 (...) 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.''

Autor nie zauważył, że mimo, iż w tym zdani ma na myśli jednego producenta sprzętu, to cały czas w artykule pisze wyłącznie o jednym producencie systemu. Tymczasem Nvidia produkuje doskonałe sterowniki i SDK pod linuxa, który z kolei daje się łatwiej łączyć w klastry. Dzięki temu na polu obliczeń inżynierskich i naukowych CUDA się spokojnie utrzyma.

A fizyka do gierek istotnie może być wygodniejsza do zaimplementowania w tym samym API w którym koduje się resztę grafiki.

Drwal Drzewny.

  • Sprawdź bezpośredni link do posta

21.07.2009 19:58

Wątków: 3 | Odpowiedzi: 345

@Spuki

"Ilość klatek bez shaderów wzrasta..." - Zawsze każda praca kosztuje. I nie powinieneś tak pisać bo bez shaderów to nic by nie było widać na ekranie Sztywne specjalizowane funkcje nie są szybsze bo są zbyt uniwersalne. Shader można napisać sobie prostszy i bardziej przystosowany do danego zadania i zawsze będzie to szybsze. Nie mówiąc o tym, że można sobie zrobić efekty, które nie istnieją w funkcjach wbudowanych. Nawet takie, których nikt jeszcze nigdy nie widział Cieniowanie Phonga jest od dawna w każdej grze i to akurat już nie jest wyzwaniem dla dzisiejszych GPU.
"większosc ukladów zajmują teraz wyspecjalizowane jednostki do obliczen na pixelach" - tzn. specjalizowane jednostki zostały wycięte właśnie po to aby zrobić więcej miejsca na shadery, które są uniwersalnymi jednostkami No i całą infrastrukturę je wspomagającą. A teraz to są zunifikowane shadery, które mogą być albo pixel shaderem albo vertex shaderem. Do tego geometry shader czy inne nowe, które będą w dx11. Dzisiaj nawet pulpit 2D windowsa czy linuksa jest w rzeczywistości robiony shaderami. Dekodowanie i kodowanie wideo, które kiedyś było specjalizowaną funkcją to dzisiaj również jest robione shaderami. Jak pisałem wcześniej - dzisiaj nawet piksela się nie stawia bez shadera.

http://grypa666.wordpress.com

21.07.2009 20:59

Wątków: 153 | Odpowiedzi: 0

[Ciach]

[WypowiedŸ usunięta przez moderatora z powodu niezgodnoœci z regulaminem, mieszczšcym się pod tym adresem ]

CoreQuad 2,8ghz , Asus Striker II Nse , 4 GB ram OCZ , Evga GTX 280 :)

Aby dodać odpowiedź zaloguj się.