Rok 2006. Japoński gigant Sony przygotowuje się do wypuszczenia na rynek swojej trzeciej konsoli domowej – PlayStation 3. Po spektakularnym sukcesie PS2, który sprzedał się w ponad 155 milionach egzemplarzy, wydawało się, że Sony nie może popełnić błędu. Tymczasem w obozie konkurencji Microsoft ma już na koncie rok obecności z Xbox 360, który zyskał solidną bazę graczy i – co ważniejsze – znacznie prostszą architekturę. Szykowała się wojna, w której technologiczna wizja Sony miała okazać się zarówno największą siłą, jak i druzgocącą słabością.
W sercu tej historii leży procesor Cell Broadband Engine – układ zaprojektowany wspólnie przez Sony, Toshibę i IBM, który do dziś budzi skrajne emocje wśród deweloperów gier. Z jednej strony miał być rewolucyjnym arcydziełem, zdolnym do obliczeń porównywalnych z superkomputerami. Z drugiej – okazał się koszmarem programistycznym, który przez lata krzyżował plany twórcom i doprowadzał do technicznych kompromisów. „Trudny, ale potężny” – to zdanie stanowi esencję całej generacji PS3. Czas jednak przyjrzeć się, co dokładnie kryło się pod tą głośną etykietą i dlaczego Cell stał się symbolem ambicji, która niemal zgubiła Sony.
Spis treści
Architektura Cell Broadband Engine
Aby zrozumieć piekło programowania na PS3, trzeba najpierw pojąć, czym w ogóle był procesor Cell. W uproszczeniu – nie przypominał on niczego, do czego przywykli twórcy gier na PC czy poprzednich konsolach. Typowy procesor, nawet wielordzeniowy, działa na zasadzie kilku symetrycznych rdzeni radzących sobie ze wszystkim po trochu. Cell zaprojektowano zupełnie inaczej.
Jego sercem jest PPE (Power Processing Element) – dość konwencjonalny rdzeń oparty na architekturze PowerPC, działający z zegarem 3,2 GHz. To on zarządza całym systemem, obsługuje system operacyjny, rozdziela zadania i dba o logikę gry. Dotąd brzmi znajomo. Prawdziwa innowacja – i jednocześnie źródło cierpień – to osiem jednostek SPE (Synergistic Processing Elements). Wyobraźcie sobie małe, wyspecjalizowane fabryczki, każda z własnym, niewielkim obszarem roboczym (256 KB pamięci lokalnej), ale pozbawione bezpośredniego dostępu do głównej pamięci RAM konsoli (256 MB XDR). Aby SPE mogło coś obliczyć, PPE musiało ręcznie skopiować dane do jego pamięci lokalnej, uruchomić zadanie, a następnie odebrać wyniki.
IBM i Sony wierzyły, że to właśnie jest przyszłość obliczeń równoległych. W teorii osiem wyspecjalizowanych jednostek, każda zdolna do wykonywania prostych, ale bardzo szybkich operacji na liczbach zmiennoprzecinkowych (co istotne w grafice 3D, fizyce czy AI), mogło dać łączną wydajność sięgającą ponad 200 GFLOPS w precyzji pojedynczej. Dla porównania, procesor Xbox 360 (trzy symetryczne rdzenie PowerPC) osiągał około 115 GFLOPS. Marketingowo Sony mogło więc ogłosić, że PS3 jest „ponad dwukrotnie wydajniejsze” w teoretycznych obliczeniach. Rzeczywistość miała jednak okazać się znacznie bardziej brutalna.
Teoretyczna przewaga nad Xbox 360
Gdy porównamy specyfikacje CPU obu konsol, różnice są uderzające. Xbox 360 korzystał z procesora Xenon – trzech symetrycznych rdzeni PowerPC, każdy zdolny do obsługi dwóch wątków jednocześnie (SMT). Był to układ znacznie bliższy temu, co programiści znali z komputerów. Programowanie pod Xenon wymagało co prawda uwagi przy dzieleniu zadań między rdzenie, ale model był przewidywalny: każdy rdzeń miał dostęp do współdzielonej pamięci cache i głównej pamięci RAM.
Cell z kolei zmuszał do myślenia w kategoriach heterogenicznej architektury. PPE to master, SPE to wyspecjalizowani niewolnicy. Aby wykorzystać potencjał, trzeba było rozbić każdy skomplikowany algorytm na dziesiątki drobnych operacji, które mogłyby działać równolegle na SPE. Do tego dochodziła pamięć lokalna – 256 KB na SPE to ekstremalnie mało jak na dzisiejsze standardy, a w 2006 roku również było wyzwaniem. Wszystko, co nie mieściło się w tym ograniczeniu, musiało być nieustannie przeładowywane z głównej pamięci, co generowało opóźnienia.
Dlaczego więc Sony i IBM poszły w tym kierunku? U zarania projektu, w erze przed wielordzeniowością powszechną, inżynierowie zdali sobie sprawę, że klasyczne procesory coraz gorzej radzą sobie ze wzrostem taktowania (ograniczenia termiczne i energetyczne). Rozwiązaniem była równoległość – ale nie taka, jak w PC. Cell był eksperymentem myślowym: co by było, gdybyśmy stworzyli procesor złożony z jednego „mózgu” i wielu małych „pomocników” optymalnych do obliczeń numerycznych, kosztem łatwości programowania? W laboratoriach IBM wyniki testów pokazywały oszałamiające osiągi w zastosowaniach naukowych (np. kryptografia, analiza sygnałów). Sony uwierzyło, że gry również skorzystają na tej mocy. To był błąd.
Dlaczego programowanie pod Cell było tak trudne
Dla przeciętnego zespołu deweloperskiego w 2005-2006 roku, który właśnie kończył prace nad grami na PS2 (znanym już z trudnej architektury Emotion Engine), Cell okazał się szokiem. Oto najważniejsze problemy:
- Brak spójnego modelu pamięciowego. W normalnym CPU programista pisze kod, który swobodnie odczytuje i zapisuje dane w RAM. Kompilator i sprzęt dbają o to, aby wszystko działało poprawnie. Na SPE nie ma dostępu do głównej pamięci – trzeba jawnie kopiować dane poprzez komendy DMA (Direct Memory Access). To jakbyście prowadzili restaurację, ale każdy garnek musielibyście fizycznie przenosić z magazynu do kuchni, a następnie odstawiać z powrotem, zamiast po prostu sięgnąć po składnik.
- Ręczne zarządzanie zadaniami. Programista decydował, które SPE ma wykonać jakie obliczenia, i musiał pilnować synchronizacji – czyli tego, aby dane dotarły na czas, a żadne SPE nie czekało bezczynnie na wyniki od innego. Przy ośmiu jednostkach (z czego jedna była zablokowana przez FW na późniejszy etap życia PS3 , więc dostępnych było siedem) koordynacja stawała się logistycznym piekłem. Proste operacje, takie jak sortowanie listy obiektów czy aktualizacja fizyki, wymagały skomplikowanego kodu.
- Kompilatory i narzędzia. W pierwszych latach SDK (Software Development Kit) od Sony było niedopracowane, kompilatory generowały nieoptymalny kod dla SPE, a debugowanie równoległych procesów bez zaawansowanych profilerów graniczyło z cudem. Wielu deweloperów zdradzało publicznie, że spędzili miesiące na przepisywaniu kodu tylko po to, aby gra działała w 30 klatkach na sekundę, podczas gdy na Xbox 360 działała z 60 klatkami od pierwszego uruchomienia.
- Niska wydajność w grach nieoptymalizowanych. Jeśli twórcy po prostu przenosili kod z PC czy Xbox 360 bez głębokiej adaptacji do Cell, gra działała fatalnie – często tylko PPE był wykorzystany, a SPE stały bezczynnie. Efekt? Wolniejsze ładowanie tekstur, spadki frame rate’u, dłuższe czasy oczekiwania. Wczesne tytuły multiplatformowe były dla PS3 kompromitujące – wystarczy wspomnieć The Elder Scrolls IV: Oblivion (2006), gdzie wersja na Xbox 360 działała płynniej i oferowała lepszą ostrość obrazu.
Początki generacji PS3
Debiut PS3 w listopadzie 2006 roku był naznaczony nie tylko przepastną ceną 599 dolarów (wersja 60 GB), ale również technologicznymi bolączkami. Gry startowe, takie jak Resistance: Fall of Man od Insomniac Games, były chwalone za wizualną oprawę, ale już tytuły od zewnętrznych studiów cierpiały. Szczególnie widoczne stało się porównanie wersji Call of Duty 3 – na Xbox 360 gra osiągała stabilniejsze 30 klatek, na PS3 zdarzały się spadki do 20. Tony Hawk’s Project 8 miał na PS3 przeciętne 25-30 FPS wobec 60 na konkurencyjnej konsoli.
Deweloperzy publicznie narzekali. Gabe Newell z Valve (twórcy Half-Life i Steam) nazwał procesor Cell „całkowitą stratą czasu” i uznał, że programowanie na PS3 jest bezcelowe. Valve wydało później The Orange Box (2007) na PS3, ale wersja ta była technicznie tak słaba, że Newell przeprosił graczy i obiecał, że nigdy więcej nie będą współpracować z Sony, dopóki architektura się nie zmieni. Inne studia, jak Bungie, otwarcie przyznawały, że wybrały Xbox 360 jako platformę wiodącą dla Halo 3 i Destiny właśnie z powodu prostoty.
Produkcje zaczęły się wydłużać. Dla przykładu, Grand Theft Auto IV (2008) od Rockstar Games – gra wieloplatformowa – wymagała ogromnych nakładów na optymalizację pod Cell. Efekt końcowy był imponujący, ale kosztował dodatkowe miesiące pracy. W tym czasie Microsoft mógł świętować ujednolicone środowisko programistyczne (XNA) i łatwość przenoszenia gier z PC.
Oswajanie bestii
Mimo początkowych porażek, niektórzy programiści postanowili zmierzyć się z wyzwaniem. Stopniowo zaczęły powstawać biblioteki i silniki lepiej wykorzystujące SPE. Sony zainwestowało w szkolenia, poprawiło SDK i dostarczyło zaawansowanych profilerów. Powstała swoista kultura programowania na Cell – najlepsze studia uświadomiły sobie, że kluczem jest podział zadań na bardzo drobne, niezależne jednostki.
I tak, na przykład, jedno SPE mogło obsługiwać dekompresję tekstur w locie, drugie – obliczenia fizyki (np. symulację tkanin czy cząsteczek), trzecie – część algorytmów oświetleniowych, a czwarte – przetwarzanie dźwięku. PPE zajmowało się logiką gry i wysyłaniem komend do GPU (grafiką zajmował się osobny układ – RSX oparty na technologii Nvidii, ale to temat na inny artykuł). Z czasem twórcy nauczyli się również wykorzystywać SPE do przyspieszania AI – np. przeszukiwania drzew decyzyjnych w grach strategicznych.
Przełomowym momentem było pojawienie się silników takich jak PhyreEngine (wewnętrzne narzędzie Sony, później udostępnione za darmo) oraz dojrzałych wersji Unreal Engine 3. W 2009 roku różnice między wersjami multiplatformowymi zaczęły się zacierać, a w niektórych przypadkach PS3 nawet wyprzedzało Xbox 360 – np. Bayonetta (2009) miała na PS3 poważne problemy z framerate’em, ale późniejsze łatki i wersje (jak Portal 2 z 2011 roku) już działały dobrze.
Najlepsze studia pierwszej i drugiej strony Sony – Naughty Dog, Guerrilla Games, Sucker Punch, Santa Monica Studio – zaczęły traktować Cell jako wyjątkowe narzędzie. Zrozumiały, że aby wydobyć z niego to, co najlepsze, trzeba projektować gry od podstaw pod architekturę, a nie portować z PC. Tak narodziły się dzieła, które do dziś zadziwiają techniczną maestrią.
Case study: The Last of Us – ostatni taniec z Cell
Kiedy w czerwcu 2013 roku, na kilka miesięcy przed premierą PlayStation 4, Naughty Dog wypuściło The Last of Us, świat zadrżał. Nie tylko ze względu na genialną opowieść i postacie, ale również poziom graficznej dopięcia na starzejącym się już sprzęcie. PS3 miało zaledwie 256 MB pamięci RAM na aplikacje i 256 MB pamięci wideo. Dla porównania, PC w tamtym czasie operowały już 4-8 GB. Jak to możliwe, że The Last of Us wyglądał i działał tak dobrze?
Odpowiedź leży w mistrzowskim wykorzystaniu Cell. Twórcy opracowali zaawansowany system strumieniowania danych (streaming), który wczytywał tekstury i geometrię w locie, podczas gdy gracz się poruszał. To SPE – a nie PPE – zarządzało tym procesem. Jedno SPE dekompresowało dane z dysku Blu-ray (który był powolny, bo napęd DVD w Xbox 360 pozwalał na szybszy dostęp losowy, ale Blu-ray oferował większą pojemność). Inne SPE zajmowało się obliczeniami animacji postaci w czasie rzeczywistym (m.in. system „motion matching”). Kolejne przygotowywało bufory dla GPU.
Co najważniejsze, Naughty Dog zbudowało własny silnik (wcześniejszy z Uncharted 2 i 3), który był w stanie dynamicznie alokować zadania do SPE w zależności od obciążenia. W jednej chwili SPE mogło liczyć cząsteczki pyłu, w następnej – pomagać w oświetleniu globalnym. To było jak dyrygowanie orkiestrą, w której każdy muzyk potrafi grać na wielu instrumentach.
Efekt? The Last of Us działał w stabilnych 30 klatkach na sekundę (z drobnymi spadkami w najbardziej wymagających scenach), oferując detale, które śmiało konkurowały z wczesnymi grami na PS4. Do dziś jest to przykład tego, jak architektura uznawana za „przekleństwo” może stać się błogosławieństwem, jeśli poświęci się jej odpowiednio dużo czasu i talentu. Kontrast względem wczesnych tytułów startowych PS3 (jak Ridge Racer 7 czy Genji: Days of the Blade) jest uderzający – niemal jak dwie różne generacje konsol.
Podsumowując zatem…
Procesor Cell Broadband Engine był bez wątpienia jednym z najbardziej fascynujących eksperymentów w historii konsol. Sony i IBM postawiły wszystko na heterogeniczną równoległość, wierząc, że programiści dostosują się do wyzwania. Z perspektywy czasu widać, że było to wyprzedzenie epoki o dobrą dekadę – dziś, w dobie procesorów z dziesiątkami rdzeni (nawet w konsolach), specjalizowane jednostki (NPU, tensor core, jednostki AI) stają się normą. Jednak w 2006 roku ekosystem, narzędzia i mentalność deweloperów nie były gotowe.
Bilans Cell jest gorzko-słodki. Z jednej strony sprawił, że pierwsze lata PS3 były technologiczną porażką – droższa konsola oferująca gorsze wersje gier multiplatformowych, przedłużone cykle produkcyjne i wściekłych twórców. Z drugiej strony, gdy odpowiednie studia (jak Naughty Dog czy Guerrilla Games) oswoiły bestię, wycisnęły z niej rzeczy nieosiągalne na prostszym, choć wydajniejszym na starcie Xenonie z Xbox 360. Dziś w kręgach retro entuzjastów Cell ma status legendy – trudnej, wymagającej, ale szalenie satysfakcjonującej dla tych, którzy podjęli rękawicę.
Wpływ PS3 na przyszłe konsole jest oczywisty. Projektując PlayStation 4, Sony totalnie odrzuciło koncepcję egzotycznej architektury. Powrócono do sprawdzonego x86 (podobnie jak w PC), a programistom dostarczono proste narzędzia. Lekcja została odrobiona: potęga obliczeniowa nie ma sensu, jeśli deweloperzy nie są w stanie jej efektywnie wykorzystać. I choć przez to ucierpiała część wczesnej biblioteki PS3, a sama konsola nigdy nie dogoniła sprzedażowo PS2 (sprzedała się w około 87 milionach egzemplarzy, wciąż sukces), to Cell pozostaje symbolem – czasem, by stworzyć coś przełomowego, trzeba najpierw przejść przez piekło. Nawet jeśli to piekło trwało pięć długich lat.
