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

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.