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

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ź.

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 .

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.

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.