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 .