Jak przekonwertowano The Crew na PS4

I dlaczego PC jest tak ważne w nowej generacji.

Ubisoft Reflections podsumowało drugi dzień zeszłotygodniowej konferencji Develop 2013 intrygującym wykładem, zatytułowanym „Wskazówki i porady w konwertowaniu gier na nową generację”. Dla Digital Foundry prezentacja było o tyle istotna, że większość, a może nawet wszystkie produkcje, w które zagramy na PlayStation 4 i Xbox One pod koniec roku, wywodzą się właśnie z kodu napisanego z myślą o PC.

To intrygująca sytuacja, zwłaszcza dla graczy pecetowych z rozsądnie potężnym komputerem. Jeszcze niedawno to właśnie pecety były celem konwersji, często wykonywanej minimalnym nakładem pracy. Teraz PC jest platformą wiodącą. Tegoroczne E3 udowodniło, że dostęp do finalnych wersji produkcyjnych konsol jest nadal znikomy, a wiele tytułów zmierzających na nową generację prezentowano na komputerach.

Koncentracja na tej platformie ma sens, ponieważ produkcja gry trwa co najmniej dwa lata. Oznacza to, że niektóre firmy zaczęły tworzyć gry nowej generacji, gdy konsol nie było jeszcze na horyzoncie.

Obiecująca gry wyścigowa od Ubisoftu zadebiutowała na targach E3. Pokazywano fragmenty rozgrywki, działające na PC. To projekt byłych twórców Test Drive Unlimited, którzy założyli nowe studio - Ivory Tower - zajmujące się bazową wersją PC (podejrzewamy, że także edycją Xbox One). Co ciekawe, zespół techniczny z brytyjskiego Ubisoft Reflections zajmuje się wyłącznie konwersją na PS4, podczas gdy reszta pracowników z Newcastle tworzy dodatkową zawartość dla gry - dźwięki, skrypty, wyzwania oraz cały obszar stanu Teksas.

Dla zespołu odpowiedzialnego za wersję na PS4, wyzwanie jest raczej uciążliwe. Zadanie polega bowiem na skonwertowaniu kodu napisanego w całości przez inne studio i skompilowaniu go na sprzęt Sony, starając się uzyskać na ekranie jakiś obraz.

- Zaczęliśmy od dużej bazy kodu - było tego jakieś 12 tys. plików. Najpierw od silnika w Windows 64-bit, wykorzystującego D3D11 - mówi ekspert programistyczny z Reflection (tak, to autentyczna nazwa stanowiska), dr Chris Jenner.

- Ważne jest rozpoczęcie od wersji 64-bitowej, ponieważ PS4 to system 64-bitowy. Dobrze jest rozwiązać wszystkie problemy z systemami 32-bit/64-bit przed zajęciem się detalami na poszczególnych platformach. Naszym celem było stworzenie wersji równej osiągnięciom na PC.

Sony dużo mówiło o przystępności nowej platformy. Głównym elementem będzie tzw. „łańcuch narzędziowy”, czyli zestaw programów, które po kolei należy wykorzystać, by skompilować kod na PS4. Korzyścią dla deweloperów jest decyzja o użyciu dobrze znanego środowiska Visual Studio. Sony wyraźnie wspiera pracę firm tworzących gry na wiele platform - do kompilatora Sony dodano nawet specjalne opcje, usprawniające współpracę z odpowiednikiem Microsoftu, kompilującym gry z DirectX 11.

- Jednym z czynników, który ułatwił nam prace, było szerokie zastosowanie technologii zewnętrznych w silniku. Twórcy oprogramowania middleware byli bardzo aktywni na PS4, więc dostępne są odpowiednie wersje ich technologii - kontynuuje Jenner.

- Integracja całości zajmuje nieco czasu, gdy zestawy producenckie zmieniają się, by uwzględnić wymagane oprogramowanie zewnętrzne - czasem wydaję się, że to praca na cały etat. Ale gdy platforma w końcu zostaje doszlifowana, a zmiany w SDK są mniej znaczące, problem powoli się zmniejsza.

„Zaczęliśmy od dużej bazy kodu - było tego jakieś 12 tys. plików.”

Ważniejsze jest wykorzystanie 8GB RAM, znajdujące się w PS4. Ta ujednolicona pula oferuje znaczną przewagę nad PC i PS3, gdzie zasoby pamięci procesora i układu graficznego operują osobno. PS4 działa na bazie systemu, który alokuje pamięć do CPU lub GPU, z wykorzystaniem dwóch osobnych szyn.

- Jedna szyna danych nazywa się Cebula [ang. Onion], a druga Czosnek [ang. Garlic]. Cebula jest zmapowana przez pamięć cache procesora, co umożliwia CPU sprawny dostęp do pamięci RAM - wyjaśnia Janner.

- Czosnek omija cache CPU i ma bardzo wysoką przepustowość, odpowiednią dla zastosowań graficznych, które idą prosto przez GPU. Ważne jest myślenie o alokowaniu pamięci na bazie tego, co w niej umieszczamy.

Jenner nie zdradził szczegółów na temat przepustowości posiadanej przez obie szyny, tłumacząc się umową o poufności. Według naszych informacji, GPU może skorzystać z pełnego 176GB/s oferowanego przez 8GB GDDR5, właśnie dzięki Czosnkowi, podczas gdy Cebula operuje na zdecydowanie mniejszej prędkości, w okolicach 20GB/s (jeśli wierzyć analizie serwisu ExtremeTech).

Bez względu na ostateczną przepustowość Cebuli, Jenner twierdzi, że parametr jest „wystarczający”. Optymalizacja The Crew na potrzeby PS4, po skompilowaniu kodu, wymagała więcej pracy w zakresie zaplanowania, jakie dane umieścić w danym obszarze pamięci.

- Pierwszym problemem z wydajnością było nieprawidłowe alokowanie pamięci... Cebula jest dobra na sprawy systemowe i jest dostępna dla CPU. Czosnek jest lepszy w renderowaniu i może załadować dużo danych do GPU - opisuje Jenner.

- Jednym z problemów były shadery, które umieściliśmy w Czosnku. Kod musiał odczytać jakieś dane z tego shadera, a ponieważ informacje znajdowały się w Czosnku, odczyt był bardzo wolny, bo pamięć nie przechodziła przez cache procesora. Musieliśmy poradzić sobie z tym problemem już na początku; upewnić się, że wszystko jest w odpowiednich regionach. W przeciwnym razie, może to mocno spowolnić prace.

Elementy, takie jak główne zmienne gry, kluczowe dane shaderów i kluczowe cele renderowe (gotowe sceny 3D, wczytywane do pamięci pośredniej), kluczowe z punktu widzenia CPU, powinny być umieszczone w Cebuli, podczas gdy dane dotyczące GPU, jak dane tekstur i modeli, kod shaderów i większość celów renderowych znajduje się w szerszym Czosnku.

apu
W związku z umową o poufności, Reflections nie może mówić w detalach o przepustowości Czosnku i Cebuli, ale podejrzewamy, że powyższy diagram z serwisu ExtremeTech nie różni się znacząco od rzeczywistości. Warto zauważyć, że PS4 wyposażono w dwa układy Jaguar, łącznie składające się z ośmiu rdzeni, z czego dwa zarezerwowane są na system operacyjny.

Choć „łańcuch narzędziowy” zaprojektowano z myślą o deweloperach zaznajomionych z PC, sprzęt Sony nie wspiera bibliotek DirectX, które w PlayStation 4 zastąpiono autorskim rozwiązaniem.

- Biblioteka graficzna jest całkiem nowa, bez bagażu z przeszłości, więc całość jest dość przejrzysta, przemyślna i idealnie pasuje do sprzętu - zauważa inny ekspert programistyczny z Reflections, Simon O'Connor.

- Na najniższym poziomie znajduje się biblioteka nazwana GNM, oferująca niemal pełną kontrolę nad GPU, duży potencjał i dowolność w programowaniu. Kierowanie GPU na tak niskim poziomie wymaga jednak sporo pracy.

Sony mówiło o bibliotekach niskiego poziomu na konferencji GDC, ale nie chciało zdradzić nazwy rozwiązania, więc przynajmniej teraz ją znamy (odpowiednik w PS3 określano jako GCM). Ale co z kodem „otaczającym”, który ma ułatwiać prace deweloperom?

- Większość zaczyna od biblioteki GNMX, która otacza GNM i zajmuje się bardziej zaawansowanymi detalami w GPU, w sposób podobny do rozwiązań stosowanych w D3D11. Zaczęliśmy od dostępu wysokiego poziomu, ale ostatecznie zdecydowaliśmy się na biblioteki niskiego poziomu, ponieważ lepiej nadają się do naszych zastosowań- mówi O'Connor, wyjaśniając, że z GNMX pracuje się dużo łatwiej, ale w ten sposób usuwany jest swobodny dostęp do GPU i CPU.

Przejście na dostęp niskiego poziomu za pośrednictwem GNM było pracochłonne, a zespół zdał sobie sprawę, jak wiele z tej pracy wykonuje w tle DirectX, zajmując się alokacją pamięci. Przejście na GNM oznaczało, ze deweloperzy wszystkim musieli zająć się sami. O'Connor wyjaśnia:

- The Crew wykorzystuje niektóre funkcje D3D11, więc ten wycinek opcji jest łatwy do przeniesienia na potrzeby PS4. Ale PS4 jest konsolą, a nie pecetem, gdzie za wiele rzeczy odpowiada D3D. Oznacza to dużo więcej kombinowania, ale oferuje zdecydowanie więcej kontroli nad systemem.

Kolejną kluczową sferą są programowalne shadery. Doświadczenia Reflections sugerują, że system PlayStation Shader Language (PSSL) jest bardzo podobny do standardu HSLS z DirectX, z drobnymi różnicami, które zostały wyeliminowane w większości przypadków za pomocą specjalnych makr. Znaczącymi różnicami zajmuje się proces, który O'Connor określa jako „wyszukiwanie i zamienianie wyrażeń regularnych”.

„Podczas pokazu na E3, wersja PC działała w 30 klatkach na sekundę, ale pierwsza wersja skompilowana na PS4 nie radziła sobie tak dobrze, operując na poziomie ok. 10 FPS.”

Podczas pokazu na E3, wersja PC działała w 30 klatkach na sekundę, ale pierwsza wersja skompilowana na PS4 nie radziła sobie tak dobrze, operując na poziomie ok. 10 FPS.

- Zestaw deweloperski PS4 posiada bardzo fajne narzędzie do profilowania CPU, które pomogło nam w wykryciu „wąskich gardeł” w naszym kodzie - mówi Chris Janner, odnosząc się do narzędzia Sony o nazwie Razer.

- Nasza gra została zaprojektowana, by korzystać z dwóch wątków CPU. Jeden odpowiada za symulację, drugi za renderowanie scen. Oba działają równolegle. Następnie oba wątki mogą rozszerzyć się na dodatkowe procesory, działając równocześnie.

Bez zaskoczenia, „wąskim gardłem” był wątek odpowiedzialny za renderowanie, zwłaszcza w kwestii obsługi programowanych shaderów. Głównym problemem były „stałe”, czyli dane otrzymywane przez renderer, nie będące teksturami lub modelami, czyli np. informacje na temat umieszczenia obiektów w przestrzeni, kolor światła czy dokładne pozycje kości w szkielecie animowanego obiektu. Shader wymaga od kilkunastu do kilkuset danych tego typu, a biorąc pod uwagę, jak działają shadery we współczesnych grach, łatwo o problem „wąskiego gardła”.

- Mieliśmy kilka pomysłów, jak to rozwiązać. Jeden z nich polegał na zmniejszeniu czasu spędzonego na ustawianiu stałych w wątku renderującym. Innym rozwiązaniem było zbalansowanie ładowania pomiędzy poszczególne rdzenie - mówi Jenner, wyjawiając przy tym, że podobny proces był dużo łatwiejszy na PS3, gdzie wszystkie rdzenie CPU miały dostęp do głównej pamięci.

- Sprawdziliśmy także ustawienia stałych. GNMX - czyli silnik graficzny Sony - posiada komponent określany jako Constant Update Engine, który zajmuje się ustawianiem wszystkich stałych, mających przejść do GPU. To było dla nas zbyt wolne. Zajmowało dużo czasu pracy CPU. Teraz Sony usprawniło ten mechanizm w najnowszej wersji narzędzi producenckich. CUE jest dużo szybsze, ale podjęliśmy decyzję, że zajmiemy się tym sami, ponieważ mamy sporą wiedzę na temat naszego silnika i sposobu, w jaki uzyskuje dostęp do danych i kiedy elementy powinny być aktualizowane.

Z ogólnego punktu widzenia, wszystko wskazuje na to, że narzędzia deweloperskie są już na niemal docelowym poziomie, w odróżnieniu od Microsoftu, gdzie technologia nadal przechodzi spore zmiany, podyktowane lepszą przepustowością GPU. Zapytaliśmy Reflections, czy spodziewają się dalszej optymalizacji pracy dzięki zamianom w środowisku deweloperskim? Czy Sony nadal pracuje nad „sterownikiem” GPU?

- Narzędzia deweloperskie ciągle się zmieniają, ale w dużo mniejszym tempie niż chociaż pół roku temu - mówi Chris Jenner. - Zbliżamy się do końcowej fazy, nie spodziewamy się dużej poprawy w płynności, raczej doszlifowania funkcji. Całość jest dużo bardziej stabilna niż na początku. Od dłuższego czasu nie musieliśmy nic zmieniać.

Po zakończeniu prac nad podstawami konwersji, zespół z Ubisoft Reflections zbiera wszystkie siły, by ukończyć grę na premierę w I kwartale 2014 roku. Ale wysiłek inżynierski, wymagany do przeniesienia The Crew na PlayStation 4, wymagał jedynie dwóch-trzech osób i sześciu miesięcy pracy. Ogólnie, Reflections uważa, że proces konwersji kodu z PC był raczej prosty i mało skomplikowany.

Nie dowiedzieliśmy się jednak, jak wygląda wersja Xbox One i kto nad nią pracuje - zakładamy, że zajmuję się nią samo Ivory Tower, razem z edycją PC, a to ze względu na wykorzystanie bibliotek DirectX 11 na obu platformach. Ale Xbox One i PS4 mają dużo wspólnego pod względem architektury i nasze pytanie na temat współpracy obu zespołów konsolowych, skutkujące podobną optymalizacją na obu platformach, pozostaje bez odpowiedzi.

Simon O'Connor wspomniał, że zakres prac Reflections prawdopodobnie nie zakończy się na wykonaniu prostego portu. Proces produkcji oferuje możliwość sprawdzenia nowego sprzętu, zwłaszcza ze względu na przekonanie, że moc układu graficznego PS4 nie jest do końca wykorzystana.

- GPU w PS4 jest łatwo programowalne. Jest tu dużo mocy, której po prostu jeszcze nie wykorzystujemy. Chcemy więc wprowadzić kilka zmian specyficznych dla PS4, ale w granicach rozsądku - to gra multiplatformowa, więc nie możemy pójść za bardzo w kierunku funkcji zarezerwowanych dla PS4 - wyjaśnia.

- Przyglądamy się dwóm rzeczom - asynchronicznym obliczeniom, dzięki którym możemy prowadzić obliczenia równolegle. Inna kwestia to dostęp niskiego poziomu do sprzętu odpowiedzialnego za przetwarzanie fragmentów, co pozwala na zrobienie ciekawych rzeczy z wygładzaniem krawędzi i kilkoma innymi efektami...

Standardowy proces konwersji na początku ery X360/PS3 zdawał się polegać na wybraniu jednej platformy docelowej, a następnie na usunięciu funkcji na pozostałym sprzęcie, lub na pogodzeniu się z gorszą optymalizacją. Sprzęty nowej generacji są raczej celem konwersji , a nie platformami docelowymi - jasne jest, że oferują dużo więcej, a wiele można uzyskać dzięki wykorzystaniu specyficznych elementów architektury.

Jeśli Reflection rzeczywiście uzyska optymalizację na poziomie PC, a następnie dostosuje kod z myślą o mocnych stronach „super-doładowanego PC” od Marka Cerny'ego, to The Crew powinno być interesujące.

Reklama

Skocz do komentarzy (5)

O autorze

Richard Leadbetter

Richard Leadbetter

Technology Editor, Digital Foundry

Rich has been a games journalist since the days of 16-bit and specialises in technical analysis. He's commonly known around Eurogamer as the Blacksmith of the Future.

Powiązane materiały

Na stronie

Komentarze (5)

Komentarze zostały zamknięte.

Ukryj komentarze z niską oceną
Sortuj:
Wątki z odpowiedziami