3DMark 2005

autor mójxxx323, Listopada 09 2009. Opublikowane w Moduły cieniujące DirectX 9.0b-9.0c w wersji 2.0b

Rok produkcji: 2006
Deweloper: Futuremark Corporation
Platforma: PC
Minimalne wymagania systemowe:
System operacyjny: system operacyjny Microsoft Windows 2000 lub XP
Procesor: procesor zgodny z x86 z obsługą MMX, 2000 MHz
RAM: (zalecane 512 MB)
DIRECTX: DirectX9.0c lub nowszy (wymagane)

DirectX9 i modele shaderów

W miarę ewolucji funkcjonalności procesorów graficznych programiści muszą wykorzystywać ich dodatkowe możliwości, aby zarówno poprawić jakość scen, jak i uzyskać dodatkową wydajność.
Firma Microsoft, twórca DirectX, wykazała się niezwykłą elastycznością, umożliwiając dwóm wiodącym twórcom procesorów graficznych stworzenie zestawu modeli modułów cieniujących, które wykorzystują zaawansowaną funkcjonalność procesora graficznego wykraczającą poza podstawowe wymagania modelu modułu cieniującego 2.0. Branża potrzebowała ujednoliconego podejścia do rozszerzania podstawowych możliwości DirectX 9, w wyniku czego powstały Shader Model 2.0a, Shader Model 2.0b i Shader Model 3.0.

Na przykład w Far Cry Przy obliczaniu oświetlenia przy użyciu modułu cieniującego piksele model 3.0 w jednym przebiegu obliczane są maksymalnie 4 źródła światła, przy zastosowaniu modelu 2.0b - dla 3, przy zastosowaniu modelu 2.0 - na jedno źródło światła.

Tak więc, wraz z przejściem gier na nowy sposób rozwoju, pojawiło się nowe podejście do oceny wydajności: zamiast testować karty graficzne w absolutnie identycznych warunkach, konieczne jest użycie dla każdego konkretnego akceleratora modelu modułu cieniującego, który w pełni wykorzystuje jego możliwości. Dokładnie tak twórcy z Futuremark widzieli 3Mark05.

3DMark05: etapy podróży

Futuremark, nazywając swoje zestawy testowe „The Gamer's Benchmark”, stale dodaje wsparcie dla nowych technologii i rozwija funkcjonalność swojego 3DMark. Wprowadzone po raz pierwszy pod koniec 1998 roku zestawy testów porównawczych Futuremark stały się popularnym narzędziem do pomiaru wydajności kart graficznych i bilansu mocy zarówno dla ludzi, od entuzjastów po kadrę kierowniczą korporacji.

3DMark99 - skupiono się na szybkości teksturowania i przetwarzaniu wielokątów.
3DMark2000 - otrzymało wsparcie dla sprzętowej transformacji wielokątów, a jednocześnie wzrosła złożoność scen.
3DMark2001 - otrzymało wsparcie dla shaderów wierzchołków i pikseli 1.1 oraz dodatkowo zwiększyło złożoność scen - teraz w scenach było już kilkadziesiąt tysięcy wielokątów.
3DMark03 - używane shadery 1.x i 2.0. Tylko w jednym z testów gry w ogóle nie wykorzystano shaderów pikseli. Wszystkie pozostałe testy gier w dużym stopniu wykorzystywały moduły cieniujące pikseli i wierzchołków DirectX8, a ostatni i najbardziej złożony test gier w dużym stopniu wykorzystywał moduły cieniujące Modelu 2.0. Złożoność scen wzrosła do setek tysięcy wielokątów.
3DMark05 - podniósł poziom technologii jeszcze wyżej. Pakiet korzysta wyłącznie z shaderów modelu 2.0 i wyższych, a wszystkie shadery można uruchomić w dowolnym z profili odpowiadających modelom 2.0, 2.0a, 2.0b i 3.0. Wzrosła złożoność scen: teraz w ramce może znajdować się średnio ponad milion wielokątów.

Główną różnicą pomiędzy 3DMark05 a poprzednimi wersjami pakietu testowego jest zastosowanie shaderów co najmniej modelu 2.0 i wybór optymalnej ścieżki renderowania dla każdej karty graficznej.
Patric Ojala z Futuremark podaje taki przykład: „Używamy kilku specjalnie przygotowanych shaderów, przykładowo w pierwszym teście gry shader odpowiadający modelowi 3.0 wykorzystuje dynamiczną kontrolę wykonania i przestaje działać, gdy wykryje, że powierzchnia nie jest oświetlona. Innym przykładem może być moduł cieniujący wykorzystujący tekstury szablonu głębi.

Silnik graficzny: użycie shaderów

Poprzednie wcielenia 3DMark firmy Futuremark wykorzystywały zmodyfikowane wersje MAX-FX, ale w przypadku 3DMark05 firma opracowała nowy silnik graficzny. Wszystkie shadery użyte w scenach są napisane w języku wysokiego poziomu - HLSL. Shadery te nie są wykonywane bezpośrednio; przed wysłaniem ich do akceleratora należy je skompilować, czyli przetłumaczyć na język bardziej zrozumiały dla procesora graficznego i jego sterownika. DirectX oferuje kilka profili - kilka optymalnych konfiguracji dla kompilatora modułu cieniującego, zaprojektowanych dla procesorów graficznych o różnej funkcjonalności. Tak więc, powiedzmy, dla ATI RADEON 9700 PRO będzie używany profil PS 2_0/ VS 2_0, a dla NVIDIA GeForce 6800 Ultra – PS 3_0/VS 3_0. Najnowsza generacja procesorów graficznych przekracza podstawowe wymagania DirectX 9.0 i chociaż obsługują niższe profile, powiedzmy, PS 2_0/VS 2_0, domyślnie będą korzystać z profilu, który najlepiej wykorzystuje ich funkcjonalność. To samo dotyczy procesorów graficznych, które pojawią się po wydaniu 3DMark05 - dla nich na podstawie listy obowiązkowych możliwości udostępnianych przez sterowniki zostaną wybrane profile, które najpełniej wykorzystują ich funkcjonalność.

Tak więc w nowym wcieleniu pakietu testowego Futuremark jeszcze bardziej odchodzi od pomysłu porównywania kart graficznych w absolutnie identycznych warunkach. Nie jest to zaskakujące: wszystkie nowoczesne karty graficzne obsługują podstawowe wymagania DirectX 9.0, ale ponad podstawowymi wymaganiami mają zupełnie inną funkcjonalność. Niewłaściwe jest umieszczanie ich w tych samych warunkach: te same warunki w różnych przypadkach będą optymalne dla niektórych kart graficznych i nieoptymalne dla innych. W zamian za to wszystko 3DMark05 wybierając najbardziej funkcjonalne profile dla każdego GPU, maksymalnie wykorzystuje możliwości każdej karty graficznej.
Jednak dla tych, którzy nadal są zainteresowani porównaniem wydajności kart graficznych w tych samych warunkach, wprowadzono możliwość wyboru profilu do kompilacji shaderów HLSL. W ten sposób możesz zmusić kartę graficzną do pracy z mniej funkcjonalnym profilem, powiedzmy NVIDIA GeForce 6800 Ultra nie będzie korzystać z shaderów 3.0, ale prędkość renderowania scen oczywiście ulegnie zmianie.

Silnik graficzny: użycie procesora

W testach gier nowy pakiet Futuremark nie wykorzystuje zasobów procesora do niczego innego niż przygotowanie danych do zbudowania sceny. Oznacza to, że w testach gier nie ma żadnych obliczeń związanych z fizyką, logiką lub sztuczną inteligencją gier.
Większość testów wbudowanych w zwykłe gry zorganizowana jest w ten sam sposób: podczas grania w wersję demonstracyjną nagrywa się i mierzy prędkość, oblicza sztuczną inteligencję, fizykę itp. wyłącza. Na przykład w Doom3 wbudowany test jest zorganizowany w ten sposób.
Tak więc, jeśli chodzi o wykorzystanie zasobów procesora w testach gier, programiści Futuremark próbowali zbliżyć się do prawdziwych testów gier i takie podejście wydaje się całkiem uzasadnione, ponieważ 3DMark to przede wszystkim test kart graficznych, a nie centralny procesory.

Silnik graficzny: system obliczania cieni

W scenach 3DMark 2001 pojawiły się dynamiczne cienie - silnik korzystał z rzutowanych map cieni. W 3DMark03, w drugim i trzecim teście, silnik graficzny przełączył się na inny sposób konstruowania cieni, ten sam, którego używał „wielki i straszny” Doom3 – obliczanie objętości ograniczających zacienione obszary i używanie bufora szablonu do określenia oświetlenia obiektów.
W 3DMark05 twórcy odeszli od tej metody obliczania cieni - zapewniając doskonałą jakość, ma ona jednak szereg wad. Dla każdego obiektu, który powinien rzucać cień, należy utworzyć jego „objętość cienia” - model wielokątny, którego krawędzie od strony źródła światła są krawędziami samego obiektu, a po bokach - sylwetka obiekt rozciągał się od źródła światła do nieskończoności. Znalezienie krawędzi tworzących sylwetkę obiektu podlegających wyciskaniu jest trudnym zadaniem realizowanym przez centralny procesor, a im obiekt jest bardziej skomplikowany, czyli im więcej wielokątów uwzględniono w obliczeniach, tym więcej czasu potrzeba na utworzenie „objętość cienia”.
Dalsze wykorzystanie tych niewidocznych „woluminów cienia” wiąże się z koniecznością renderowania ich do bufora szablonu, co znacznie zwiększa obciążenie procesora graficznego pod względem szybkości cieniowania. Im więcej obiektów rzuca cienie, tym większe obciążenie procesora graficznego.

Metoda obliczania cienia zastosowana w 3DMark05 jest wolna od tych niedociągnięć. 3DMark05 wykorzystuje rodzaj mapy cieni zwanej „perspektywą mapy cieni” (PSM) do obliczania dynamicznych cieni, z własnymi modyfikacjami, aby zminimalizować przejawy ich charakterystycznych wad.
Podczas obliczania cieni dynamicznych za pomocą mapy cieni etapy budowania sceny wyglądają mniej więcej tak:

-Najpierw scena jest budowana z pozycji źródła światła. Podczas budowy nie są używane żadne tekstury, shadery pikseli itp., ponieważ na tym etapie potrzebna jest jedynie wartość Z, czyli odległość pikseli sceny od źródła światła. Ta wartość dla każdego piksela jest zapisywana w buforze wyjściowym w formacie zmiennoprzecinkowym. Im większy rozmiar tego bufora i im dokładniejszy format prezentacji danych, tym lepszy będzie wynik.
-Po obliczeniu mapy cieni scena jest konstruowana w zwykły sposób, z pozycji kamery. Aby określić oświetlenie pikseli, stosuje się shadery pikseli: w shaderze dla każdego piksela w scenie wyznaczany jest odpowiedni piksel mapy cieni i obliczana jest odległość piksela sceny od źródła światła. Jeśli odległość ta jest równa lub mniejsza od wartości zapisanej na mapie cieni, wówczas piksel zostaje oświetlony. Jeśli ta odległość jest większa, oczywiste jest, że przy obliczaniu mapy cieni jakiś element sceny okazał się bliżej źródła światła, a piksel okazał się zacieniony.

Główną zaletą obliczania cieni za pomocą PSM jest to, że obliczanie cieni dynamicznych przy użyciu map cieni nie wymaga dodatkowych obliczeń przez centralny procesor, a liczba obliczeń nie jest zależna od złożoności sceny - niewidoczny, ale zasobożerny „cień” tomy” nie są dodawane.
Nowoczesne procesory pikselowe obsługują długie i złożone shadery, co pozwala określić zacienienie każdego piksela w stosunku do kilku źródeł światła w jednym przebiegu, czyli jeszcze bardziej zmniejszyć ilość pracy.
Dodatkowo, metoda ta wykorzystuje procesory pikselowe i to właśnie ich wydajność rośnie ostatnio najszybciej – szybciej niż moc procesorów wierzchołkowych, wydajność procesora, szybkość magistrali pamięci czy prędkość pobierania tekstur.

Ta metoda ma oczywiście swoje słabe strony, ale twórcy Futuremark zapewniają, że ich modyfikacja PSM dobrze nadaje się do szerokiej gamy scen i źródeł światła.
Mapy cieni dla kierunkowych źródeł światła obliczane są w rozdzielczości 2048x2048; mapy cieni zapisywane są w formacie zmiennoprzecinkowym, R32F lub D24X8. Dla tych świateł silnik graficzny oblicza dwie mapy cieni: jedną dla obiektów znajdujących się bliżej kamery, a drugą dla reszty sceny. Pozwala to uzyskać większą dokładność w obliczaniu cieni w tych miejscach, gdzie jest to najbardziej zauważalne, czyli blisko aparatu, przy jednoczesnym zachowaniu możliwości obliczania cieni dla reszty sceny. Jednak nawet to czasami nie wystarczy, aby całkowicie uniknąć pojawienia się artefaktów – w trzecim teście gry 3DMark05 artefakty cieniowania są zauważalne na fragmentach skał położonych niemal równolegle do promieni słonecznych.

Zwróć uwagę na cień rzucany przez kable w pobliżu „płetwy” latającego statku i fragment ściany kanionu.

Twórcy zauważają, że nie są to błędy sterowników ani problemy sprzętowe, jest to przejaw jednego ze słabych punktów metody mapy cieni.
W przypadku bezkierunkowych źródeł światła silnik graficzny 3DMark05 tworzy sześć map cieni w formacie R32F o wymiarach 512x512, umieszczając źródło światła w środku wyimaginowanego sześcianu, tworząc mapy cieni dla 6 ścian tego sześcianu, redukując w ten sposób ten przypadek do w przypadku kierunkowego źródła światła.

Próbkowanie wartości z mapy cieni w module cieniującym piksel w obecności sprzętowej obsługi filtrowania procentowego najbliższego (PCF) i tekstur szablonów głębokości (DST) odbywa się przy użyciu PCF, czyli w rzeczywistości przy zwykłym filtrowaniu dwuliniowym i jeśli nie ma sprzętowej obsługi PCF, filtrowanie odbywa się bezpośrednio w shaderze, w tym celu z mapy cieni wybierane są 4 wartości najbliższe punktowi odniesienia i uśredniane.
Podejścia te zapewniają nieco inne wyniki, zarówno pod względem wydajności, jak i jakości obrazu, ale programiści z Futuremark uważają, że w miarę możliwości należy używać DST i PCF, czyli sprzętowej obsługi i sprzętowego filtrowania map cieni, ponieważ większość głównych gier programiści już korzystają z tych funkcji GPU, a zapotrzebowanie na te funkcje będzie w przyszłości tylko rosło.

A więc dość szczegółów. Przejdźmy na koniec do opisu testów.

Test gry 1: Powrót do Proxycon:

Pierwszy test gry zdecydowanie należy do sekcji gier akcji: kosmiczni piraci ponownie atakują statek towarowy Proxycon.

Odzwierciedlając sceny z klasycznych strzelanek, Game Test 1: Return to Proxycon łączy w sobie dość duże pomieszczenia z wąskimi korytarzami i dużą liczbę jednocześnie walczących żołnierzy piechoty, przybliżając sytuację gry do gier wieloosobowych.

Większość powierzchni w teście gry 1: Powrót do Proxycon wykorzystuje „metaliczne” materiały zdefiniowane przez moduł cieniujący, a obliczenia oświetlenia opierają się na modelu Blinna-Phonga. Wykładniki wymagane do obliczeń nie są obliczane matematycznie w modułach cieniujących; zamiast tego używane są próbki z wstępnie obliczonej tabeli.
W sumie scena posiada 8 źródeł światła rzucających cienie: 2 kierunkowe źródła światła, dla których obliczane są mapy cieni o wymiarach 2048x2048 oraz sześć źródeł bezkierunkowych, dla których obliczane są mapy cieni o wymiarach 512x512x6.

Test gry 2: Las świetlików:

Ten test jest dobrym przykładem sceny plenerowej z dużą ilością roślinności. Scena jest stosunkowo niewielka, ale niezwykle bogata w szczegóły.
Noc księżycowa. Ziemię porasta gęsta trawa, gałęzie drzew lekko kołyszą się na lekkim wietrze...

Wyświetlanie gęstej roślinności na ziemi realizowane jest w sposób dynamiczny: stężenie i poziom szczegółowości roślinności naziemnej zmienia się wraz z ruchem kamery. Liście trawy są wyświetlane tylko tam, gdzie jest to potrzebne, co zmniejsza obciążenie procesora graficznego przy jednoczesnym zachowaniu najwyższych wrażeń wizualnych. 

Powierzchnia podłoża w tym teście jest renderowana przy użyciu „metalowego” modułu cieniującego z pierwszego testu, ale z dodatkiem podstawowych i szczegółowych map kolorów/normalnych. Materiał gałęzi drzewa nie wykorzystuje map wypukłości ani odblasków, ale ma mapę kolorów sześcianu. Niebo jest renderowane przy użyciu modułu cieniującego symulującego rozpraszanie światła.
Światło księżyca to kierunkowe źródło światła, które rzuca dynamiczne cienie. Cienie obliczane są przy użyciu mapy cieni o rozdzielczości 2048x2048. Magiczny świetlik oświetla trawę i drzewa jako dookólne źródło światła za pomocą mapy sześcianu cieni o wymiarach 512x512x6.

Test gry 3: Lot nad kanionem:

Najnowszy test gry obejmuje duże otwarte przestrzenie – w tej scenie latający statek Juliusza Verne’a płynie po falach przez kanion strzeżony przez prawdziwego morskiego diabła.

Powierzchnia wody jest najbardziej uderzającą częścią tej sceny. Woda nie tylko imituje odbicia i załamania światła, ale ma także swoją przezroczystość, dzięki czemu potwór morski poruszający się w słupie wody sprawia wrażenie, jakby rzeczywiście pływał w słupie wody, a nie za zmętniałym szkłem refrakcyjnym.
Shader używany do wyświetlania powierzchni wody jest ulepszoną modyfikacją shadera „wody” z 3DMark03, ale powierzchnia wody to nie tylko shader. Aby poprawnie obliczyć załamania i odbicia, w tym prawidłowe wyświetlanie cieni, wymagane jest sześć przebiegów akceleratora graficznego. Sam moduł cieniujący wykorzystuje odczyty z map normalnych, załamań i odbić. Ponadto w przypadku obiektów pod wodą stosowana jest mgła wolumetryczna, dzięki czemu stają się one ciemniejsze i mniej nasycone w miarę oddalania się głębiej od powierzchni wody.

W scenie wykorzystano mgłę, aby podkreślić obecność dużej otwartej przestrzeni, dzięki czemu odległe skały wyglądają bardziej naturalnie.

Shader używany do renderowania skał jest tym, co twórcy nazywają najbardziej złożonym shaderem 3DMark05 - w połączeniu z obliczeniami cieni ledwo mieści się w specyfikacji shaderów pikseli model 2.0. Materiał skalny wykorzystuje dwie podstawowe tekstury, dwie mapy normalnych i obliczenia oświetlenia Lamberta.
Scena ma jedno źródło światła – Słońce. Cienie słońca obliczane są przy użyciu dwóch map cieni o rozdzielczości 2048x2048, jedna mapa wykorzystywana jest dla obiektów znajdujących się blisko kamery, a druga dla reszty sceny.

 Test procesora:

3DMark05, podobnie jak 3DMark03, wykorzystuje testy gier w rozdzielczości 640x480 z wyłączonymi efektami końcowymi i z programową emulacją shaderów wierzchołków w celu przetestowania szybkości centralnego procesora. To przesuwa równowagę testów w kierunku zwiększenia obciążenia procesora centralnego i uzależnia wyniki testów od szybkości procesora centralnego, a nie karty graficznej. Aby mieć pewność, że testy przebiegają w dokładnie takich samych warunkach na każdym systemie, oba testy procesora korzystają z trybu wyjściowego sceny ze stałą liczbą klatek na sekundę.

W pierwszym teście procesora twórcy wprowadzili dodatkowe obliczenia przypisane do procesora centralnego. Pomimo tego, że lot statku przez kanion w każdych warunkach odbywa się po stałej trajektorii, test ten obejmuje ciągłe obliczanie optymalnej trajektorii omijającej kontury kanionu. Obliczenia związane z tym obliczeniem wykonywane są w pobocznym wątku, co pozwala na wykorzystanie możliwości wieloprocesorów lub procesorów z HyperThreading.

Współczynnik wypełnienia :

Test ten został przeniesiony do 3DMark05 praktycznie bez zmian. Wszystko, co się zmieniło, jest widoczne gołym okiem: aby zmniejszyć wymagania dotyczące przepustowości pamięci i podkreślić prędkość teksturowania, twórcy maksymalnie zmniejszyli rozdzielczość używanych tekstur - teraz są to nudne „komórki”.

Test jak zwykle ma dwa tryby: nakładanie pojedynczej tekstury i wieloteksturowanie. W trybie nakładania pojedynczej tekstury scena ma 64 powierzchnie z jedną warstwą tekstury na każdej, a w trybie wielu tekstur ma 8 powierzchni z ośmioma teksturami na każdej.

Moduł cieniujący pikseli:

W tym teście wykorzystano najbardziej złożony moduł cieniujący 3DMark05, moduł cieniujący powierzchni skalnej z trzeciego testu gier. Shader został przeniesiony z testu gry z jedną tylko zmianą – cienie nie są tutaj obliczane.

Warto przypomnieć, że shader jest napisany w HLSL; podstawowe wymagania dla GPU, podobnie jak wszystkie inne testy 3DMark05, obejmują obsługę shaderów modelu 2.0.

Twórcy zauważają, że o wynikach tego testu zadecyduje nie tylko wydajność procesorów pikselowych, ale także szybkość magistrali pamięci - ten shader intensywnie wykorzystuje tekstury o dużej objętości.
Mniej zależną od szybkości pamięci alternatywę dla takiego modułu cieniującego, programiści widzą moduł cieniujący, który wykorzystuje obliczenia matematyczne, czyli „tworzy tekstury w locie”, ale po pierwsze podobny moduł cieniujący był już używany w 3DMark03, a po drugie jak zauważa Futuremark, twórcy gier Zamiast obliczeń matematycznych w shaderach znacznie chętniej sięgają po zwykłe tekstury.

Vertex Shader:

Test składa się z dwóch części: w pierwszej mierzona jest szybkość prostej transformacji modeli potworów morskich – shader odpowiedzialny za transformację może z powodzeniem mieścić się w specyfikacjach shaderów modelu 1.0, jednak test, kierując się ideologią Futuremark, korzysta z DirectX 9.0.

Druga, bardziej złożona wersja testu wykorzystuje złożony moduł cieniujący wierzchołków do przekształcania źdźbeł trawy. Każde źdźbło trawy ugina się niezależnie od pozostałych pod wpływem „wiatru” generowanego przez szum fraktalny obliczany na centralnym procesorze. Aby ograniczyć wpływ takich czynników, jak wydajność procesora i szybkość cieniowania na wyniki testu, obliczenia szumu fraktalnego są maksymalnie zoptymalizowane, a źdźbła trawy znajdują się dalej od aparatu.

 Testy wielkości partii:

 Batch Size Tests – zestaw testów zaprojektowanych pod kątem szybkości renderowania wsadów o różnej wielkości – grup wielokątów wysyłanych przez aplikację do sterownika akceleratora w jednym wywołaniu funkcji Direct3D. Każdy z tych testów losuje tę samą liczbę wielokątów, ale za każdym razem są one grupowane w grupy o różnych rozmiarach: 8,32,128, 512, 2048 i 32768 wielokątów.
Aby zapobiec łączeniu przez sterowniki kart graficznych małych grup w większe w celach optymalizacji, każda początkowa grupa wielokątów jest rysowana własnym kolorem — powoduje to ponowne uruchomienie potoku graficznego po nadejściu każdej nowej grupy wielokątów:

Test pokazuje, o ile przeładowania potoku graficznego zmniejszają wydajność karty graficznej oraz pokazuje wydajność sterownika i karty graficznej w grupach o różnej wielkości - wiadomo, że wysłanie do akceleratora i narysowanie tej samej liczby wielokątów jednym wywołaniem funkcji a jedna grupa jest szybsza niż w przypadku wielu małych grup.

Każde z wcieleń 3DMarka rzuciło na kolana nowoczesne karty graficzne dzięki nowym technologiom i bardziej złożonym scenom, jednak nigdy wcześniej „nominałowi papugi” nie towarzyszył tak ogromny skok w jakości obrazu. Aby uzyskać maksymalne wrażenia i docenić nowe testy, trzeba oczywiście obejrzeć tryb demonstracyjny – każda scena gry w trybie demonstracyjnym to kompletne dzieło sztuki.

Warto zauważyć, że tym razem Futuremark wyraźnie dzieli sceny gier na gatunki, co widać już na pierwszy rzut oka po testach - powtórzyła się sytuacja z 3DMark03, gdzie drugi i trzeci test gier za inną powłoką wypadł w środku tak samo nie stało się. Każda scena w grze jest zupełnie inna i na pierwszy rzut oka powinna wyglądać tak, jakby całkiem dobrze odzwierciedlała sceny z gier z bliższej i dalszej przyszłości.
Warto zwrócić uwagę na nowe podejście Futuremark do testowania kart graficznych o różnej funkcjonalności – zastosowanie shaderów HLSL i własnego optymalnego profilu dla każdego procesora graficznego jest chyba najwłaściwszym odzwierciedleniem istniejących trendów w branży gier.