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

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.