Download to read offline
Uploaded bycorehard_by
Многопоточность в играх. Игорь Лобанчиков. CoreHard Spring 2019
Документ обсуждает многопоточность в разработке игр, включая её историю, модели и методы реализации. Основное внимание уделяется структуре application loop и подходам к многопоточному рендерингу, а также вызовам, связанным с синхронизацией и производительностью. В конце представлены современные графические API и идеи для оптимизации многопоточности.
More Related Content
Similar to Многопоточность в играх. Игорь Лобанчиков. CoreHard Spring 2019
Многопоточность в играх. Игорь Лобанчиков. CoreHard Spring 2019
- 1. Многопоточность и игры IgorLobanchikov, 2019
- 2. Игорь Лобанчиков • Разрабатываюигры с 2003 года • S.T.A.L.K.E.R.: Clear Sky • Работал с Intel, AMD, Qualcomm, Amazon, Confetti и другие • Эксперт по компьютерной графике • Помогаю улучшать и оптимизировать чужие проекты • Портирую игры на новые платформы • imixerpro(at)gmail(dot)com 2
- 3. О чем будемговорить • Структура application loop • История многопоточности в играх • Как зарождалась • Как развивалась • Почему именно так, а не иначе • Многопоточность сегодня • Task-based • Hybrid (Task-based + thread-based) • Многопоточный рендеринг • DX12 + Vulkan + Metal 3
- 4. Core 0 Структура applicationloop Input Update Output 4
- 5. • 60 кадровв секунду (16.6 мс на кадр) • 16.6мс vs 17.6мс = 60 FPS vs 57 FPS • 33.3мс vs 34.4мс = 30 FPS vs 29 FPS Core 0 Структура application loop Input Update Render 5
- 6. 1 % 49.5% 49.5% Core 0 Структураapplication loop I n p u t Update Render 6
- 7. Core 0 Структура applicationloop I n p u t Update Render Update Game Logic Collision / Simulation Audio rendering Path finding Transform Animation blending Visibility culling Batching Submission to GPU 7
- 8. • February 25,2002, Xeon (2xSMT) • Early 2003 MS announced XBox Next (3 cores w/2xSMT), launched November 22, 2005 • May 25, 2005, Pentium D (2 cores) • May 2005, Athlon 64 X2 (2 cores) • November 11, 2006 Sony launched PS3 (1 PowerPC 2xSMT core, 6 SPEs) Core 0 Предпосылки возникновения многопоточностиI n p u t Update Render Update Game Logic Collision / Simulation Audio rendering Path finding Animation blending Visibility culling Batching Submission to GPU ???Core 1 Transform 8
- 9. • Основной паркигровых компьютеров - одноядерный • Двух-ядерные CPU дороги • Логические взаимосвязи между различными модулями сильны ради увеличения производительности • Консольное железо уникально и требует специального подхода Core 0 Предпосылки возникновения многопоточностиI n p u t Update Render Update Game Logic Collision / Simulation Audio rendering Path finding Animation blending Visibility culling Batching Submission to GPU ???Core 1 Transform 9
- 10. • специальный отдельныйпоток с фиксированным порядком выполнения задач, определенных на этапе компиляции • минимально необходимые изменения в структурах данных • максимально сохраняется порядок выполнения • синхронизация с помощью conditional или их аналогов • возможно, у каждой задачи свой поток, поскольку задач мало Core 0 Threaded model: naive approach I n p u t Update Render Update Game Logic Path finding Animation blending Visibility culling Batching Submission to GPU Core 1 Transform Audio rendering Collision / Simulation Visibility culling Resource streaming GPU driver thread 10
- 11. • Незначительный приростпроизводительности • Плохо масштабируется при увеличении количества ядер • плохо подходит для XBox360/PS3 Core 0 Threaded model: naive approach НедостаткиI n p u t Update Render Update Game Logic Path finding Animation blending Visibility culling Batching Submission to GPU Core 1 Transform Audio rendering Collision / Simulation Visibility culling Resource streaming GPU driver thread 11
- 12. • Независимые пространстваобъектов для Update и Render все еще позволяют использовать старый однопоточный код • Обновление состояния render через single writer single reader lock free кольцевой буфер • Можно сбалансировать нагрузку для любого, заранее заданного, количества ядер - хорошо сработало для Xbox 360 Core 0 Threaded model: независимые системы I n p u t Update Update Game Logic Collision / Simulation Audio rendering Path finding ???Core 1 Render Animation blending Visibility culling Batching Submission to GPU Transform I n p u t 12
- 13. • Существенные затратына создание независимых структур данных • Все несколько сложнее, чем выглядит, поскольку результаты работы систем могут быть нужны в обоих потоках (например, скиннинг) • Не масштабируется для произвольного количества ядер • PS3 в силу наличия только одного полноценного 2xSMT ядра требовала еще более глубокой адаптации Threaded model: независимые системы Недостатки ???Core 1 Render Animation blending Visibility culling Batching Submission to GPU Transform Core 0 I n p u t Update Update Game Logic Collision / Simulation Audio rendering Path finding I n p u t 13
- 14. Threaded model: ??? ???Core1 Render Animation blending Visibility culling Batching Submission to GPU Transform Core 0 I n p u t Update Update Game Logic Collision / Simulation Audio rendering Path finding Queue 1 Queue 2 Queue N Key Ref Key Ref Key Ref Render Object Path finding I n p u t 14
- 15. Threaded model: ??? ???Core1 Render Animation blending Visibility culling Batching Submission to GPU Transform Core 0 I n p u t Update Update Game Logic Collision / Simulation Audio rendering Sorted render list Key Ref Key Ref Key Ref Mesh Object list Shaders Textures Instance data Path finding I n p u t 15
- 16. • очереди наотрисовку формируются из объектов (или мешей) и их состояний: положения в пространстве, анимации и т.п. • Можно пользоваться старыми однопоточными структурами данных • Самая дорогая и неделимая часть выполняется параллельно основному потоку • Можно сбалансировать нагрузку для любого, заранее заданного, количества ядер - хорошо сработало для Xbox 360 Core 0 Threaded model: draw list generation I n p u t Update Update Game Logic Collision / Simulation Audio rendering Path finding ???Core 1 Ani mat ion ble ndi ng Visibility culling Batching Submission to GPU Tr a ns fo r m I n p u t 16
- 17. • Все ещенеобходимо гарантировать время жизни моделей, мешей, текстур (без boost::shared_ptr) • Выше асимметрия нагрузки потока, чем для независимых систем • Не масштабируется для произвольного количества ядер • те же проблемы с PS3, что и для независимых систем Core 0 Threaded model: draw list generation НедостаткиI n p u t Update Update Game Logic Collision / Simulation Audio rendering Path finding ???Core 1 Ani mat ion ble ndi ng Batching Submission to GPU Tr a ns fo r m Visibility culling I n p u t 17
- 18. Куда дальше? • Всепереписать и сделать правильно • Data-driven approach • Task-based approach • C++ 17 • AGILE • GIT • Data science • Block chain 18
- 19. Реальный мир • Количествопроизводственных ресурсов ограничено: люди, деньги не бесконечны • Необходимо продолжить выпускать игры • Количество ядер у пользователя 1-2-4 с топовыми конфигурациями 8-16 • На горизонте новые консоли (первые дев киты попали к разработчикам в 2011 году) • Много специализированного PS3 кода для использования 6 ядер SPU 19
- 20. Чего мы хотимот многопоточности • минимизация накладных расходов • минимум синхронизаций между потоками • максимизация загрузки всего CPU • минимизация конфликтов между кешами разных ядер (т.е. не пишем туда, откуда читает другой поток, и, тем более, не пишем в одно и то же место из разных потоков) 20
- 21. Что уже реализовано •у нас уже есть определенные гарантии на неизменность некоторых состояний объектов и на время их жизни ??? Objects can be read from other threads Update objects Flush lazy computations Delete pending objects 21
- 22. Что уже реализовано •у нас уже есть определенные гарантии на неизменность некоторых состояний объектов и на время их жизни • мы уже умеем работать с быстрыми очередями (1R/1W) Calculate data Send data update ??? Apply data update Process old data Process new data 22
- 23. Что уже реализовано •у нас уже есть определенные гарантии на неизменность некоторых состояний объектов и на время их жизни • мы уже умеем работать с быстрыми очередями (1R/1W) • Мы уже научились не выделять память как попало (до появления многопоточности тоже умели) 23
- 24. Task-based parallelism • taskmanager • выносим код из потоков в таски • таски не модифицируют глобальные данные, но формируют новые • а некоторые и на вход получают буфер с данными • используем где возможно data parallel таски (если порядок обработки не важен) • каждый поток таска при этом генерирует свой собственный выходной буфер (нет проблем с синхронизацией, нет проблем с кешом) • при необходимости по завершению работы буфера будут объединены 24
- 25. ??? ??? ??? ??? Core 0 Task-based parallelism:submission to GPU занимает много времениI n p u t Update Update Game Logic Collision / Simulation Audio rendering Path finding Core 1 Anim ation blen ding Batching Submission to GPU for previous frame Transfo rm Core 2 Core N Ani mat ion ble ndi ng Visibility culling Visibility culling GPU driver thread Submission to GPU I n p u t Update Game Logic 25
- 26. ??? ??? ??? ??? Core 0 Task-based parallelism:submission to GPU требует неизменности данныхI n p u t Update Update Game Logic Collision / Simulation Audio rendering Path finding Core 1 Anim ation blen ding Batching Transfo rm Core 2 Core N Ani mat ion ble ndi ng Visibility culling Visibility culling GPU driver thread Submission to GPU I n p u t Update Game Logic 26
- 27.
- 28. “Старые” графические API •(Direct3D 11-, OpenGL / OpenGL ES) • много проверок и дополнительной работы на лету, достаточно дорогие вызовы API • захват времени жизни объектов • некоторые объекты API далеки от реальных объектов GPU 28
- 29. ??? “Старые” графические API управлениерезидентностью ресурсов ??? ??? Set texture DrawClient GPU command buffer Driver Texture residence manager Draw Set resources Flush unused textures Restore used textures Process CB Set texture Draw Draw Set resources Draw Draw State cache State cache 29
- 30. “Старые” графические API управлениесостоянием GPU ??? ??? Set Pixel Shader DrawClient GPU Driver State cache Draw Set state object Process CB Set Pixel Shader Draw Draw Set state object Draw Draw Set Vertex Shader State cache Set Vertex Shader command buffer 30
- 31. DirectX 12 /Vulkan / Metal • DirectX 12 - июль 2015, Vulkan - февраль 2016, Metal - сентябрь 2014 • Большую часть работы переложили на клиентский код 31
- 32. ??? “Новые” графические API управлениерезидентностью ресурсов Set resources DrawClient GPU command buffer Driver Set resources Process CB Set resources Draw Set resources Draw Draw Flush unused textures Restore used textures Manage textures residency 32
- 33. ??? “Новые” графические API управлениесостоянием GPU Set state object DrawClient GPU Driver Set state object Process CB Set state object Draw Set state object Draw Draw command buffer 33
- 34. ??? ??? ??? ??? Core 0 Task-based parallelism+ современные графические APII n p u t Update Update Game Logic Collision / Simulation Audio rendering Path finding Core 1 Anim ation blen ding Batching Transfo rm Core 2 Core N Ani mat ion ble ndi ng Visibility culling Visibility culling I n p u t Update Game Logic Submission to GPU Submission to GPU Submission to GPU Submission to GPU 34
- 35.
- 36. Links • https://github.com/dougbinks/enkiTS • https://www.enkisoftware.com/devlogpost-20150822-1- Implementing_a_lightweight_task_scheduler •https://www.enkisoftware.com/devlogpost-20150905-1- Internals_of_a_lightweight_task_scheduler • https://www.slideshare.net/jrouwe/killzone-shadow-fall-threading-the- entity-update-on-ps4 • https://www.gdcvault.com/play/1022164/Multithreading-the-Entire- Destiny • http://s09.idav.ucdavis.edu/talks/05-JP_id_Tech_5_Challenges.pdf 36
Editor's Notes
- #10 До настоящего времени консоли так же были одноядерными. PS2 - неоднородная система с уникальными вычислительными блоками. Код для нее можно было бы считать многопоточным. GPU, фактически, так же отдельный поток. Но, в норме, данные туда передаются и оттуда не забираются
- #14 В результате PS3 версия движка обложена огромным количеством операций условной компиляции даже в общем и условно “платформо-независимом” коде
- #15 В результате PS3 версия движка обложена огромным количеством операций условной компиляции даже в общем и условно “платформо-независимом” коде
- #17 Двойная буферизация в действии.
- #19 Я ничего модного не упустил?
- #22 на консолях больше контроля - больше гарантий. бэкпортится на PC
- #23 на консолях больше контроля - больше гарантий. бэкпортится на PC
- #24 на консолях больше контроля - больше гарантий. бэкпортится на PC
- #25 количество тасков - минимально. Так проще контролировать. все это требует дополнительной памяти, которая у нас уже есть: и на консолях (там пока еще тесновато), и уж точно на PC. Несколько дополнительных мегабайт под рабочие буфера занимают много меньше места, чем графические ресурсы
- #26 Здесь нет particle simulation - все стараются делать на GPU В итоге на достаточно быстром и многоядерном CPU мы упираемся вsubmission to gpu. На консолях таких проблем нет (почти)
- #27 если разработчик изначально начал с тасков минуя предыдущие модели и не имеет независимых систем и/или draw list generation подхода в таких случаях update logic так же стараются бить на таски: перекрытие с рендерингом у игровой логики отсутствует, значит, пока игровая логика обновляется, есть много свободных ядер
- #28 CPU и GPU - асинхронные системы. Поэтому команды между ними передаются с помощью очереди команд, которая, в свою очередь, состоит из command buffer. Драйвер буфер заполняет и отдает на GPU. В свою очередь, секвенсор GPU забирает буфера команд из очереди и последовательно их обрабатывает. В идеальном мире драйвер бы только и делал, что преобразовывал команды.
- #29 Не имело смысла писать многопоточный код драйвер управлял временем жизни ресурсов некоторые скрытые ресурсы генерировались на лету
- #35 Счастливое ближайшее будущее (для многих уже настоящее) На консолях всегда так было
- #39 Вообще, это не совсем правда и первое приближение, поскольку разные API все же могут иметь отличные подходы управления ресурсами, DX12 предлагает даже 2 подхода.
- #47 Во избежание аллокаций памяти - а это те же синхронизации внутри хипа, используем кольцевые буфера или двойную буферизацию Т.е. мы всеми способами стараемся избегать лишних блокировок. Если данные необходимо обновить в другой системе, мы передаем в нее буфер команд (возможно, неявно). Внутри системы секвенсор разберется, что с командами делать. Если данные данной системы нужны снаружи, мы так же стараемся обновлять их только в те промежутки времени, когда они никем не используются. В результате, вместо множественных синхронизаций между потоками мы синхронизируем их исключительно в ключевых точках.
- #48 каждую изолированную систему можно разбивать на параллельные задания независимо от других