Çok platformlu çoklu iş parçacığı: Asıl zorluklar nelerdir?

SDL gibi bir kütüphane, iş parçacığı için bir platformlar arası sarmalayıcı API sağlarken, bunun doğrudan farklı platformlarda (masaüstü / mobil) oyunların kolayca geliştirilmesine yol açtığını varsaymanın saf olacağını düşünüyorum.

Aşağıdakileri göz önünde bulundurarak (çapraz platform iş parçacığı API'ları verildiğinde) bu şekilde gelişmenin üstesinden gelmenin en iyi yolu nedir:

• farklı sayıda çekirdek
• Çekirdek başına çok farklı işlem yetenekleri
• Örneğin, genellikle farklı bir sistem mimarisi. önbellek, RAM ve G / Ç erişimi için farklı gecikmeler

Bunu yapmanın tek yolunun, desteklemeyi düşündüğünüz her cihaz için kaç iş parçacığının çalıştırılabileceğini değerlendirmek ve en düşük ortak paydanın ne olduğunu bulmak olduğunu hissediyorum. Bununla birlikte, bu, hala mevcut olan toplam işlem hacmiyle ilgili olarak beni karanlıkta bırakmaktadır. Bunu etkin bir şekilde yapmanın tek yolunun, geliştirme boyunca desteklemeyi düşündüğüm en düşük özellikli mobil cihaz için aktif olarak geliştirilmesi mi? - yani en düşük ortak payda? Bu kabaca yeterli olmalı mı ? Yoksa bundan daha fazlası var mı?

EDIT: Lütfen sorumun henüz tam olarak cevaplanmadığını hissetmediğim için başkaları bu konuda daha fazla deneyim sunabilir mi?

"Çok iş parçacıklı zorluklar" hakkında konuşuyorsunuz ama gerçekte hangi zorluklardan bahsediyorsunuz? Bir şekilde, hayali bir problemi bile varolmayabilir. Asıl zorluk, kendin için yapman gereken bir şey - kesinlikle donanımın her bir son damlasından kurtulmaya kararlıysanız, donanımı en iyi etki için kullanmayı gerektiren, ancak aynı zamanda en güçlü makine arasındaki boşluğu genişleten ve en az güçlü olan. Bunun bir anlamı, gerçekten PS3'ten en iyi şekilde yararlanan bir oyununuz varsa (örneğin), yine de ucuz bir cep telefonunda gerçekten çalıştıramazsınız, bu nedenle sorununuz artık "nasıl 1 program alabilirim?" çok farklı donanımlar üzerinde çalışmak "ama" farklı oyunlarda farklı güçlerle çalışan donanımlar üzerinde çalışabilmeleri için 1 oyun fikrini birkaç farklı yolla nasıl uygulayabilirim "olur.

SDL gibi bir kütüphane, iş parçacığı için bir platformlar arası sarmalayıcı API sağlarken, bunun doğrudan farklı platformlarda (masaüstü / mobil) oyunların kolayca geliştirilmesine yol açtığını varsaymanın saf olacağını düşünüyorum.

Oyunların kolay gelişimi - elbette. Optimal çoklu okuma, hayır. Ama yok gerek oyun yapmak mulithread. Yüksek performans elde etmek için kesinlikle yardımcı olur. Ancak birçok harika oyun tek bir iş parçacığında yayınlanıyor.

Aşağıdakileri göz önünde bulundurarak (çapraz platform iş parçacığı API'ları verildiğinde) bu şekilde gelişmenin üstesinden gelmenin en iyi yolu nedir:

• farklı sayıda çekirdek
• Çekirdek başına çok farklı işlem yetenekleri
• Örneğin, genellikle farklı bir sistem mimarisi. önbellek, RAM ve G / Ç erişimi için farklı gecikmeler

İş parçacıklarına sistem atamaya çalışmak yerine, iş parçacıklarına görevler atayabilirsiniz. Her göreve çalışması ve ihtiyaç duyduğu verileri, hangi donanımın mevcut olduğu ile ilişkilendirerek verin. Genellikle, çeşitli çekirdek veya işlemcileri soyutlamak için bir tür iş parçacığı havuzuna ve bir görev sırasına sahip olan ve iş parçacığı bir önceki işin tamamlandığını bildirdiğinde ve iş parçacığı işini bitirdiğinde çeşitli iş parçacıklarına yönlendiren bir görev yöneticisine sahip olacaksınız. yeni bir tane için hazır. Daha fazla çekirdeğe sahip donanım, işleri daha hızlı tamamlar ve daha hızlı bir şekilde işlem yapar. Bu sistemin farklı özelliklere sahip sistemlerde en iyi şekilde çalışması için uzmanlaşmak ileri bir optimizasyon problemi haline gelir, ancak belirli sezgisel taramalara dayanabilir (örneğin;

Bununla birlikte, oyun özelliklerinin ayrık görevlere ayrıştırılması oldukça karmaşık bir konudur ve performansa ihtiyacınız olduğundan emin olmadığınız sürece, çoğu zaman çabaya değmez, bu yüzden çoğu kişi bunu denemez.

Biraz daha okuma:

http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php - 'veri paralel' bölümüne bakın. Bu modelde, veriler birkaç benzer görev arasında bölünür ve bireysel konulara dağıtılır.

http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/ - oldukça yoğun, oyun seviyesinden ziyade işletim sistemi seviyesindeki şeyleri açıklar.

http://drdobbs.com/high-performance-computing/216500409 - oyuna özgü değil, görevleri nasıl bölmeniz gerektiğini söyleme açısından tamamen alakalı.

http://www.itfgaming.com/news/tech-focus-crysis-2-and-the-future-of-cryengine-3 - Bu görüşme aşağı yarı yolda bir görev tabanlı sistemine geçiş konusunda bir hadise olarak .

Mobil oyunlar yaptığımda ilk önce bir 'altın' versiyon geliştirdik (tam işlevli bir oyun) ve sonra 3 ana versiyona (büyük ekran, orta boy ve küçük ekran) ayırdık. Bunlar daha 11 versiyona çevrildi: zorlu grafikler (okuma çok fazla bellek / işlemci alır) vs düşük profilli vs. (bir çiftin özel platform versiyonları vardı).

En büyük sorun (diğerleri arasında benim işim olan) ihtiyaç duyulan platformları izole etmek ve bu sürümleri ve bunların nasıl oluşturulacağını belirlemek (örneğin, büyük ekran, ancak Düşük profil büyük ekran / yüksek profilin düşürülmüş bir sürümü olmalıydı ya da olmalıdır). orta boy ekran / lo profil büyük ekran yaptı?).

Elbette bunu aklımızda kodladık, böylece oyunlar ekran boyutuna çok gevşek bir şekilde iliştirildi.

HTH

[değiştir] Demek istediğim, hedef platformlarınızı farklı niteliklere (örneğin 1 çekirdekli, 2 çekirdekli, 1 çekirdekli, ancak iki kat hızlı) bölmeniz gerekiyordu. O zaman kaç sanal hedef istediğinize karar verin (örneğin " sadece bir "veya" Düşük, Orta, Yüksek ") Ardından tüm platformları kendi 'kalitelerine' yerleştirin ve Her kalite için en düşük paydayı alın ve kodu 'bu' şartlara uyacak şekilde kodlayın (yani çalışır ve hızlıdır) yeterli).

Bunu oldukça fazla tahminde bulunmanız gerekebilir gibi görünebilir, ancak en kötü platformda en kötü kaliteyi zaten bulabilirsiniz. Her sonraki kaliteyi birincisinden en az "iki katı kadar iyi" seçecektim, bu muhtemelen 3-4 "kaliteden" bahsetmekten daha fazla olmaz. Kod altın bir sürümden taşınırsa, yeterince iyi performans göstermeyen herhangi bir platform hızlandırmak için daha düşük bir 'kaliteye' uyarlanabilir. Herhangi bir yeni platform da kolayca doğru kalitede yerleştirilebilir.

Bunu yapmanın tek yolunun, desteklemeyi düşündüğünüz her cihaz için kaç iş parçacığının çalıştırılabileceğini değerlendirmek ve en düşük ortak paydanın ne olduğunu bulmak olduğunu hissediyorum.

Mutlaka gerekli değil - daha dinamik bir çözüm için umut olabilir, ancak bu, (varsa) çözmeye çalıştığınız asıl soruna bağlıdır. Sorunuzda biraz belirsizsiniz, bu yüzden cevabım da belirsiz olmalı.

Çalıştırmayı düşündüğünüz platformların gruplanması, bir API üzerinden donanım numaralandırma yeteneğine sahipse, sistemin kullanabileceği maksimum iş parçacığı sayısını saptamak için bu arabirimi kullanabilirsiniz ve uygulamanızın kaç iş parçacığı için temel olarak kullanabilirsiniz oluşturmanız gerekir. Buradaki tek zorluk bu API'leri bulmak; İşletim sistemi seviyesine gidip gitmediğiniz veya bir üçüncü taraf kütüphanesi veya çapraz platformlu bir SDK / API araması olup olmadığınız size bağlıdır ve desteklemeye çalıştığınız platformlara bağlıdır.

Aşağıdakileri göz önünde bulundurarak (çapraz platform iş parçacığı API'ları verildiğinde) bu şekilde gelişmenin üstesinden gelmenin en iyi yolu nedir:

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

önbellek, RAM ve G / Ç erişimi için gecikmeler

Benim düşünceme göre, bu şeylerin hiçbiri sizin endişeniz olmamalıdır. Endişen, oyununu geliştirmek olmalı. Eğer bir tıkanıklığa çarptıysanız ve işlemci yoğun bir işlem için ayrı bir iplik oluşturmanın daha iyi olacağına karar verirseniz, ipliğin yumurtlamasını sağlayın ve işletim sisteminin ve diğer alt seviye yazılımların iş parçacığını nasıl idare edeceğine karar vermesine izin verin.