MSI Big Bang Fuzion – test jedynej płyty głównej z układem Lucid Hydra 200

Hydra 200 – trochę teorii

Konfiguracje multi-GPU są już z nami trochę czasu i są dostępne rozwiązania zarówno firmy AMD, jak i NVIDIA. Zarówno w przypadku SLI, jak i CrossFire kolejne układy graficzne zajmują się renderowaniem oddzielnych klatek obrazu i wymieniają między sobą dane jedynie wtedy, gdy występują jakieś zależności między klatkami (na przykład następna klatka zależy od poprzedniej). Już raz pisaliśmy o zasadzie działania współczesnych rozwiązań multi-GPU, dlatego nie będziemy się powtarzać. Tym, co warto podkreślić, jest informacja, że zarówno ATI, jak i NVIDIA praktycznie porzuciły technikę SFR (ang. Split Frame Rendering), ponieważ algorytmy dzielenia pracy pomiędzy układy graficzne były bardzo skomplikowane i ciężko było osiągnąć wydajność choćby porównywalną z tym, co zapewnia AFR.

AFR pomimo swojej prostoty ma kilka wad. Podstawową jest konieczność tworzenia profilów, które dodają obsługę wielu kart graficznych w danej grze. Innym problemem jest synchronizacja. W idealnej sytuacji kolejne karty powinny renderować klatki w równych odstępach czasu, aby zachować płynność i aby to, co widzimy, wyglądało tak samo jak wyświetlane przez pojedynczą kartę graficzną. Niestety, często tak nie jest, czego objawem są mikroprzycięcia. Poza tym karty łączone w SLI czy CrossFire muszą mieć taką samą wydajność, aby była możliwa właściwa synchronizacja klatek, przez co nie jest możliwe łączenie ze sobą różnych kart graficznych (w przypadku CrossFire można łączyć karty o podobnej wydajności, na przykład Radeona HD 5850 z Radeonem HD 5870, ale już Radeona HD 5770 z HD 5870 – nie).

Tutaj do gry wchodzi nikomu wcześniej nieznana firma Lucid (której właścicielem jest teraz Intel) ze swoim rozwiązaniem o wdzięcznej nazwie Hydra. O tej technice słychać już od kilku miesięcy, ale dopiero teraz doczekała się oficjalnych narodzin i pierwszej odpowiednio przygotowanej płyty głównej. Lucid postanowił wrócić do rozwiązania polegającego na tym, że oddzielne karty graficzne zajmują się renderowaniem tej samej klatki animacji, czyli tego, na czym AMD i NVIDIA już jakiś czas temu postawiły krzyżyk. Jednak firma podeszła do tematu zupełnie inaczej. Zamiast dzielić ekran na kawałki (pasy albo kwadraty, jak to było we wcześniejszych implementacjach SFR) i kazać układom graficznym renderować konkretny zbiór pikseli, Hydra stara się wydawać układom graficznym rozkazy typu „ty wygeneruj ten obiekt, ty wygeneruj tamten, ty wygeneruj ten kawałek podłogi, a ja to poskładam do kupy” (w dużym uproszczeniu). Jest to rozwiązanie znacznie bardziej eleganckie niż przeprowadzenie poziomej linii przez ekran i wydanie rozkazu typu „ty wyrenderuj górne 700 pikseli, a ja wyrenderuję dolne 500”, ale też znacznie bardziej skomplikowane.

Jakie są główne problemy związane z dzieleniem pracy nad tą samą klatką animacji między różne układy graficzne? Można wymienić dwa. Pierwszy to równy podział pracy pomiędzy GPU. Drugi to zależności wewnątrz klatki. W obu przypadkach inżynierowie z Lucid sami postanowili utrudnić sobie życie.

Rozwiązaniem tych problemów zajmuje się połączenie własnego oprogramowania i własnego sprzętu. Główną część pracy wykonuje sterownik Hydry, który „wchodzi” pomiędzy grę a sterownik (lub sterowniki) kart graficznych. Analizuje on polecenia API (OpenGL lub DirectX) generowane przez grę, analizuje, co będzie renderowane, generuje drzewo zależności wewnątrzklatkowych, określa, czego dane zadanie wymaga od sprzętu. Po uzyskaniu takich informacji na temat renderowanej klatki animacji zaczyna się rozdzielanie zadań pomiędzy układy graficzne. Początkowo jest badana wydajność dostępnych układów graficznych, później klatka (a dokładniej: dane, które mają służyć do wyrenderowania klatki) jest rozdzielana na niezależne części, które według sterownika Hydry powinny zostać wyrenderowane w tym samym czasie. Tak przygotowane części oraz informacje o tym, co będzie renderowane, trafiają do sterowników kart graficznych, a czip na płycie głównej dodatkowo dba o to, aby każda karta dostała odpowiedni zestaw informacji. Warto w tym miejscu zwrócić uwagę na to, że o ile w zwykłych trybach SFR każda z kart dostawała cały zestaw danych do wyrenderowania klatki animacji, to tutaj karty dostają jedynie niezbędne minimum danych potrzebnych do wykonania przydzielonej im pracy, co znacznie zmniejsza zapotrzebowanie na przepustowość. Oprócz tego nie są wykonywane nadmiarowe obliczenia związane z geometrią. Gdy karty zakończą swoją pracę, finalna klatka jest składana w całość i zostaje wysłana do monitora.

Algorytm budujący drzewo zależności musi być wydajny i nie może się mylić. Karty muszą otrzymać całkowicie niezależne od siebie zbiory danych i nie może dochodzić do komunikacji między nimi. Każda pomyłka będzie obniżała skalowanie albo spowoduje, że jakiś obiekt na scenie nie będzie wyglądał jak należy.

Algorytm rozdzielający pracę pomiędzy układy jest oparty na danych pochodzących z kilku wcześniejszych klatek. Jest zapisywane, jak dany układ graficzny poradził sobie z danym zadaniem, i na podstawie tych informacji algorytm stara się odgadnąć, jak sobie poradzi z tym, co jest do zrobienia teraz.

Ilość pracy do wykonania wygląda imponująco, a najlepsze w tym jest to, że to wszystko musi być liczone w czasie rzeczywistym. Nie ma mowy o żadnych przestojach i zwiększeniu opóźnień. Ciężko uwierzyć, że to w ogóle działa, i nie ma co się dziwić, że NVIDI-i i AMD po prostu się nie chciało.

Do działania całości jest niezbędny dodatkowy chip znajdujący się pomiędzy mostkiem północnym a układami graficznymi. Oprócz roli przełącznika PCI Express zajmuje się on dekompozycją i składaniem w całość klatek oraz prawdopodobnie generowaniem kodu maszynowego, który otrzymują karty graficzne. Pracę tę wykonuje znajdujący się w krzemie procesor RISC taktowany zegarem 300 MHz, oparty na architekturze Tensilica Diamond.

Po co ta cała gimnastyka? Pierwszym celem jest pozbycie się profili do gier. Ponieważ Hydra mówi DirectX-em, który jest wspólny dla wszystkich kart i gier, nie ma potrzeby tworzenia profili i optymalizacji pod konkretną grę. Wszystko jest robione na bieżąco i jest „przezroczyste” dla gry i systemu. Drugim ważnym celem jest możliwość dynamicznego dzielenia pracy pomiędzy GPU pochodzące z innych rodzin, o różnej wydajności, a nawet wykonane przez różnych producentów. Jeśli algorytm dzielenia obciążenia byłby dobry, to byłoby możliwe łączenie ze sobą dowolnych kart graficznych i obserwowanie liniowego wzrostu wydajności. Po co to? Wyobraźcie sobie na przykład, że postanowiliście zmienić kartę graficzną. Macie Radeona HD 4870, ale chcecie więcej mocy, więc kupujecie Radeona HD 5870. Dzięki Hydrze, zamiast pozbyć się starej karty, można ją zaprząc do współpracy z nową i cieszyć się sporo wyższą wydajnością. Prawda, że fajna perspektywa? Jeśli do tego dorzucimy możliwość połączenia kart ATI i NVIDI-i, to daje nam to bardzo ciekawe perspektywy rozwoju sprzętu do grania.

A wady? Największą jest to, że jest to rozwiązanie w dużej mierze programowe. A oprogramowanie ma to do siebie, że lubi mieć błędy. Na przykład algorytm balansowania obciążenia może się pomylić, przez co wydajność może odbiegać od oczekiwań albo może dojść do przycinania się gry lub mikroprzycięć. Algorytm sprawdzający zależności też może się pomylić i może się okazać, że na ekranie występują różnego rodzaju błędy graficzne. Poza tym sterownik Hydry musi rozumieć wszystkie polecenia API i musi umieć „rozmawiać” ze sterownikiem i sprzętem. Z tego powodu zawsze będzie występowało lekkie opóźnienie we wprowadzaniu pewnych funkcji (na przykład obecna wersja sterownika Hydry, 1.4, nie obsługuje DirectX 11). Problemem jest też brak kompatybilności z nowymi sterownikami kart graficznych (na przykład sterownik w wersji 1.4 działa jedynie z ForceWare nie nowszymi niż 195.62). No i nowy sprzęt graficzny musi poczekać na nowy sterownik do Hydry. Jeśli ktoś postanowi kupić Fermiego zaraz po tym, jak się ukaże, to połączy go ze swoim GeForce'em GTX 285 dopiero po jakimś czasie, gdy zostanie wydana nowa wersja sterownika. Lucid obiecuje wydawanie większych aktualizacji sterowników co kwartał, a mniejszych wtedy, gdy zajdzie taka potrzeba. Zobaczymy, jak to będzie wyglądało w praktyce. I oczywiście brak profili nie oznacza, że Hydra poradzi sobie z każdą grą. Czasem sterownik może nie rozumieć, czego gra od niego chce, i pogubić się, przez co coś może nie działać. Z biegiem czasu zapewne będzie to coraz rzadsze zjawisko, ponieważ możliwości DirectX i OpenGL nie są nieograniczone, ale na początku może to być sporym problemem.

A teraz praktyka.