GeForce GTX 480 (Fermi) – nowa generacja kart graficznych NVIDI-i (w końcu!)

Nie trzeba chyba nikomu tłumaczyć, że budowa rdzenia układu graficznego znacznie różni się od budowy rdzenia zwykłego procesora x86. Różnice wynikają z tego, że oba układy wykonują zupełnie inny rodzaj zadań. Rdzeń procesora jest optymalizowany w ten sposób, aby jak najszybciej wykonać pojedynczy, dowolny wątek. Do tego potrzebuje bardzo dużo dodatkowych zasobów, takich jak mechanizmy przewidywania skoków, mechanizmy wstępnego pobierania do pamięci, dużo pamięci podręcznej. Te dodatkowe zasoby zabierają większą część powierzchni rdzenia i mają zapewnić jak najlepsze wykorzystanie jednostek wykonawczych zajmujących się skomplikowanymi, często bardzo zróżnicowanymi i nieprzewidywalnymi obliczeniami. W przypadku układów graficznych te rzeczy są niepotrzebne. Wykonywane obliczenia i w ogóle zadania stawiane przed układami graficznymi są stosunkowo proste, więc pojedynczy rdzeń potrzebuje bardzo niewiele do efektywnego wykonywania obliczeń. Dzięki temu takich bardzo małych „rdzeni” można umieścić w jednym układzie kilkadziesiąt, a nawet kilkaset (o ich liczbie i schematach nazewnictwa będzie trochę dalej). O ile wielowątkowość w używanych na co dzień aplikacjach, jak przeglądarka i klient poczty, jeszcze raczkuje, to grafika jest bardzo łatwa do zrównoleglenia. W końcu mamy do czynienia z milionami wielokątów, które trzeba przeprowadzić przez różne transformacje, i miliony pikseli, których ostateczny kolor trzeba policzyć, aby wyświetlić je na ekranie. Okazuje się jednak, że niektóre z tych „niezbędnych” elementów dodatkowo mogą być współdzielone przez części chipu zajmujące się obliczeniami. Tutaj do gry wchodzi SIMD, czyli możliwość równoległego wykonywania tej samej instrukcji na niezależnych od siebie danych. Po tym przydługim wstępie czas na pierwszy rysunek pokazujący architekturę GF100 (zastosowaną w opisywanym dzisiaj GeForsie GTX 480) i jej porównanie z architekturą GT200 (obecną w starszych GeForce'ach: GTX 260 i GTX 280).

Powyższy diagram jest bardzo ogólny i zawiera wiele uproszczeń (które czasem nie są do końca precyzyjne), aby nie przytłoczyć Czytelnika zbyt dużą ilością informacji oraz aby analiza różnic pomiędzy poprzednią a nową generacją kart NVIDI-i była stosunkowo łatwa.

Pierwszą rzucającą się w oczy różnicą jest zmiana w ułożeniu i pogrupowaniu multiprocesorów strumieniowych (ang. Streaming Multiprocessor – SM). Układ GT200 składał się z 30 SM, zgrupowanych po trzy. W GT 200 trzy multiprocesory korzystają z tej samej pamięci podręcznej tekstur pierwszego poziomu oraz tych samych jednostek teksturujących. W ten sposób powstaje grupa nazywana TPC. W GF100 zrezygnowano z takiego grupowania multiprocesorów. Teraz każdy multiprocesor jest częścią całkowicie niezależną od reszty układu, ma własną pamięć podręczną pierwszego poziomu i własne jednostki teksturujące (więcej o jednostkach teksturujących powiemy trochę później). Liczba SM w układzie zmalała z 30 do 16, za to każdy z multiprocesorów trochę „przytył”. O tym jednak napiszemy trochę dalej.

Trochę architektury – pamięć podręczna, zarządca i kontroler pamięci

Drugą zmianą widoczną na ogólnym widoku architektury układu GF100 jest to, że Fermi otrzymał prawdziwą hierarchię pamięci podręcznej. Osoby bardziej spostrzegawcze zapewne zauważyły, że na diagramie GT200 jest mowa o pamięci podręcznej tekstur, natomiast w przypadku GF100 brakuje słowa tekstur. Nie jest to przeoczenie, a jedna z większych zmian w stosunku do poprzedniej generacji. Zmiana ta jest przede wszystkim ukłonem w kierunku osób wykorzystujących karty graficzne w obliczeniach, a nie w grach. Mimo że zarówno w jednym, jak i w drugim przypadku jest to pamięć podręczna, to różnica między nimi jest bardzo duża.

Pamięć podręczna tekstur, jak sama nazwa wskazuje, została zaprojektowana do przechowywania... tekstur (mało odkrywcze). Podstawową różnicą w porównaniu z pamięcią podręczną w procesorach jest to, że jest to pamięć tylko do odczytu i nie ma ona na celu zapewnienia spójności danych pomiędzy multiprocesorami. W tradycyjnym procesorze pamięć podręczna jest często wykorzystywana przy wykonywaniu obliczeń – są tam zapisywane dane potrzebne do ich wykonania (pobierane później przez właściwą część rdzenia instrukcją load) oraz ich wyniki (zapisywane instrukcją store). Pamięć podręczna służy też do tego, aby rdzenie nie nadpisywały swojej pracy i aby wiedziały, którym zadaniem się zajmują. Poza tym ma ona na celu przyspieszenie działania procesora, bo dzięki pamięci podręcznej jest możliwe wielokrotne używanie danych bez konieczności ciągłego odwoływania się do zewnętrznego RAM-u.

Do pamięci podręcznej tekstur dane zapisuje się „odgórnie”. Programista może zdecydować, że umieści w niej jakąś macierz danych, która będzie często wykorzystywana przy obliczeniach, dzięki czemu oszczędzi cenną przepustowość pamięci. A multiprocesory same z siebie nic do niej nie mogą zapisać – mogą jedynie pobierać z niej dane (wykonywać instrukcję load). Dane są zapisywane bezpośrednio do zewnętrznej pamięci z wykorzystaniem po drodze ROP-ów (do których jest wysyłana instrukcja store). Pamięć podręczna tekstur jest też sporo wolniejsza od zwykłej pamięci podręcznej, ponieważ nie jest potrzebny tak szybki dostęp do niej jak w przypadku procesora. W GT200 do komunikowania się pomiędzy wątkami w SM była wykorzystywana pamięć współdzielona (16 kB), do której procesory strumieniowe (ang. Streaming Processor – SP) mogą zapisywać wyniki swoich obliczeń, dostępne do wykorzystania przez inne SP znajdujące się w danym SM (pod warunkiem że wykonują obliczenia dla wątku należącego do tego samego bloku – obszerniej napiszemy o tym trochę później). Jednak to też nie jest pamięć podręczna w pełnym tego słowa znaczeniu. Jest ona zarządzana programowo, a nie sprzętowo, czyli programista decyduje, kiedy dane z niej są odczytywane, a kiedy są do niej zapisywane i oczywiście co się tam znajduje. Fermi ma pamięć podręczną znacznie bliższą temu, co spotykamy w procesorach. Każdy SM otrzymał 64 kB szybkiej pamięci. Może ona zostać podzielona w proporcji 16/48 kB – część jest wykorzystywana jako pamięć L1D (pamięć podręczna danych pierwszego poziomu), a część jako pamięć współdzielona. Rozmiar obu rodzajów pamięci można ustawić ręcznie w czasie działania układu. Wymaga to jednak zatrzymania na chwilę wszystkich obliczeń. NVIDIA zdecydowała się na taką konfigurowalność, ponieważ każdy z tych rodzajów pamięci może być bardziej lub mniej przydatny, zależnie od sytuacji. Gdy mamy do czynienia z bardziej przewidywalnymi algorytmami i obliczeniami, większy pożytek będzie z większej pamięci współdzielonej. Gdy obliczenia są mniej przewidywalne i trudno zmusić algorytm do efektywnego wykorzystywania pamięci współdzielonej, lepiej jest, gdy pamięć podręczna ma większy rozmiar, a pamięć współdzielona – mniejszy. Oprócz tego Fermi otrzymał prawdziwą pamięć podręczną drugiego poziomu (768 kB) zamiast pamięci podręcznej tekstur drugiego poziomu, jak w GT 200 (256 kB). Pośredniczy ona w wykonywaniu instrukcji load/store (także przy operacjach na teksturach, tak jak pamięć tekstur), pilnuje, aby dane nie były nadpisywane przez „niepowołane” wątki (zapewnia spójność danych), i umożliwia korzystanie z tych samych danych wszystkim multiprocesorom.

Jak już wspomnieliśmy, ta zmiana bardziej była podyktowana potrzebami naukowców niż projektantów gier. Gry co prawda także skorzystają z większej i szybszej pamięci, w której mogą być trzymane tekstury, ale różnice na pewno nie będą na tyle duże, aby uzasadnić całkowitą przebudowę układu i sposobu zarządzania pamięcią. Za to programy wykonujące różne dziwne obliczenia mogą przyspieszyć nawet kilkukrotnie (w skrajnych przypadkach). Poza tym jest to znaczne ułatwienie dla programistów, którzy mają teraz dostępny znacznie bardziej przejrzysty model pamięci. Dodatkowym prezentem od NVIDI-i jest jednolita przestrzeń adresowa pamięci lokalnej, współdzielonej i globalnej, co mocno upraszcza operacje na wskaźnikach.

Inna zmiana zaszła w globalnym zarządcy (ang. scheduler), który rozdziela pracę pomiędzy SM. NVIDIA zarządcę Fermiego nazywa GigaThread Engine. Tutaj będzie potrzebne małe wyjaśnienie dotyczące tego, w jaki sposób jest organizowana praca w GeForce'ach. Najszerszym pojęciem jest kernel. Jest to „miniprogram” wykonujący jakieś zadanie obliczeniowe (w przypadku grafiki będzie to jakiś shader). Kod jest analizowany i jest tworzona siatka składająca się z bloków wątków. Blok wątków składa się (jak sama nazwa wskazuje) z oddzielnych wątków (do 512 wątków na blok). GigaThread Engine rozsyła poszczególne bloki do multiprocesorów (o tym, jak i dlaczego wątki są grupowane w bloki, napiszemy w swoim czasie ;)). W G80 i GT200 zarządca mógł się zajmować w tym samym czasie tylko jednym kernelem / jedną siatką bloków. W Fermim zmieniono to: GigaThread Engine może zajmować się kilkoma kernelami jednocześnie. Jest to przydatne, gdy zadanie do wykonania jest zbyt małe, aby zapewnić pracę całemu układowi. Wtedy zarządca może do niezajętych obliczeniami multiprocesorów wysłać bloki wątków związane z innym kernelem. Ograniczeniem jest to, że wszystkie kernele muszą mieć ten sam „kontekst”. Nie jest na przykład możliwe jednoczesne liczenie fizyki na części multiprocesorów i wykonywanie kodu OpenCL na reszcie. Poprawka ta nie ma większego znaczenia w przypadku renderowania grafiki, ponieważ przeważnie procesor ma wystarczająco dużo roboty, aby obciążyć wszystkie multiprocesory. Jest to więc kolejna poprawka, która przyniesie korzyści w GPGPU. Ale NVIDIA chwali się przy tym, że znacznie poprawiła szybkość przełączania się pomiędzy kontekstami. Powinno to mieć pozytywny wpływ na wydajność w grach korzystających z GPU PhysX, gdy zarówno grafika, jak i fizyka są liczone na tej samej karcie graficznej. Skorzystają z tego też wszelkie gry DirectX 11, które używają Compute Shaderów DirectX-a 11 (na przykład BattleForge, S.T.A.L.K.E.R.: Zew Prypeci, gry oparte na silniku Frostbite 2.0 itp.). Mimo że DirectCompute jest częścią DirectX, to nie jest możliwe jednoczesne wykonywanie kodu DirectCompute i Direct3D. Musi nastąpić zmiana kontekstu. Dzięki temu, że karta traci mniej cykli zegara na przełączanie się pomiędzy trybami pracy, może szybciej wykonać potrzebne obliczenia.

Ostatni zestaw zmian widocznych „z lotu ptaka” nastąpił w kontrolerze pamięci. Fermi ma sześć kontrolerów obsługujących pamięć GDDR5. Daje to nam 384-bitową szynę pamięci. Dla porównania, GT200 miał osiem kontrolerów GDDR3, co dawało 512-bitową szynę. Zmianą związaną z kontrolerem, która znowu nie ma żadnego związku z grami, jest dodanie mechanizmów korekcji błędów ECC. Dzięki temu błędy w przesyłaniu danych po szynie pamięci mogą być naprawiane. Oczywiście – nic za darmo. Włączenie trybu ECC powoduje 10–20% spadek przepustowości pamięci. To następna funkcja całkowicie niepotrzebna graczom, a bardzo przydatna w zaawansowanych obliczeniach. (Wyobraźcie sobie, że w obliczeniach związanych z wytworzeniem na przykład leku, które trwają kilka tygodni, pojawił się jakiś błąd w obliczeniach wynikający z nieprawidłowego przesłania danych z pamięci). Oczywiście, specyfikacja pamięci GDDR5 zawiera pewne mechanizmy wykrywania błędów i ponawiania transmisji danych „do skutku” (z tego korzystają Radeony HD 5000), ale w niektórych zastosowaniach to nadal za mało.

Trochę architektury – multiprocesor i okolice

W końcu możemy zejść trochę niżej, czyli do budowy pojedynczego multiprocesora i tego, co zostało tutaj zmienione. Gdyby GPU było CPU, to multiprocesor byłby jednym z jego rdzeni (autor uchyla się przed cegłą rzuconą przez marketingowców NVIDI-i). Na naszej ulubionej ilustracji widać, że liczba „rdzeni” w Fermim zmalała z 30 do 16. Pojedynczy SM składa się teraz z 32 SP zamiast ośmiu, więc całkowita liczba procesorów strumieniowych wzrosła z 240 do 512. Oczywiście NVIDIA (zresztą AMD też) twierdzi, że rdzeniami należy nazywać pojedyncze SP, z których składają się SM-y (nawet dostały chwytliwą nazwę „CUDA Core”), ale my niezbyt chętnie patrzymy na to w ten sposób. Oczywiście, pojedynczy SP / CUDA Core jest w pewnym sensie rdzeniem. Ma własny potok wykonawczy i daleko mu do zwykłej jednostki wykonawczej, którą znamy ze standardowych procesorów. Ale do pełnego procesora też mu sporo brakuje, ponieważ znaczna część zasobów jest dzielona z innymi SP znajdującymi się w danym multiprocesorze, przez co nie jest to „byt” autonomiczny. A my lubimy patrzeć na rdzeń jak na najmniejszą autonomiczną część danego procesora.

Wróćmy jednak do zmian w budowie multiprocesora. Już wspomnieliśmy o znacznym zwiększeniu liczby SP, ale nie pisaliśmy, że są one wewnętrznie podzielone na dwie grupy po 16 jednostek. Każda z tych grup zajmuje się oddzielną grupą wątków, którą nazwano... osnową (ang. warp). Tak, nazwa jest wzięta prosto z tkalni. Tutaj znowu musimy zrobić małą dygresję. Przy okazji wytłumaczymy w końcu, o co chodzi z tym całym SIMD i SIMT.

Od czasów G80 osnowa składa się z 32 wątków (lub z ośmiu czwórek pikseli, gdy mówimy o grafice). Podział ten został wprowadzony, ponieważ cały blok wątków (przypominamy, że składa się on z 512 wątków) jest za duży, aby nim efektywnie zarządzać jako całością. A pojedynczy wątek jest zbyt małą jednostką. Potrzebne było coś pomiędzy i tym czymś jest właśnie osnowa będąca grupą 32 wątków. Jest to twór podobny do wektora danych w przetwarzaniu SIMD. W przetwarzaniu SIMD dane są pakowane w wektory, a później przed wykonaniem są rozpakowywane i przetwarzane równolegle (stąd Multiple Data w nazwie). Aby było możliwe jednoczesne wykonywanie obliczeń na tak przygotowanym zbiorze danych, muszą one wiązać się z wykonywaniem tej samej instrukcji (stąd Single Instruction w nazwie). Albo mówiąc bardziej precyzyjnie i trochę bardziej „asemblerowo”: muszą mieć taki sam adres początku instrukcji. Przykładem może być podwojenie wszystkich liczb znajdujących się w macierzy o rozmiarach 100×100 (tylko proszę pamiętać, że instrukcje to nie tylko działania matematyczne). Pakujemy z tej macierzy na przykład 10 liczb (bo na tyle pozwala nasz teoretyczny procesor SIMD), pakujemy je w wektor, zaznaczamy, że każda z tych liczb ma zostać podwojona, i wysyłamy wektor do 10 jednostek, które te obliczenia wykonują równolegle. Mamy jednego zarządcę, jeden pobrany adres instrukcji i 10 „przemielonych” liczb. Gdy mamy do wykonania takie samo działanie na dużym zbiorze danych, wyraźnie widać zalety takiego rozwiązania. W przypadku GPU NVIDI-i nie ma jednak wektorów takich jak w SIMD. Zamiast tego jest osnowa (dziwnie to brzmi po polsku, ale nie my wymyślaliśmy te nazwy ;)). Różnica polega na tym, że o ile w przetwarzaniu SIMD dane trzeba pakować w wektory świadomie i jest to bezpośrednio związane z architekturą danego układu, to w przypadku GPU NVIDI-i jest to zaszyte w mikroarchitekturze. Układ sam grupuje wątki i nie mamy na to żadnego wpływu. Świadomość pakowania wątków w 32-elementowe grupy pomaga przy optymalizacji kodu, ale nie jest wymagana do tego, aby obliczenia były wykonywane równolegle.

Inna różnica pomiędzy SIMD a SIMT jest taka, że o ile w SIMD wątki obliczeniowe mogą się bez problemu komunikować ze sobą, to w SIMT wątki komunikują się ze sobą jedynie za pośrednictwem pamięci współdzielonej i jeden wątek nie może korzystać z danych zawartych w rejestrach wykorzystywanych przez drugi. Koniec dygresji, wróćmy do rdzeni Fermiego i GT200.

Czterokrotnie większa liczba procesorów strumieniowych znajdujących się w multiprocesorze oraz ich podział na dwie grupy to nie wszystko. Podwojono liczbę zarządców i liczbę jednostek SFU (ang. Special Function Unit – jednostki zajmujące się bardziej skomplikowanymi działaniami, na przykład obliczaniem wartości funkcji sinus) oraz pozbyto się oddzielnej jednostki wykonującej obliczenia na liczbach zmiennopozycyjnych podwójnej precyzji.

Podwojenie liczby zarządców łączy się bezpośrednio z podzieleniem SP na dwie podgrupy. Każdy z zarządców może przygotować i wysłać do danej grupy jednostek obliczeniowych pojedynczą grupę wątków, dzięki czemu jednocześnie mogą być wykonywane obliczenia związane z dwiema osnowami. Mamy tu więc do czynienia z czymś, co w procesorach nazwalibyśmy dwudrożnością (ang. dual-issue). Zarządcy są oddzieleni od SP i każdy z nich co cykl zegara może wysłać przygotowaną połowę osnowy do jednej z dwóch grup SP lub do SFU. Wartą wzmianki nowością jest to, że obliczenia wykonywane przez SFU nie „paraliżują” już obliczeń wykonywanych przez SP, tak jak to było w G80 i GT200. Teraz obliczenia mogą być tam wykonywane niezależnie od SP i zarządca po wysłaniu grupy wątków do SFU może wysłać zestaw wątków do grupy procesorów strumieniowych. Wcześniej, gdy obliczeniami zajmowały się „jednostki do zadań specjalnych”, procesory strumieniowe cierpliwie czekały, aż ich wyspecjalizowani koledzy ukończą swoje zadanie, co mogło trwać nawet kilkadziesiąt cykli zegara (w porównaniu z czterema potrzebnymi na wykonanie wszystkich obliczeń dla pojedynczej osnowy, gdy są to standardowe działania wykonywane przez jednostki zmiennoprzecinkowe). Pozbycie się z multiprocesora oddzielnej jednostki zajmującej się obliczeniami na liczbach zmiennopozycyjnych podwójnej precyzji jest ściśle związane ze zmianami, które omawialiśmy przed chwilą. W GT200 obsługę obliczeń na typie danych double dodano „na szybko”. NVIDIA otrzymała informację od programistów tworzących oprogramowanie wykonujące obliczenia na kartach z układami G80/G92, że czasem przydałaby im się możliwość wykonywania obliczeń o większej precyzji. Najszybszym sposobem było dodanie nowej jednostki. Wadą tego rozwiązania była wydajność, wynosząca zaledwie 1/8 wydajności GT200 w obliczeniach na liczbach 32-bitowych. Teraz zostało to naprawione. Gdy do gry wchodzi 64-bitowa arytmetyka, jednocześnie są wykorzystywane obie grupy procesorów strumieniowych w multiprocesorze. Łatwo więc policzyć, że Fermi na liczbach podwójnej precyzji wykonuje dwa razy mniej obliczeń niż na liczbach pojedynczej precyzji, co prowadzi do wniosku, że pod tym względem nowa architektura jest cztery razy bardziej efektywna niż stara. Całkiem spory krok naprzód. Oczywiście, w grach nie ma to żadnego znaczenia (przynajmniej na razie), ale w przypadku niektórych profesjonalnych aplikacji jest to gigantyczna różnica.

Pozostało nam omówić zmiany w budowie pojedynczego procesora strumieniowego, lub jak kto woli, rdzenia CUDA. Przed Fermim we wnętrzu procesora strumieniowego znajdowała się pojedyncza jednostka wykonawcza, zajmująca się działaniami zarówno na liczbach stało-, jak i zmiennopozycyjnych. Za to pojedynczy rdzeń CUDA w Fermim ma w sobie dwie oddzielne jednostki, z których każda jest przeznaczona do innego typu obliczeń. Ale nie mogą one wykonywać ich jednocześnie. W GT200 łączona jednostka obliczeniowa znajdująca się w SP mogła wykonywać mnożenie liczb stałopozycyjnych jedynie z 24-bitową precyzją, a 32-bitowe mnożenie musiało być emulowane (nie dało się go wykonać w jednym cyklu zegara), co negatywnie wpływało na wydajność.

Nastąpiło też kilka zmian mających na celu przystosowanie Fermiego do wykonywania obliczeń zgodnych z normą IEE 754-2008. Dodano obsługę instrukcji FMA (ang. Fused Multiply Add), czyli bardziej precyzyjnej odmiany instrukcji MAD. Obie pozwalają na wykonanie w jednym cyklu zegara mnożenia dwóch liczb i dodanie wyniku tego mnożenia do trzeciej liczby (A*B+C). MAD przed przejściem do dodawania zaokrąglała wynik mnożenia liczb. FMA tego nie robi, co pozwala uzyskać większą precyzję obliczeń. Dodano też obsługę liczb „subnormal”, czyli takich, jakie są większe od zera, ale mniejsze od najmniejszej liczby, którą da się zapisać za pomocą 32-bitowej liczby zmiennopozycyjnej (na przykład... 10^-8 ). Wcześniej takie liczby były zerowane i bezpowrotnie tracone.

Nastąpiło też dużo dodatkowych zmian mających na celu umożliwienie kompilacji kodu C++ na Fermim. Niektóre z nich zostały omówione już wcześniej (na przykład ujednolicenie przestrzeni adresowej). Trzeba było licznych zmian, aby możliwe było wykorzystywanie takich rzeczy, jak obiekty i wskaźniki, albo zgłaszanie wyjątków (tak, w końcu Try-Catch w CUDA i porządny debugger!). Wszystko to po to, aby zachęcić programistów do pisania jak największej liczby programów korzystających z tych kart graficznych.  

Trochę architektury – umarł TPC, niech żyje GPC!

W końcu trochę o zmianach związanych z generowaniem grafiki. A nastąpiła tutaj mała rewolucja. Jak zapewne sobie przypominacie, w architekturze GT200 występowało coś takiego jak TPC (czyli połączenia trzech multiprocesorów i współdzielonych jednostek teksturujących). Teraz każdy multiprocesor ma własne cztery jednostki teksturujące, którymi nie musi się dzielić. Nowy podział został przedstawiony na poniższym fragmencie slajdu:

Widzimy, że multiprocesory są pogrupowane w cztery GPC. W skład każdego GPC wchodzi rasteryzator (nazywany po prostu Raster Engine), który we wszystkich poprzednich kartach graficznych był pojedynczym „bytem”. Poza tym każdy z multiprocesorów otrzymał własny PolyMorph Engine, którego najważniejszą częścią jest teselator. Mamy więc tutaj do czynienia z 16 teselatorami. Dla porównania, wszystkie karty AMD serii HD 2000, HD 3000, HD 4000 i HD 5000 mają... jeden teselator.

Jest to istotnie mała rewolucja, ponieważ dzięki temu „zniknęły” ostatnie dwa elementy karty graficznej, które nie były zrównoleglone. I stanowczo nie było to łatwe zadanie. Ale po kolei.

Oto PolyMorph Engine:

PolyMorph Engine ma za zadanie zajmować się wierzchołkami. Najpierw pobiera je z pamięci i przesyła do multiprocesora, w którym ich współrzędne są transformowane z przestrzeni obiektów do współrzędnych przestrzeni świata (wytłumaczenie, co to dokładnie znaczy, to temat na oddzielny artykuł, więc wybaczcie te ogólne stwierdzenia). Dodatkowo są określane wszystkie początkowe dane potrzebne do teselacji, np. stopień teselacji i sposób wyznaczenia nowego kształtu teselowanej powierzchni. Tak przygotowane dane na temat wierzchołków i tego, co z nimi zrobić w trakcie teselacji, wracają do teselatora, który generuje nową siatkę wierzchołków i informacje o tym, w jaki sposób są one ze sobą połączone. Dane te wysyła z powrotem do multiprocesora (często w tym momencie w grę wchodzi mapa przesunięć), w którym są obrabiane przez shader domeny i shader geometrii, dzięki czemu uzyskujemy ostateczne współrzędne nowo powstałych w procesie teselacji wierzchołków.

Po końcowej obróbce w PolyMorph Engine przygotowane wielokąty trafiają do Raster Engine, gdzie są poddawane rasteryzacji.

Najpierw pobierane są informacje o wierzchołkach prymitywu, który chcemy poddać rasteryzacji, i są obliczane jego brzegi. Pojedynczy Raster Engine może obliczyć w jednym cyklu zegara brzegi jednego trójkąta. Ponieważ w GF100 mamy cztery takie jednostki, to cała karta jest może przygotować cztery trójkąty na cykl zegara. Taki zestaw informacji trafia do rasteryzatora, który przelicza, które piksele ekranu wypadają na powierzchni danego wielokąta. Na końcu dane o wielokątach są przesyłane do jednostki Z-cull, która odrzuca piksele należące do niewidocznych wielokątów lub ich części.

Jak już wspominaliśmy, wcześniej cała karta graficzna musiała się zadowolić jednym rasteryzatorem. Pojedynczy rasteryzator spokojnie pobierał sobie kolejne wierzchołki i wypluwał z siebie piksele. Nikt wcześniej nie wziął się za zwielokrotnienie tych jednostek, ponieważ nie było to szczególnie potrzebne, a przy tym rozdzielenie pracy pomiędzy rasteryzatory jest zadaniem trudnym i wymagającym wielu dodatkowych obliczeń. Udało nam się dowiedzieć, że NVIDIA, aby to osiągnąć, postanowiła podzielić ekran na części (kafelki – ang. tiles). Ile części? Tego się nie dowiedzieliśmy. Po tym, jak PME przygotowały wierzchołki i przekształciły ich współrzędne na przestrzeń świata, jest możliwe określenie, w którym kawałku ekranu znajduje się dany wielokąt, i na podstawie tego zostaje on przydzielony do odpowiedniego rasteryzatora. Problematyczne są wielokąty, które leżą na powierzchni kilku kafelków, ale NVIDIA ponoć przygotowała jakiś sprytny algorytm wyrównywania obciążenia rasteryzatorów, aby zawsze miały one tyle samo pracy.

Po co to całe zamieszanie i te wszystkie kombinacje? Głównie chodzi o teselację. Obiekty po przejściu przez proces teselacji mogą się składać nawet z kilku milionów wielokątów w miejsce początkowych kilku tysięcy. I karta graficzna jakoś musi sobie z tym poradzić. Pojedynczy teselator i rasteryzator to za mało. Pokazuje to choćby uruchomienie benchmarku Heaven na Radeonie HD 5870. Po włączeniu w nim teselacji i zwróceniu kamery na jakiś mocno teselowany obiekt liczba klatek na sekundę jest praktycznie stała niezależnie od rozdzielczości. Jest to dowód na to, że w takiej sytuacji wąskim gardłem są możliwości karty w obliczaniu geometrii. NVIDIA zaprojektowała GPU zdolny zająć się tymi wszystkimi wielokątami.

Jest to odważny ruch. Nakład pracy musiał być ogromny. Liczba dodatkowych tranzystorów – pewnie też. A wszystko to po to, aby zapewnić jak najwyższą wydajność w grach DirectX 11 korzystających z teselacji, których jednak na razie jest bardzo niewiele. Jeśli teselacja się przyjmie, będzie to strzał w dziesiątkę, w przeciwnym razie ogrom pracy pójdzie na marne.

Przy okazji powstał ciekawy efekt uboczny. W praktyce pojedynczy GPC to prawie kompletny układ graficzny. Dzięki temu NVIDIA ma bardzo uproszczone zadanie przy projektowaniu kart graficznych z niższej półki. Wystarczy wziąć jeden, dwa lub trzy GPC, połączyć je pamięcią podręczną drugiego poziomu, dodać GigaThreadEngine, odpowiednią liczbę ROP-ów oraz kontrolerów pamięci – i otrzymujemy nowy układ graficzny. Czy to oznacza, że w końcu pojawią się słabsze karty oparte na nowej architekturze? Mamy nadzieję, że tak i że nie będziemy musieli czekać na nie zbyt długo (hm... GT200...). 

Modele oraz ich dane techniczne

Na początek pojawią się dwie karty graficzne z układem GF100. Oto ich dane techniczne.

Niektóre informacje znajdujące się w tej tabelce wymagają wyjaśnienia.

Po pierwsze, NVIDIA na razie nie wprowadza karty z aktywnymi wszystkimi 512 rdzeniami CUDA. Firma zdecydowała się na odłączenie jednego całego multiprocesora, czego skutkiem jest „zniknięcie” 32 SP i czterech jednostek teksturujących.

Druga kwestia to stosunkowo mała liczba jednostek teksturujących, nawet mniejsza niż w GeForsie GTX 285. Nie oznacza to jednak niższej wydajności w teksturowaniu. Owszem, GTX 480 może wygenerować mniej adresów tekstur niż poprzednik, ale pojedyncza jednostka teksturująca może pobrać aż cztery próbki tekstury w jednym cyklu zegara zamiast jednej, jak w przypadku poprzednika. Więc w praktyce wydajność jednostek teksturujących jest znacznie wyższa niż poprzednio.

Następna ciekawostka dotyczy zegarów taktujących. Zegar rdzenia odnosi się teraz tylko do taktowania pamięci podręcznej drugiego poziomu i do ROP-ów. Cała reszta układu jest taktowana zegarem jednostek cieniowania lub jakąś jego częścią. Pamięć podręczna pierwszego poziomu i rdzenie CUDA są taktowane pełnym zegarem jednostek cieniowania, a jednostki teksturujące, silniki PolyMorph i rasteryzatory są taktowane... połową tego zegara, czyli 700 MHz. Żeby było śmieszniej, zegar „rdzenia” jest na stałe powiązany z zegarem „jednostek cieniowania”, a jego taktowanie zawsze wynosi połowę prędkości tego drugiego. Więc mamy niby dwie domeny zegarowe, ale tak naprawdę jest jedna, bo obie są ze sobą bezpośrednio połączone.

Inna ciekawostka jest widoczna, gdy porównujemy maksymalną teoretyczną wydajność obliczeniową GeForce'ów GTX 285 i GTX 480. Skąd taka stosunkowo mała różnica pomimo znacznie większej liczby jednostek obliczeniowych?

GT200 i G80 w teorii mogły wykonać równolegle jedną instrukcję MAD (mnożenie dwóch liczb plus dodanie do wyniku trzeciej) wykonywaną na SP i jedną instrukcję MUL (mnożenie dwóch liczb) wykonywaną na SFU (każda SFU ma cztery jednostki FPU zdolne wykonać instrukcję MUL, więc dwie takie jednostki znajdujące się w SM mogły wykonać mnożenie ośmiu par liczb w jednym cyklu zegara). W teorii daje nam to 24 (osiem MUL plus osiem ADD wynikających z operacji MAD wykonywanych przez każdy z SP i osiem MUL wykonywanych przez SFU) operacje na liczbach zmiennopozycyjnych w jednym cyklu zegara wykonywane przez jeden multiprocesor (dalsze obliczenia prowadzące do „uzyskania” maksymalnej teoretycznej mocy obliczeniowej można wykonać dla ćwiczenia samemu ;)). W praktyce sytuacja, kiedy dało się uzyskać równoległe wykonywanie niezależnych instrukcji MUL na SFU, prawie nigdy się nie zdarzała, więc pozostawaliśmy ze standardowym zestawem 240 operacji MAD (480 flopów) wykonywanych przez całe GPU w każdym cyklu zegara. Kiedy spojrzymy na to w ten sposób, to szybko okazuje się, że praktyczna moc obliczeniowa wzrosła w Fermim dwukrotnie, czyli tyle, ile byśmy się spodziewali. Warto też spojrzeć na wydajność w obliczeniach na liczbach podwójnej precyzji. Komentarz jest chyba zbędny.

No i na deser rozmiar GPU. Nie mamy dokładnych liczb, ale możemy w miarę precyzyjnie oszacować, jaki rozmiar ma GPU GTX-a 480. Od razu widać, że jest... olbrzymi. Na dodatek ponad trzy miliardy tranzystorów w jednym kawałku krzemu robi spore wrażenie. Cypress przy Fermim wygląda jak Dawid przy Goliacie. Widać tu wyraźnie, że obie firmy mają zupełnie inną koncepcję GPU i inaczej budują swoją ofertę kart graficznych opartych na danej architekturze. W praktyce tych GPU nie powinno się ze sobą bezpośrednio porównywać. To tak, jakby bokser wagi ciężkiej walczył z bokserem wagi średniej – po prostu to nie ta kategoria wagowa. W teorii o tyle większy układ graficzny powinien być znacznie wydajniejszy niż „knypkowaty” Radeon. Czy tak jest naprawdę? O tym już za chwilę, wcześniej kilka fotek ;)

Filtrowanie tekstur i wygładzanie krawędzi

Przejdźmy teraz do trochę bardziej praktycznych rozważań. Omówimy teraz zmiany (albo ich brak) w szybkości i jakości filtrowania tekstur oraz wygładzania krawędzi.

Najpierw filtrowanie tekstur. NVIDIA nie zmieniła swojego algorytmu anizotropowego filtrowania tekstur i nadal nie jest on doskonały, ale daje bardzo dobre efekty. W praktyce nie da się dostrzec różnicy między algorytmem NVIDI-i a algorytmem idealnie niezależnym od kąta. Poniżej potwierdzający to zrzut ekranu z programu D3D AF-Tester. 

A jak z wydajnością? Przeprowadziliśmy serię testów w kilku grach z wyłączonym i włączonym filtrowaniem anizotropowym. Podajemy też, o ile procent spada liczba klatek na sekundę po włączeniu 16-krotnego filtrowania anizotropowego.

Widzimy, że w nowej generacji kart dość mocno (około dwukrotnie) wzrósł koszt filtrowania anizotropowego. Możliwe, że jest to wina mniejszej liczby jednostek teksturujących. Pod tym względem architektura Radeona HD 5870 wypada trochę lepiej, ale trochę gorzej niż staruszek GTX 285.

Teraz trochę o wygładzaniu krawędzi. NVIDIA nie zmieniła sposobu dobierania próbek w czasie wykorzystywania multisamplingu.

Za to nieco zmieniła się wydajność. NVIDIA chwali się tym, że udało się zoptymalizować ROP-y pod kątem ośmiokrotnego wygładzania krawędzi, dzięki czemu powinien to być znacznie mniej kosztowny proces w stosunku do kart poprzedniej generacji.

Widzimy, że o ile koszt czterokrotnego wygładzania jest bardzo zbliżony do modelu 285 (i przy tym trochę niższy niż w przypadku Radeona HD 5870), to koszt wygładzania ośmiokrotnego faktycznie wyraźnie się zmniejszył.

ROP-y GeForce'a GTX 480 dostały też kilka nowych funkcji. Jedną z nich jest nowy tryb wygładzania krawędzi – CSAA 32×. W GeForce'ach GTX 2xx najwyższym trybem był CSAA 16×, czyli tryb z ośmioma próbkami multisamplingowymi i ośmioma próbkami pokrycia. NVIDIA poszła o krok dalej i umożliwiła wygładzanie krawędzi z użyciem ośmiu próbek multisamplingowych i 24 próbek pokrycia (zasadę działania takiego wygładzania krawędzi tłumaczyliśmy tutaj).

Oprócz tego próbki pokrycia mogą być wykorzystywane przez ROP-y do wykonywania obliczeń związanych z funkcją Transparency Multi-Sample Anti-Aliasing. Transparency Anti-Aliasing (TAA) jest wykorzystywana, gdy chcemy wygładzić krawędzie... liści w grach DirectX 9 i starszych. Liście na drzewach przeważnie są złożone z jednego wielokąta, który jest pokryty teksturą z namalowanym liściem i dodanymi przezroczystymi partiami dopasowującymi kształt tekstury do kształtu wielokąta. Standardowy multisampling nie umie sobie poradzić z wygładzeniem krawędzi liścia, ponieważ bada on tylko krawędzie wielokątów, a krawędź wielokąta takiego liścia jest przezroczysta. TAA pozwala na wygładzenie krawędzi takiego liścia, ponieważ umożliwia GPU „zrozumienie” tego, że ma wygładzić tę nieprzezroczystą krawędź znajdującą się we wnętrzu wielokąta, a nie tę przezroczystą, której i tak nie widzimy. Oczywiście, liść to tylko przykład. Tego typu zabieg (tekstura z przezroczystymi częściami) jest stosowany bardzo często na przykład przy tworzeniu trawy czy siatek. Od kilku generacji kart graficznych (a dokładniej: od GeForce'ów serii 7000) mamy do dyspozycji dwie metody TAA: Transparency Super-Sample Anti-Aliasing (TSAA) i Transparency Multi-Sample Anti-Aliasing (TMAA). Ten pierwszy jest znacznie kosztowniejszy, ale daje dobre rezultaty, a ten drugi obciąża kartę znacznie mniej, ale też efekty są znacznie gorsze. Nowe GeForce'y mają umożliwić wykorzystywanie próbek pokrycia przy włączonym TMAA, dzięki czemu ma być możliwe uzyskanie jakości obrazu porównywalnej z TSAA, ale przy znacznie mniejszym spadku płynności.

Fermi pręży muskuły – wydajność teselacji i DirectCompute

Postanowiliśmy sprawdzić, jak architektura GF100 sprawdza się w testach, które bardzo mocno obciążają kartę obliczeniami związanymi z teselacją i (lub) DirectCompute. Testy te należy traktować jako syntetyczne, ponieważ to, co zawierają, jeszcze długo nie pojawi się w grach (jeśli w ogóle się pojawi).

Na pierwszy test wybraliśmy demo NVIDI-i o nazwie Island:

Mamy tu do czynienia z w pełni dynamicznie generowaną powierzchnią oceanu. Demo wykorzystuje teselację, aby wzbogacić fale w szczegóły, oraz DirectCompute, aby przeliczać na bieżąco, w jaki sposób zmienia się kształt i ułożenie fal. Testy przeprowadziliśmy po ustawieniu współczynnika teselacji na 20. Taki wybór wynika z tego, że powyżej tej wartości obserwowaliśmy znaczny spadek wydajności, a trudno było przy tym zauważyć jakiekolwiek różnice w wyglądzie.

Oparty na architekturze Fermi GeForce GTX 480 radzi sobie w takich warunkach ponad dwa razy lepiej niż najmocniejszy układ AMD.

Użyliśmy także dema NVIDI-i prezentującego symulację włosów.

Demo to wykorzystuje teselację, aby zwiększyć szczegółowość fryzury, oraz DirectCompute, aby symulować zachowanie fryzury w zależności od siły i kierunku wiatru itd. Bardzo byśmy chcieli zobaczyć tak symulowane włosy w grach.

Tym razem przewaga GeForce'a nad Radeonem jest prawie trzykrotna.

Po dwóch testach przygotowanych przez NVIDI-ę czas na test firmy AMD. W pakiecie SDK DirectX-a 11 znajdują się prezentacje i przykłady. Spora część z nich została wykonana przez programistów AMD. My wybraliśmy demo pokazujące podział wielokątów na mniejsze metodą Catmula-Clarka. 

Pomiary wykonaliśmy przy dwóch różnych współczynnikach gęstości podziału: 15 (najwyższy, przy którym jeszcze zauważaliśmy jakieś różnice) i 31 (najwyższy, jaki da się ustawić w tej prezentacji).

Nie, te wyniki to nie jest nasza pomyłka. Tyle naprawdę wychodzi. Jest to test zdecydowanie syntetyczny, ale komentarz i tak jest zbędny.

Na zakończenie znany benchmark Unigine Heaven 2.0, który wykorzystuje teselację wszędzie tam, gdzie tylko się da. Mimo że jest oparty na prawdziwym silniku gry, to w praktyce sposób wykorzystywania teselacji w tym teście jest na tyle „nachalny”, że zbyt szybko nie spotkamy się z czymś takim w rzeczywistości. Ale za to potrafi wycisnąć z teselatorów karty graficznej wszystko, co się da.

Test wykonywaliśmy w dwóch różnych ustawieniach jakości teselacji: Normal i Extreme. Nie ma pomiędzy nimi praktycznie żadnej różnicy wizualnej, ale jest całkiem spora pod względem wydajności i liczby generowanych wielokątów.

Już porównanie średniej wydajności Radeona HD 5870 i GTX-a 480 robi wrażenie. Ale jeszcze większe robi porównanie minimalnej liczby klatek na sekundę. Gdy na ekranie jest naprawdę wiele wielokątów (w tym teście najwięcej jest ich wtedy, gdy się patrzy na charakterystycznego smoka), GeForce potrafi być nawet trzy razy szybszy od Radeona.

Tych kilka testów syntetycznych pokazuje, że różnica w możliwościach przetwarzania geometrii między Radeonem HD 5870 a GeForce'em GTX 480 jest naprawdę ogromna. Tak samo jest z DirectCompute. 16 silników PolyMorph, cztery silniki rasteryzujące i szybka pamięć podręczna robią swoje.

3DVision, OptiX i inne CUDA

W redakcji czasem wracał temat, czy wolimy 3DVision czy Eyefinity. NVIDIA postanowiła rozwiązać nasz problem i połączyła obie te techniki w jedną. 3DVision na trzech monitorach? Bez problemu – dzięki 3DVision Surround.

Widzieliśmy to w działaniu i wygląda to po prostu cudownie. Lepsze doznania może zapewnić tylko specjalnie przygotowany pokój ze specjalnym projektorem kompatybilnym z 3DVision ;) Ale są dwa problemy. Jednym z nich jest wydajność. Uruchomienie 3DVision na trzech monitorach wymaga gigantycznej mocy obliczeniowej karty graficznej i nie we wszystko pogramy w maksymalnych ustawieniach szczegółowości obrazu. Drugi polega na tym, że... potrzebujemy do tego dwóch kart graficznych. NVIDIA nie ma jeszcze karty, która umiałaby wyprowadzić obraz do trzech monitorów naraz (tym bardziej obraz stereoskopowy). Dlatego potrzebujemy wyjścia obrazu z dwóch kart. Dobra wiadomość jest taka, że nie muszą to być dwa GeForce'y z serii 400. Będzie to działało także w starszych modelach, ale wydajność stanowczo nie zachwyci.

Wprowadzając nowe układy, NVIDIA podkreśla możliwość ich wykorzystania w śledzeniu promieni (ray-tracingu). Firma od dłuższego czasu ma w swojej ofercie dla profesjonalistów pakiet OptiX. Jest to w pełni funkcjonalny zestaw narzędzi pozwalających przerzucić śledzenie promieni na kartę graficzną. Efekty?

Powyższy zrzut ekranu pochodzi z dema NVIDI-i, w którym można sobie wyrenderować modele różnych samochodów. Wyrenderowanie takiej sceny trwa w zależności od ustawień jakości od kilku sekund do kilku minut, co jest wynikiem raczej imponującym. Nie jest to jeszcze ray-tracing w czasie rzeczywistym, ale widać znaczne przyspieszenie. NVIDIA mówi o Fermim jako o pierwszym kroku w stronę śledzenia promieni w czasie rzeczywistym i twierdzi, że za kilka lat będzie można zobaczyć coś takiego w grach. Mówi też o tym, że Fermi może być w tego typu zastosowaniach nawet cztery razy szybszy od kart poprzedniej generacji. Nasza kryształowa kula chwilowo pojechała do naprawy, więc tego nie skomentujemy, ale na pewno będziemy uważnie obserwować rozwój wydarzeń.

Na koniec o tym, że doczekaliśmy się pierwszej gry wykorzystującej... CUDA: Just Cause 2. Gdzie miejsce na CUDA w grze? Programistom udało się zaimplementować dwa dodatkowe efekty, do których obliczenia są wykonywane przez kod zgodny z CUDA: filtr bokeh i przekształcanie powierzchni wody za pomocą szybkiej transformaty Fouriera (FFT).

Pierwszy efekt zmienia wygląd świateł znajdujących się poza ustawioną strefą ostrości widzenia i tworzy tak zwany bokeh. Jest to efekt dobrze znany wszystkim fotografom i kamerzystom. Drugi efekt generuje fale na wodzie. Bez CUDA woda jest zupełnie płaska i do urozmaicenia jej wyglądu jest używana zwykła mapa wypukłości (na dodatek niezbyt ładna ;)). Dzięki wykorzystaniu CUDA jest możliwe dynamiczne generowanie fal, które na dodatek są zależne od kierunku wiatru. Wygląda to ładnie, ale szczerze mówiąc, wolelibyśmy zobaczyć to samo wykonane za pomocą DirectCompute. Na poprzedniej stronie można zobaczyć wodę, której powierzchnia również jest przekształcana przy użyciu FFT. Co prawda jest to wersja, która jest zgodna tylko z DirectX 11, ale swego czasu NVIDIA prezentowała podobne demo (ale bez teselacji) uruchamiane na GeForce'ach GTX 285. Wiemy więc, że da się coś takiego zrobić w grze zgodnej z DirectX 10, takiej jak Just Cause 2. Czemu zamiast tego wykorzystano chronioną patentami technikę CUDA? Nie będziemy się bawić w teorie spiskowe. Ale trochę szkoda, bo chcielibyśmy porównać w rzeczywistych warunkach wydajność Radeonów i GeForce'ów. Mimo wszystko to dobrze, że pierwsze gry zaczynają korzystać w taki sposób z mocy obliczeniowej kart graficznych. Chcemy więcej!

GeForce GTX 480 – karta referencyjna

Każdy, kto na bieżąco śledził informacje o nowym GeForsie pojawiające się w internecie, widział już jego zdjęcia. Dla pozostałych – zestaw zdjęć zrobionych przez nas.

Od frontu od razu zauważamy rurki cieplne wychodzące poza górną krawędź karty. Dość kontrowersyjnie wygląda niezakryta część radiatora. Oprócz tego, że naszym zdaniem nie wygląda to najładniej, to lepiej nie dotykać go, gdy komputer jest włączony. No i z tyłu nie ma ochronnej płytki, którą tak lubiliśmy w GTX-ie 280 i Radeonie HD 5870. I te wycięcia w płytce drukowanej... Z wyglądu Radeon HD 5870 podoba nam się dużo bardziej ;) Karta została wyposażona w dwa wyjścia DVI i jedno mini-HDMI. Niestety, nie da się korzystać z wszystkich trzech naraz, jak w Radeonach serii HD 5000.

GPU jest wielkie i zakryte miedzianą blaszką ochronną. Zaskoczyły nas użyte kości pamięci. Są to układy Samsunga przeznaczone do działania z częstotliwością 1250 MHz – takie same jak w Radeonach HD 5870. Są one w tej karcie taktowane dużo wolniej, niż przewiduje specyfikacja. Układ scalony CHL8266 wyprodukowany przez firmę CHiL umożliwia programową zmianę napięcia rdzenia. Możliwe, że pokażą się odpowiednie narzędzia, które będą to ułatwiały.

Układ chłodzenia jest stosunkowo mały, ale bardzo dobrze wykonany. W równomiernym rozprowadzaniu ciepła pomaga pięć rurek cieplnych. Dodatkowo cała powierzchnia karty znajduje się pod jednolitym radiatorem odłączonym od bloku odprowadzającego ciepło bezpośrednio od GPU. Jest to dobra wiadomość dla wielbicieli chłodzenia cieczą. Wentylator został wyprodukowany przez Delta Electronics.

Zestaw testowy

Wszystkie testy wydajności zostały wykonane na platformie składającej się z następujących podzespołów:

System operacyjny:

• Windows 7 w wersji 64-bitowej.

Sterowniki:

• Radeon HD 5970, Radeon HD 5870 – Catalyst 10.3a,
• GeForce GTX 285, GeForce GTX 295 – ForceWare 197.25,
• GeForce GTX 480 – ForceWare 197.17.

3DMark Vantage

Na rozgrzewkę 3DMark Vantage, który ma bardziej wartość sentymentalną niż użytkową ;) Najnowsza wersja benchmarku nie polubiła się z nowym GeForce'em i umieściła go w rankingu zarówno poniżej Radeona HD 5870, jak i GeForce'a GTX 295.

Battlefield: Bad Company 2 DX 10

Nowy Battlefield korzysta z podrasowanej wersji silnika Frostbite 1.5. Silnik ten po tuningu korzysta z DirectX 9, DirectX 10, jak i niektórych funkcji DirectX 11. Wydajność mierzymy w początkowej części trzeciego rozdziału kampanii dla pojedynczego gracza, a pomaga nam w tym FRAPS.

Wydajność nowego GeForce'a jest zbliżona do GTX-a 295 i... Radeona HD 5870. Bez wygładzania krawędzi i przy wygładzaniu czterokrotnym Radeon jest lekko z przodu, natomiast przy ośmiokrotnym GeForce nadrabia zaległości.

Borderlands

Borderlands to dość nietypowa gra, będąca skrzyżowaniem gatunków RPG i FPS. Korzysta z silnika Unreal Engine 3, ale bywa dość ciężkim orzechem do zgryzienia nawet dla mocniejszych kart graficznych, szczególnie gdy zostaje wymuszone wygładzanie krawędzi. Test wykonujemy przy użyciu wbudowanego w grę timedema.

Bez wygładzania krawędzi na prowadzenie wysuwa się nowy GeForce. Po włączeniu wygładzania sytuacja się zmienia i to Radeon przewodzi stawce, i to dość wyraźnie (szczególnie przy ośmiokrotnym wygładzaniu).

Call of Duty: Modern Warfare 2

Jedna z najbardziej wyczekiwanych i kontrowersyjnych gier zeszłego roku. Przez jednych uwielbiana, przez innych znienawidzona za sprawą niezbyt trafnych decyzji producenta. Test przeprowadzamy, mierząc FRAPS-em średnią liczbę klatek na sekundę w początkowej fazie misji Gułag.

Widzimy, że GeForce radzi sobie trochę lepiej z wygładzaniem krawędzi: po jego włączeniu jest na lekkim (5–10%) prowadzeniu. Gdy wygładzanie wyłączymy – na czoło wysuwa się Radeon. Niestety, z jakiegoś powodu nie mogliśmy wymusić ośmiokrotnego wygładzania w tej grze przy użyciu panelu sterowania NVIDI-i zintegrowanego ze sterownikami, które były niezbędne do uruchomienia GTX-a 480.

Colin McRae: DiRT 2 DX 9

Najnowsza gra rajdowa Codemasters cieszy się sporą popularnością. Jest oparta na zaktualizowanym silniku Ego, który został wykorzystany w Race Driver: GRID. Do mierzenia wydajności wyjątkowo używamy zintegrowanego z grą testu. Okazało się, że wyniki podawane przez ten test nie odbiegają od tych uzyskiwanych w czasie gry, także jego forma jest do przyjęcia (jedno okrążenie przejechane przez komputer).

W tej grze widzimy wyraźnie efektywność nowych ROP-ów przy włączonym ośmiokrotnym wygładzaniu krawędzi. Dzięki temu w pierwszym z trzech trybów testowych GeForce ma wyraźną przewagę nad Radeonem. W pozostałych przypadkach jest już trochę gorzej i GTX 480 kończy równo z Radeonem HD 5870 lub nieco za nim.

Crysis: Warhead

Tej gry nie trzeba nikomu przedstawiać. Do pomiarów wydajności wykorzystujemy demo nagrane w czasie rozgrywki na mapie Ambush. Demo rozpoczyna się krótkim biegiem wzdłuż strumyka, a kończy podziwianiem wschodu słońca na plaży. Wszystkie opcje jakości grafiki były ustawione na poziom Entuzjasta. Silnik gry to oczywiście CryEngine 2, korzystający z API DirectX 10.

W Crysisie walka była bardzo wyrównana: średnia liczba klatek na sekundę była bardzo zbliżona. Mimo to zwycięstwo w tej konkurencji przypada raczej GeForce'owi. Natknęliśmy się na powtarzający się problem z minimalną liczbą klatek na sekundę w testach z użyciem Radeona HD 5870. Gdy na ekranie było widać jakiś większy wybuch, płynność była znacznie mniejsza niż w przypadku GeForce'a. Możliwe, że to jakiś problem ze sterownikami... albo zły kaprys. Wcześniej tego zjawiska nie zaobserwowaliśmy.

Enemy Territory: Quake Wars

Enemy Territory: Quake Wars to jedna z najdłużej wykorzystywanych przez nas gier. I prawdopodobnie będzie tak aż do pojawienia się nowej gry id Software pod tytułem Rage. Pomiar wykonujemy przy użyciu nagranego przez siebie timedema obejmującego kawałek rozgrywki botów na mapie Salvage. W sprawdzaniu minimalnej liczby klatek na sekundę pomaga nam FRAPS. Wszystkie opcje graficzne są ustawione na maksimum. Silnik gry to mocno przebudowany id Tech 4 i jako jedyny w naszym zestawieniu korzysta z API OpenGL.

Pierwsze wyraźne zwycięstwo GTX-a 480 nad Radeonem HD 5870. GeForce jest tutaj szybszy o kilkanaście procent. W końcu.

Left 4 Dead 2

Druga część gry o czwórce typowych ludzi, którzy znaleźli się w środku wesołej gromadki krwiożerczych zombi. Gra wykorzystuje zmodyfikowany silnik Source zgodny z DirectX 9. W czasie testu uruchamiamy timedemo z nagranym przebiegiem ostatniego etapu kampanii Hard Rain.

Zwycięstwo numer dwa. Widać wyraźnie efektywność nowych ROP-ów GTX-a 480, i to nie tylko na tle poprzedniej generacji, ale też w porównaniu z Radeonem HD 5870.

Metro 2033 DX 10

Metro 2033 urzekła nas klimatem oraz technicznym zaawansowaniem użytego silnika. Grę można uruchomić zarówno w trybie DirectX 9, jak i DirectX 10 oraz DirectX 11. Test wykonujemy, mierząc FRAPS-em liczbę klatek na sekundę w trakcie przejażdżki drezyną na początku etapu Chase.

Na razie Radeony nie mają zbytnio czego szukać w tej grze. Bardzo wyraźna przewaga nowego GeForce'a, szczególnie po aktywowaniu pełnego multisamplingu.

Need for Speed: Shift

Druga gra wyścigowa w naszym zestawieniu, tym razem wydana przez Electronic Arts. Pomiar wykonujemy FRAPS-em w czasie przejazdu jednego okrążenia trasy London River.

W najnowszym Need for Speed Radeony obecnie radzą sobie lepiej niż GeForce'y, o ile nie jest włączone ośmiokrotne wygładzanie krawędzi.

S.T.A.L.K.E.R.: Zew Prypeci DX 10.1

Ostatni S.T.A.L.K.E.R. korzysta ze zaktualizowanej wersji silnika X-Ray oznaczonej numerem 1.6. Test wykonujemy, mierząc FRAPS-em liczbę klatek na sekundę w czasie wycieczki dookoła bazy stalkerów znajdującej się na wraku łodzi, na początku gry.

Bardzo wyrównana walka z lekką przewagą GeForce'a. W końcu karty NVIDI-i mogą powalczyć w grach z tej serii z kartami AMD.

Battlefield: Bad Company 2 DX 11

Nowa Bad Company korzysta z bardzo niewielu funkcji DirectX 11. Nie mamy tu do czynienia ani z teselacją, ani DirectCompute. Dopiero w nadchodzącym silniku Frostbite 2.0 zostanie w pełni wykorzystane nowe API twórców Windows. Radeon HD 5870 radzi sobie odrobinę lepiej niż GeForce GTX 480.

Colin McRae: DiRT 2 DX 11

Po przejściu do trybu DirectX 11 zarysowuje się dość wyraźna, kilkunastoprocentowa przewaga GeForce'a nad Radeonem. Gra ta nie korzysta jakoś szczególnie intensywnie z teselacji i DirectCompute, ale to wystarczy, aby uwidoczniła się przewaga architektury NVIDI-i na tym polu.

Metro 2033 DX 11

O ile w trybie DirectX 10 różnica pomiędzy Radeonem HD 5870 a GeForce'em GTX 480 była stosunkowo nieduża, to w trybie DirectX 11... No cóż, nie ma czego porównywać. Widać tu idealnie gigantyczną wydajność GeForce'ów w obliczaniu geometrii i dużą efektywność w wykonywaniu obliczeń DirectCompute. Nawet Radeon HD 5970 nie ma tu za dużo do powiedzenia.

S.T.A.L.K.E.R.: Zew Prypeci DX 11

Następna gra DirectX 11 i znów bardzo duża (kilkudziesięcioprocentowa!) przewaga nowego GeForce'a nad Radeonem. Dalszy komentarz jest chyba zbędny.

Pobór mocy, głośność, temperatura

GeForce GTX 480 ma bardzo wysokie TDP, co powoduje uzasadnione obawy co do takich parametrów karty, jak pobór prądu, głośność i temperatura. Wiele się mówiło o problemach z wytwarzaniem nowych układów w fabrykach TSMC, z uzyskiem, z wyciekami itp., itd. Część obaw potwierdziła się i... Niestety, rzeczywistość jest gorsza, niż w nawet najbardziej pesymistycznych wizjach.

Zacznijmy od poboru energii:

To nie jest pomyłka. Nowy GeForce pobiera więcej energii niż GeForce GTX 295 i Radeon HD 5970, czyli karty z dwoma układami graficznymi. Także pobór w spoczynku jest spory. Karta pobiera też ponad 80 W więcej niż Radeon HD 5870, który przecież w grach DX 9 i DX 10 ma wydajność porównywalną z nowym GeForce'em. Wynik ten trochę nas dziwi, ponieważ GPU GTX-a 480 jest zasilany bardzo niskim napięciem: tylko 1 V (5870 – 1,175 V). Zresztą wygląda to tak, jakby NVIDIA zaniżała w specyfikacji prawdziwe TDP karty. No i mamy też jednego z głównych winowajców niezachwycającej wydajności nowej karty. NVIDIA nie mogła sobie pozwolić na szybsze zegary czy wykorzystanie wszystkich 512 rdzeni CUDA ze względu na i tak już bardzo wysoki pobór energii. Dodatkowo konieczność ustawienia niskiego napięcia zasilającego zmniejsza prawdopodobieństwo znalezienia w pełni funkcjonalnego kawałka krzemu, który mógłby działać z zadaną częstotliwością. Oczywiście, jest to model z najwyższej półki i jeśli ktoś wydaje na kartę graficzną prawie 2 tys. zł., to raczej nie przejmuje się zbytnio tym, ile energii pobiera. Ale chyba też nikt nie lubi zbędnych wydatków...

Tak wysoki pobór energii odbija się też na temperaturze działania i głośności wentylatora.

Jest gorąco. Bardzo gorąco. I głośno. Temperaturę mierzymy w Crysisie, a nie w żadnym Furmarku, a i tak temperatura GPU bez trudu przekracza 90 stopni. Po kilku godzinach testów w niektórych co bardziej grzejących GPU grach temperatura zbliżała się do 100 stopni. Do tego karta jest na tyle głośna, że może przeszkadzać nawet wtedy, gdy na uszach mamy słuchawki. Przebywanie w pomieszczeniu z obciążonym obliczeniami GeForce'em nie jest zbyt przyjemnym doznaniem.

Podkręcanie

Do podkręcania kart wykorzystaliśmy specjalną wersję programu EVGA Precision, która na razie jako jedyna umożliwia zmianę zegarów taktujących GTX-a 480.

Spodziewaliśmy się niezłej podkręcalności pamięci i niezbyt oszałamiającej układu graficznego. Okazało się, że pamięć nie chciała przyspieszyć bardziej niż do 1035 MHz – nadal sporo poniżej specyfikacji. Ponieważ zegar rdzenia jest połączony z zegarem jednostek cieniowania, kartę podkręcamy jednym suwakiem. Rdzeń udało nam się podkręcić do 800 MHz. Powyżej tej wartości dawało o sobie znać zabezpieczenie przeciwprądowe, które odcina zasilanie, gdy wykryje, że z układu zasilania płynie zbyt duża ilość prądu. Jest to pierwsza testowana przez nas karta, która ma taki problem przy podkręcaniu z użyciem chłodzenia powietrzem i bez zmiany napięcia. W Radeonie HD 5870, aby zabezpieczenie zadziałało, napięcie zasilania GPU musi wynosić około 1,45 V, a częstotliwość zegara taktującego rdzeń – około 1300 MHz.

Dodamy, że po podkręceniu karta zaczęła pobierać 33 W więcej.

Podsumowanie

Trzeba przyznać, że inżynierowie bardzo dobrze przemyśleli architekturę nowych produktów. Jest w niej kilka innowacyjnych rozwiązań. Myślimy, że prędzej czy później (stawiamy na prędzej) AMD też będzie musiało zwielokrotnić liczbę rasteryzatorów i teselatorów. Ale architektura musiała zostać ubrana w produkt, którym jest GeForce GTX 480. I tu zaczynają się schody, ponieważ nie wszystko jest takie, jak byśmy chcieli. Głównie chodzi nam o pobór energii i to, co się z nim wiąże: głośność i temperaturę. GeForce GTX 480 pobiera więcej energii niż Radeon HD 5970 i GeForce GTX 295 (o Radeonie HD 5870 nie wspominając), czyli karty z dwoma układami graficznymi. Oczywiście, jeśli ktoś kupuje kartę graficzną z najwyższej półki, przeważnie nie przejmuje się zbytnio jej prądożernością, ale nikt by się nie obraził, gdyby była „trochę” mniejsza. Karta jest bardzo gorąca. Temperatura rzędu 95 stopni Celsjusza to częsty widok. Lepiej nie wkładać tej karty do słabo wentylowanej obudowy. No i głośność. Karta jest na tyle głośna, że potrafi przeszkadzać nawet wtedy, gdy gramy ze słuchawkami na uszach. A tego już nikt nie lubi.

Wydajność budzi mieszane uczucia. Chciałoby się, aby GPU składający się z ponad trzech miliardów tranzystorów i potrzebujący aż tyle mocy dawał sporo wyższą wydajność. A z tym jest różnie. Oczywiście, GeForce GTX 480 nie jest wolniejszy od Radeona HD 5870, bo to byłaby tragedia. Jest szybszy, ale to, o ile jest szybszy, zależy od pewnego trudnego w ocenie czynnika: wersji DirectX. W grach korzystających z DirectX 9/10/10.1 lub OpenGL wydajność nowej karty NVIDI-i nie rzuca na kolana (biorąc pod uwagę pobór energii oraz liczbę tranzystorów): jest średnio kilka – kilkanaście procent wyższa od Radeona HD 5870 (chociaż zdarza się jej przegrać lub zremisować). Nie jest to zły wynik, ale nie tego oczekiwaliśmy od tego potwora.

Wszystko się jednak zmienia, gdy weźmiemy pod uwagę gry DirectX 11 korzystające z DirectCompute i teselacji. Dopiero tutaj widać cały potencjał tej architektury. Tam gdzie jest potrzebna duża moc przetwarzania geometrii i efektywne wykonywanie obliczeń, nowy GeForce rozwija skrzydła i zwiewa nimi konkurencję (która wielokrotnie podkreślała, od jak dawna ma w swoich kartach teselator i jak umiała go zaprojektować – ach, ta ironia losu!). Na czym polega problem? Na razie dostępnych jest pięć gier DirectX 11, które potrafią wykorzystać drzemiący w nowym GeForsie potencjał.

Stąd te mieszane uczucia. Z jednej strony jest 99,9% gier, w których GTX 480 współczynnikiem cena/wydajność i pobór energii/wydajność przegrywa (i to bardzo wyraźnie) z Radeonami HD 5870 i HD 5970. Z drugiej są obecne i przyszłe gry DirectX 11, w których tak naprawdę tylko nowy GeForce może zapewnić w miarę płynną rozgrywkę (przedsmak tego mamy w Metro 2033). Czyli teoretycznie jest to karta znacznie bardziej przyszłościowa. Teoretycznie, bo właściwie nie wiemy, ile w najbliższym czasie pojawi się gier DirectX 11. Sytuację polepsza nieco to, że większej wydajności kart graficznych będziemy teraz potrzebować praktycznie tylko w grach DirectX 11. Reszta zadowoli się znacznie słabszym sprzętem, więc nowość NVIDI-i będzie się kupowało właśnie pod kątem trybu DirectX 11. Ma ona jeszcze jedną zaletę: właściwie jest to pierwsza pojedyncza karta tego producenta, która bez problemu radzi sobie z jednoczesnym renderowaniem grafiki i PhysX-em, co dodaje kilka gier do listy tych, które za nią przemawiają.

Każdy musi się zastanowić, co jest dla niego ważne i czego oczekuje od swojego sprzętu. Trudno oprzeć się wrażeniu, że docelowa grupa odbiorców, którzy przymkną oko na wady tej karty ze względu na wydajność w trybie DirectX 11, nie będzie zbyt duża. Jest to przyszłościowa architektura, lecz wiele osób woli kupić coś, co dobrze spisuje się teraz, a dopiero po jakimś czasie pomyśleć o zmianie.

Teraz zapewne wszyscy zadają sobie pytanie, kiedy, gdzie i za ile będzie można kupić tę kartę. Okazuje się, że już dzisiaj będzie ona dostępna w kilku dużych polskich sklepach. Może nie będzie to jakaś ogromna liczba egzemplarzy, ale jeśli ktoś bardzo będzie chciał, to uda mu się kupić nowego GeForce'a za... 2000 zł (dzisiejsza cena w Komputroniku i Proline). Trzeba przyznać, że to sporo, ale w cenę jest wliczony tradycyjny u nas „podatek od nowości”. Karta powinna kosztować około 1800 zł, ale dopóki dostępność będzie ograniczona, dopóty cena nie będzie niższa. Z kolei GeForce GTX 470 będzie kosztował 1500 zł, czyli tyle co Radeon HD 5870, a nie HD 5850, z którym ma rywalizować pod względem wydajności.

Do testów dostarczył: NVIDIA

Cena w dniu publikacji (z VAT): 2000 zł