Багатоплатформна багатопотокова передача: Які реальні проблеми?

Хоча бібліотека на зразок SDL надає міжплатформову програму для обгортання ниток, я думаю, що було б наївно вважати, що це призводить безпосередньо до простого розвитку ігор на абсолютно різних платформах (настільних / мобільних).

Який найкращий спосіб вирішити цей спосіб (враховуючи будь-який міжпластовий інтерфейс API), враховуючи наступне:

• різна кількість ядер
• дуже різні можливості обробки на ядро
• Взагалі інша архітектура систем з напр. різні затримки для кешу, оперативної пам’яті та доступу вводу / виводу

У мене виникає відчуття, що єдиний спосіб зробити це - оцінити, скільки потоків може працювати на кожному пристрої, який ви маєте намір підтримувати, і дізнатися, який найменший загальний знаменник. Однак це все ще залишає мене в темряві щодо загальної кількості доступної пропускної спроможності. Я маю рацію припустити, що єдиний спосіб зробити це ефективно - це активно розробляти мобільний пристрій з найнижчою специфікою, який я маю намір підтримувати протягом усієї розробки? - тобто найменший загальний знаменник? Чи приблизно цього має бути достатньо? Або в цьому є більше, ніж у цьому?

EDIT: Будь ласка, чи не могли б інші запропонувати додатковий досвід щодо цього, оскільки я ще не відчуваю, що на моє запитання відповіли повністю.

Ви говорите про "багатопотокові труднощі", але про які труднощі ви насправді говорите? Таким чином, ви посилаєтесь на фантомну проблему, яка може навіть не існувати. Справжнє завдання - це те, що ви робите для себе - якщо ви абсолютно налаштовані отримувати кожну останню краплю енергії з обладнання, це вимагає використання обладнання для найкращого ефекту, але це також розширює розрив між найпотужнішою машиною і найменш потужний. Наслідком цього є те, що якщо у вас є гра, яка справді найбільше використовує PS3 (наприклад), ви все одно не можете її запустити на дешевому мобільному телефоні, тому ваша проблема вже не "як я можу отримати 1 програму працювати над різним обладнанням ", але стає" як я можу реалізувати одну ідею гри декількома різними способами, щоб вона працювала на апаратному забезпеченні з різним харчуванням ".

Хоча бібліотека на зразок SDL надає міжплатформову програму для обгортання ниток, я думаю, що було б наївно вважати, що це призводить безпосередньо до простого розвитку ігор на абсолютно різних платформах (настільних / мобільних).

Легкий розвиток ігор - точно. Оптимальна багатопотокова, ні. Але для створення ігор вам не потрібно багатопотокове читання. Щоб зробити якісні продуктивні, це безумовно допомагає. Але багато чудових ігор працює в одну нитку.

Який найкращий спосіб вирішити цей спосіб (враховуючи будь-який міжпластовий інтерфейс API), враховуючи наступне:

• різна кількість ядер
• дуже різні можливості обробки на ядро
• Взагалі інша архітектура систем з напр. різні затримки для кешу, оперативної пам’яті та доступу вводу / виводу

Замість того, щоб намагатися призначити системи потокам, призначте завдання потокам. Надайте кожному завданню необхідні йому дані для виконання та обробку завдань, залежно від необхідного обладнання. Зазвичай у вас буде якийсь пул потоків, щоб абстрагувати різні ядра чи процесори, і диспетчер завдань, який має чергу завдань і підводить їх до різних потоків, коли потік сигналізує про те, що завершено попереднє завдання і є готовий до нового. Обладнання з більшою кількістю ядер, очевидно, швидше виконає завдання та зможе швидше рендерувати. Спеціалізація цієї системи для оптимальної роботи на системах з різними характеристиками стає вдосконаленою проблемою оптимізації, але може ґрунтуватися на певній евристиці (наприклад, завдання, яке не відповідає "

Однак, розкладання ігрових особливостей на дискретні завдання є досить складною справою і часто не варто докладати зусиль, якщо ви не впевнені, що вам потрібна продуктивність, тому більшість навіть не намагатиметься цього зробити.

Деякі подальші читання:

http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php - див. розділ "Паралель даних". З цією моделлю дані поділяються на кілька однакових завдань і обробляються окремими потоками.

http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/ - досить щільний, описує речі на рівні ОС, а не на рівні гри.

http://drdobbs.com/high-performance-computing/216500409 - не конкретна гра, але цілком доречна з точки зору того, як розповісти, як потрібно розділити завдання.

http://www.itfgaming.com/news/tech-focus-crysis-2-and-the-future-of-cryengine-3 - на півдорозі інтерв'ю - це анекдот про те, як вони перейшли на систему, засновану на завданнях .

Коли я робив мобільні ігри, ми спочатку розробили «золоту» версію (тобто повністю функціональну гру), а потім розділили її на 3 основні версії (великий екран, середній розмір та маленький екран). Далі вони були перетворені на 11 версій: вимоглива графіка (читання займає багато пам’яті / процесор) порівняно з низьким рівнем профілю тощо (також були спеціальні версії платформи для пари).

Найбільшою проблемою було (це було моєю роботою серед інших), щоб виділити необхідні платформи та визначити ці версії та як їх створити (т. Е. Великий екран, але низький профіль повинен бути зменшеною версією великого екрана / привітання профілю чи повинен бути екран середнього розміру / lo зроблений великий екран?).

Звичайно, ми це задумали, тому ігри були дуже вільно прикріплені до розміру екрана.

HTH

[ред.] Я мав на увазі те, що вам потрібно розділити цільові платформи за різними якостями (наприклад, 1 ядро, 2 ядра, 1 ядро, але вдвічі швидше ...), а потім вирішите, скільки віртуальних цілей ви хочете (наприклад, " лише один "або" Низький, середній, привіт ") Потім розмістіть усі платформи у відповідній" якості "і для кожної якості візьміть найнижчий знаменник і" порт "код, щоб він відповідав цим вимогам (тобто працює і швидко достатньо).

Може здатися, що ви повинні робити це з досить багато здогадок, але ви вже можете знайти найгіршу якість з найгіршою платформою. Я б вибрав кожну наступну якість, принаймні "вдвічі кращу", ніж попередню, це, мабуть, не призведе до того, що б сказати 3-4 "якості". Якщо код перенесений із золотої версії, будь-яка платформа, яка не працює досить добре, може бути просто модернізована до нижчої «якості», щоб пришвидшити її. Будь-яку нову платформу можна також досить легко розмістити в потрібній якості.

У мене виникає відчуття, що єдиний спосіб зробити це - оцінити, скільки потоків може працювати на кожному пристрої, який ви маєте намір підтримувати, і дізнатися, який найменший загальний знаменник.

Не обов’язково - може бути надія на більш динамічне рішення, але це залежить від реальної проблеми, яку ви намагаєтеся вирішити (якщо вона є). Ви трохи розпливчасті у своєму питанні, тож моя відповідь має бути і невиразною.

Якщо групування платформ, на яких ви збираєтеся запустити, має можливість перерахування апаратних засобів через API, ви можете використовувати цей інтерфейс для виявлення максимальної кількості потоків, з якими система може обробляти, і використовувати це як основу для кількості потоків вашої програми повинні створити. Єдиною проблемою тут є пошук цих API; незалежно від того, переходите ви на рівень ОС або шукаєте сторонні бібліотеки, або кросплатформний SDK / API залежить від вас і залежить від платформ, які ви намагаєтеся підтримувати.

Який найкращий спосіб вирішити цей спосіб (враховуючи будь-який міжпластовий інтерфейс API), враховуючи наступне:

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

затримки для кешу, оперативної пам’яті та доступу вводу / виводу

На мою думку, жодна з цих речей не повинна викликати ваших проблем. Ваша турбота повинна бути побудовою вашої гри. Якщо ви потрапили у вузьке місце і вирішите, що було б краще проробити окрему нитку для конкретного завдання, що вимагає процесора, тоді породжуйте нитку і нехай ОС та інше програмне забезпечення нижчого рівня вирішують, як маніпулювати обладнанням для обробки нитки.