Wieloplatformowe wielowątkowość: jakie są prawdziwe wyzwania?


21

Podczas gdy biblioteka taka jak SDL zapewnia wieloplatformowy interfejs API do tworzenia wątków, myślę, że naiwnością byłoby zakładać, że prowadzi to bezpośrednio do łatwego rozwoju gier na bardzo różnych platformach (stacjonarnych / mobilnych).

Jaki jest najlepszy sposób radzenia sobie z programowaniem w ten sposób (biorąc pod uwagę dowolny wieloplatformowy interfejs API do wątkowania), biorąc pod uwagę następujące kwestie:

  • różna liczba rdzeni
  • bardzo różne możliwości przetwarzania na rdzeń
  • Zasadniczo inna architektura systemów z np. różne opóźnienia dla pamięci podręcznej, pamięci RAM i dostępu we / wy

Mam wrażenie, że jedynym sposobem na to jest ocena, ile wątków można uruchomić na każde urządzenie, które zamierzasz obsługiwać, i dowiedzieć się, jaki jest najniższy wspólny mianownik. Jednak to wciąż pozostawia mnie w ciemności, jeśli chodzi o całkowitą dostępną przepustowość przetwarzania. Czy mam rację, zakładając, że jedynym sposobem na to skutecznie jest aktywne opracowywanie urządzenia mobilnego o najniższej specyfikacji, które zamierzam wspierać przez cały okres programowania? - tj. najniższy wspólny mianownik? Czy powinno to z grubsza wystarczyć? Czy jest w tym coś więcej?

EDYCJA: Proszę, czy inni mogą zaoferować dalsze doświadczenia w tej sprawie, ponieważ nie sądzę, aby na moje pytanie została jeszcze w pełni udzielona odpowiedź.


Ponieważ moja odpowiedź nie w pełni odpowiada na twoje pytanie, czy mógłbyś szczegółowo opisać to, czego brakuje / co chcesz wiedzieć? Może nie jestem świetnym pisarzem, ale poradziłem sobie z tego rodzaju problemami więcej niż raz.
Valmond,

Naprawdę nie odpowiedziałeś na pytanie, które dotyczyło trudności związanych z wielowątkowością i sposobu ich przezwyciężenia podczas opracowywania platform z różnymi możliwościami wątkowania . Zobacz mój akapit poniżej punktorów. Mówisz o rozmiarach i rozdzielczościach ekranu - nie mają one nic wspólnego z moim pytaniem - przeczytaj tytuł.
Inżynier

1
Myślę, że trudność wynika z tego, do czego chcesz użyć wątków. Jedną rzeczą jest, aby wątek pomocniczy robił coś z boku, a zupełnie inną próbą wyciśnięcia ostatnich kawałków wydajności z 8-rdzeniowej maszyny. Z mojego punktu widzenia wątki SDL są przeznaczone głównie do pierwszego, nie ten drugi.
Jari Komppa,

Odpowiedzi:


11

Mówisz o „trudnościach z wielowątkowością”, ale o jakich trudnościach faktycznie mówisz? W pewnym sensie cytujesz problem fantomowy, który może nawet nie istnieć. Prawdziwe wyzwanie należy do siebie - jeśli jesteś absolutnie zdeterminowany, aby z każdej części sprzętu wydobyć ostatnią kroplę mocy, wiąże się to z optymalnym wykorzystaniem sprzętu, ale także powiększa lukę między najpotężniejszą maszyną i najmniej potężny. Implikacja tego jest taka, że ​​jeśli masz grę, która naprawdę w pełni wykorzystuje PS3 (na przykład), tak naprawdę nie możesz uruchomić jej na tanim telefonie komórkowym, więc twoim problemem nie jest już „jak mogę uzyskać 1 program pracować na bardzo różnych urządzeniach ”, ale„ jak mogę wdrożyć 1 pomysł na grę na kilka różnych sposobów, aby działał na sprzęcie o różnej mocy ”.

Podczas gdy biblioteka taka jak SDL zapewnia wieloplatformowy interfejs API do tworzenia wątków, myślę, że naiwnością byłoby zakładać, że prowadzi to bezpośrednio do łatwego rozwoju gier na bardzo różnych platformach (stacjonarnych / mobilnych).

Łatwy rozwój gier - na pewno. Optymalny wielowątkowość, nie. Ale nie potrzebujesz wielowątkowości, aby tworzyć gry. Aby stworzyć te o wysokiej wydajności, z pewnością pomaga. Ale wiele świetnych gier działa w jednym wątku.

Jaki jest najlepszy sposób radzenia sobie z programowaniem w ten sposób (biorąc pod uwagę dowolny wieloplatformowy interfejs API do wątkowania), biorąc pod uwagę następujące kwestie:

  • różna liczba rdzeni
  • bardzo różne możliwości przetwarzania na rdzeń
  • Zasadniczo inna architektura systemów z np. różne opóźnienia dla pamięci podręcznej, pamięci RAM i dostępu we / wy

Zamiast próbować przypisywać systemy do wątków, przypisuj zadania do wątków. Podaj każdemu zadaniu dane, które są potrzebne do uruchomienia, i rozprowadź zadania na dowolnym dostępnym sprzęcie. Zwykle masz jakąś pulę wątków, aby wyodrębnić różne rdzenie lub procesory, oraz menedżera zadań, który ma kolejkę zadań i podaje je do różnych wątków, gdy wątek sygnalizuje, że zakończyło poprzednie zadanie i jest gotowy na nowy. Sprzęt z większą liczbą rdzeni oczywiście szybciej wykona zadania i będzie mógł szybciej renderować. Specjalizacja tego systemu do optymalnej pracy z systemami o różnych właściwościach staje się zaawansowanym problemem optymalizacji, ale może być oparta na pewnych heurystykach (np. Zadanie, które nie wykonuje

Jednak rozkład funkcji gry na odrębne zadania jest dość złożoną sprawą i często nie jest wart wysiłku, chyba że masz pewność, że potrzebujesz wydajności, więc większość nawet nie spróbuje.

Dalsza lektura:

http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php - patrz sekcja „równoległe przesyłanie danych”. W tym modelu dane są dzielone na kilka identycznych zadań i rozdzielane na poszczególne wątki.

http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/ - dość gęsty, opisuje rzeczy na poziomie systemu operacyjnego, a nie na poziomie gry.

http://drdobbs.com/high-performance-computing/216500409 - nie jest specyficzny dla gry, ale całkowicie istotny pod względem informowania Cię, jak należy podzielić zadania.

http://www.itfgaming.com/news/tech-focus-crysis-2-and-the-future-of-cryengine-3 - w połowie tego wywiadu jest anegdotą na temat migracji do systemu zadaniowego .


Bardzo dobre punkty. I prawda, użyłem słowa „trudności”, gdy „wyzwania” byłyby bardziej dokładne. Powiedziałeś: „Rozkład funkcji gry na odrębne zadania jest dość złożoną sprawą i często nie jest wart wysiłku, chyba że masz pewność, że potrzebujesz wydajności, więc większość nawet nie spróbuje”. Czy możesz to rozwinąć? Zapewnić źródła? To trochę niejasne, ale powiedziałbym, że dochodzisz do sedna sprawy.
Inżynier

Przepraszam, myślałem, że takie podejście jest dobrze znane. Rozwiążę odpowiedź.
Kylotan,

4

Kiedy tworzyłem gry mobilne, najpierw opracowaliśmy wersję „złotą” (tj. W pełni funkcjonalną), a następnie podzieliliśmy ją na 3 główne wersje (duży ekran, średniej wielkości i mały ekran). Te zostały następnie przekonwertowane na 11 wersji: wymagająca grafika (odczyt zajmuje dużo pamięci / procesora) w porównaniu z niskim profilem itp. (Istniało też kilka specjalnych wersji platform).

Największym problemem było (to było między innymi moje zadanie) wyodrębnienie potrzebnych platform i określenie tych wersji oraz sposobu ich tworzenia (tj. Duży ekran, ale Niski profil powinien być obniżoną wersją profilu dużego ekranu / hi powinien być profil średniego ekranu / lo zrobiony duży ekran?).

Oczywiście kodowaliśmy to z myślą o tym, aby gry były bardzo luźno związane z rozmiarem ekranu.

HTH

[edytuj] Chodziło mi o to, że musisz podzielić platformy docelowe na różne jakości (tj. 1 rdzeń, 2 rdzenie, 1 rdzeń, ale dwa razy szybciej ...) Następnie zdecyduj, ile chcesz wirtualnych celów (na przykład „ only one ”lub„ Low, Mid, Hi ”) Następnie umieść wszystkie platformy w odpowiedniej„ jakości ”i dla każdej jakości weź najniższy mianownik i„ przenieś ”kod, aby spełniał te wymagania (tj. działa i jest szybki wystarczająco).

Może się wydawać, że musisz to zrobić z dużą ilością domysłów, ale już najgorszą jakość można znaleźć na najgorszej platformie. Wybrałbym każdą kolejną jakość co najmniej „dwa razy lepiej” niż poprzednia, prawdopodobnie nie wygenerowałoby to więcej niż powiedzenie 3-4 „jakości”. Jeśli kod zostanie przeniesiony ze złotej wersji, każda platforma, która nie działa wystarczająco dobrze, może zostać po prostu przywrócona do niższej „jakości”, aby przyspieszyć. Każdą nową platformę można również łatwo ustawić w odpowiedniej jakości.


Jak myślisz, ile czasu można by poświęcić, aby projekt obejmował zarówno fazę projektowania, jak i rozwoju, aby pomieścić taką wieloplatformową wersję? Pomogłaby tylko przybliżona średnia.
Inżynier,

1
Cóż, ponieważ zrobiliśmy wiele języków (angielski, francuski, hiszpański, portugalski, niemiecki i włoski w paczce + niezależnie od potrzebnego dnia, tajwański, turecki, rosyjski ...) i mieliśmy nowe platformy, których potrzebowaliśmy do „portowania” wszystkie nasze gry co kilka miesięcy (przeczytaj nową klasę telefonów komórkowych), tak naprawdę stracilibyśmy dużo czasu, nie idąc w ten sposób, to byłoby naprawdę niemożliwe bez naprawdę dużego tema. Projekt „frameworka” został wykonany w biegu, gdy dowiedziałem się o różnych telefonach komórkowych i dojrzałem po około 3-4 latach. Warto jednak zainwestować.
Valmond,

1

Mam wrażenie, że jedynym sposobem na to jest ocena, ile wątków można uruchomić na każde urządzenie, które zamierzasz obsługiwać, i dowiedzieć się, jaki jest najniższy wspólny mianownik.

Niekoniecznie - może być nadzieja na bardziej dynamiczne rozwiązanie, ale zależy to od rzeczywistego problemu, który próbujesz rozwiązać (jeśli występuje). Jesteś trochę niejasny w swoim pytaniu, więc moja odpowiedź również musi być niejasna.

Jeśli grupa platform, na których zamierzasz uruchomić, ma możliwość wyliczenia sprzętowego za pośrednictwem interfejsu API, możesz użyć tego interfejsu do wykrycia maksymalnej liczby wątków, które system może obsłużyć, i użyć go jako podstawy liczby wątków aplikacji powinien stworzyć. Jedynym wyzwaniem jest znalezienie tych interfejsów API; niezależnie od tego, czy przejdziesz na poziom systemu operacyjnego, czy poszukasz biblioteki innej firmy, czy wieloplatformowego zestawu SDK / API zależy od Ciebie i zależy od platform, które próbujesz obsłużyć.

Jaki jest najlepszy sposób radzenia sobie z programowaniem w ten sposób (biorąc pod uwagę dowolny wieloplatformowy interfejs API do wątkowania), biorąc pod uwagę następujące kwestie:

different numbers of cores
vastly different processing capabilities per core
A generally different systems architecture with eg. different

opóźnienia dla pamięci podręcznej, pamięci RAM i dostępu we / wy

Moim zdaniem żadna z tych rzeczy nie powinna Cię dotyczyć. Twoim zmartwieniem powinno być budowanie gry. Jeśli trafisz na wąskie gardło i zdecydujesz, że lepiej byłoby odrodzić osobny wątek dla konkretnego zadania wymagającego intensywnego procesora, a następnie odrodzić wątek i pozwól systemowi operacyjnemu i innemu oprogramowaniu niższego poziomu zdecydować, jak manipulować sprzętem w celu obsługi wątkowania.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.