Что такое однопоточность в играх

объясните мне что такое однопоточных задачь, относится к процессору как это понимать

тем настолько хорошая что напишу через 5 лет когда автор возможно умер или вообще отрёкся задавать такие вопросы.

однопоточная задача (она же задача называется игрой, программой или подпрограммой внутри программы, например фильтр для работы с фото внутри графического редактора) это такая программа, которая может выполняться только на одном ядре процессора, а обо всех остальных будет незнать, так она написана, поэтому вашь крутой процессор превращается в x раз слабее для конкретно этой игры/программы где х рах это сколько в вашем процессоре ядер, на четырёхядерном в 4 раза т. е. Соответственно для этой программы например в диспетчере задачь чтобы понять что процессор загружен под сотку т. е. он работает в полную на двухйадерном процессоре будет 50% для такой программы это как 100% на неоднопоточной программе (т. е. программе или игре как готика, варкрафт 3 например, эти перечисленные они все однопоточные, что печально), и этот предел неодной программе по распаралеливанию задачьЪ не посилу, ибо они все мошейнические такие программы. Сама виндовс конечно загрузит такую однопоточную (читай одноядерную, т. е. программу игру могущую токо в одно ядро) на все ядра отнимая от каждого скажет по 25% на двухядерном получится = 50% (это на двухядерном, на трёхядерном 33%, на шести 16% или 17%, на четырёх 25%) от всего процессора что для конкретной задачи = как 100% загрузка процессора, но на деле более 50% взять не сможет. Если это онлайн игра ждите что если нехватка ресурсов пойдет процессора (50% мало) то тут же упадет fps и подскочет пинг на онлайн игре. На четырёх ядерном 100% делим кол-во ядер в процессоре например на 4 как в четырёхчдерном получится что одноядерная программа (однопоточная) сможет только 25% (а не 50% как на двухядерном) загрузить. Всё это даст fps, если например больше положеных 60 fps скажете много то в трудных местах этот запас опустится до 60 fps если игра многопоточная и больше дает чем 60fps (а 60 = плавно играется, кстате дляcs 1.6 исключение там 100 нужно для отсутствия тормозов, но на ней 100 легче набрать она старенькая совсем).

однопоточными являются игры старые + браузер (в нём flash игры и javascript, а вот flash или html5 видео нет оно многопоточное т. е. во все ядра) + какой-нить например проводник виндовс (мой компьютер, диск ц и лазание по папкам это та самая программа, она же меню пуск) она тоже однопоточная.

выход менять процессор умно с упором чтоб запас был для старых решений в виде старых программ в силе однопотока. Core 2 duo e6600 уже не хватает даже для cs 1.6 в некоторых картах и до 20 fps со 100 может падать и в готике 1,2 нехватает, раза в 3 сильнее бы на однопоток и хватит для всех однопоточных игр да программ. Конечно не значит что хватит для новых программ многопоточных. А этот процессор вообще 2008 года. Думаю и core 2 duo e8400 мало. На e6600 1080р в ютуб если оно в 60 fps тормоза, иногда и просто 1080 (30 fps) тормоза.

windows в любом случае на все ядра распределит такую программу по чуть чуть только безтолку, а игру никто переделывать не будет и мод и патч не спасут только исходники и громадный ремонд игры

сила процессора лучше смотреть в тестах чем знать скоко герц, один процессора за один герц сделает в 4 в 8 раз больше чем другой при одинаковых скажем 3 ггц соответственно у одного одна и та же игра чуть чуть его загрузит у другого очень много, поэтому сила процессора только в тестах слишком много паарметров все не реально учесть чтобы сказать кто мощнее.

разве что разгон пк может дать к однопотоку больше силу = больше fps

смотреть потоки у программы в process explorer

Источник

Сколько тебе нужно ядер для игр?

реклама

Про ядра.

Простым языком, количество ядер решает, как много задач процессор сможет обрабатывать одновременно. Когда-то все процессоры были одноядерными и не поддерживали многозадачность. Они умели только быстро переключаться между приоритетными задачами. С выходом процессоров Athlon и Pentium, на потребительский рынок поступили первые многоядерные «камни». Произошла так называемая «ядерная революция», их количество росло не по дням, а по часам. На текущий момент среди пользовательского сегмента есть 4, 8, 16 и даже 32-х ядерные модели. Серия AMD Ryzen на количестве ядер «собаку съела».

Совсем недавно, все компьютерные игры могли пользоваться только одним физическим ядром, установка двухъядерного процессора во многом ничего не давала. С течением времени, производители игр научились использовать большое количество ядер, что положительно сказалась на игровой производительности.

реклама

Из таблицы следует, что производительность многопоточного двухъядерного процессора практически сопоставима с полноценным четырехъядерным. Так процессор i3 седьмого поколения с 4-мя логическими потоками в играх оказался быстрее, чем i5 шестого поколения с полноценными 4-мя ядрами. Дальнейший же рост количества ядер и потоков не приносит каких-либо существенных результатов.

реклама

Про производительность.

Для того, чтобы проверить игровую производительность в различных вариациях ядер и потоков, возьмем десятиядерный двадцатипоточный Intel Core i9 7900X. Будем делать из него различные комбинации и смотреть на разницу игровой производительности. Также в тест будет добавлен AMD Ryzen 7 2700X на базовых частотах и с использованием всех ядер.

Тестовый стенд:

реклама

Эта игра видимо не знает, что такое потоки и ядра. Результат в пределах погрешности одинаков.

Здесь мы так же удостоверились, что 4 ядра вполне хватает для «раскрытия» видеокарты.

Так же как и Call of Duty, данный проект либо не умеет использовать больше чем 4 потока, либо настолько хорошо оптимизирован, что ему вполне хватает и двухъядерного процессора для максимальной производительности.

С 4-х поточными Pentium и i3 к этой игре лучше не подходить. Начиная с четырех ядер, роста производительности практически нет.

Про выбор.

Источник

На что влияет количество потоков процессора? Просто о сложном

Когда-то технология Hyper Threading от Intel стала настоящим прорывом, а ныне практически каждый современный процессор поддерживает распараллеливание Core-вычислений для обеспечения поточности. Аналогичным путём пошла и AMD. На что влияет количество потоков процессора?

Для начала дадим определение самому термину. Ядро – условное обозначение вычислительной ед-цы CPU, выполняющее последовательность команд. Строго одну и в заданной очерёдности.

Если ядер несколько, уже происходит переключение, обеспечивая равномерное распределение ресурсов. Понятно, что Double Core – лучше одного, а Quad – в 2 раза быстрее, чем двуядерный (при условии идентичной частоты и прочих характеристик).

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

Например, для антивирусного ПО, работающего в фоне. Если же предстоит сложный графический рендеринг, практичнее взять ЦП с максимальным числом физических ядер.

Источник

Сколько ядер и потоков процессора нужно для игр в 2020 году

Содержание

Содержание

Четырьмя ядрами процессора уже давно никого не удивить, в последние время количество ядер и потоков в предлагаемых для настольного ПК центральных процессорах растёт с каждым годом. Поколение консолей с x86 архитектурой и 8 ядрами на борту уже готово смениться на следующее. Сколько же ядер нужно для игр прямо сейчас и в ближайшем будущем?

Методика тестирования

В идеальных условиях необходимо взять многоядерный процессор и протестировать все варианты отключения ядер. При этом надо сохранить идентичность внутренних взаимодействий и размер кеша. С другой стороны, такое исследование несет меньше пользы в реальном применении — размер кеша является одним из инструментов в разделении линеек. Поэтому многоядерные решения имеют большой размер кеша, а самые младшие процессоры в несколько раз меньше заветных МБ в L3.

Выявлять зависимость игр от количества ядер и потоков центрального процессора будем на двенадцатиядерном Ryzen 9 3900X.

Для каждой конфигурации подберу оптимальную на мой взгляд комбинацию активных ядер и CCD-чиплетов. Напомню, что процессоры AMD на архитектуре Zen2 состоят из нескольких кристаллов: I/O-чиплет с контроллерами интерфейсов и CCD-чиплеты с ядрами. Каждый CCD-чиплет представляет собой блок из двух CCX, содержащих в максимальной конфигурации 4 ядра и 16 МБ кеша третьего уровня. В Ryzen 9 3900X каждый CCX модуль оснащен тремя ядрами и 16 МБ кеша L3. CCD-чиплет может работать либо с равным количеством активных ядер на каждом из его CCX, либо только с одним активным CCX — это накладывает ограничение на итоговые комбинации для тестирования.

В таблице выше указаны все возможные для Ryzen 9 3900X конфигурации ядер, жирным выделены компромиссно выбранные для тестирования варианты — с максимальным кешем для 8 и 12 ядер и одинаковым половинным для всех остальных вариантов от 2 до 6 ядер.

Вариант с 3 ядрами исключил по причине отсутствия таковых в продаже и слишком малого для игр количества ядер, 2 ядра без SMT (технология использования одного физического ядра для создания двух логических, аналогично Hyper Threading у Intel) не включены в тест из-за неактуальности таких процессоров в настоящее время.

В CPU-Z соревнующиеся варианты с включенным SMT выглядят так:

CCD-чиплеты в процессоре не одинаковы по частотному потенциалу: один является более удачным и используется для достижения максимальных частот буста, второй — с меньшими возможными частотами на тех же напряжениях. Для чистоты эксперимента все ядра зафиксируем на одинаковой частоте — 4350 МГц.

Остальной тестовый стенд выглядит так:

Настройки таймингов оперативной памяти выставлены в режим высокой производительности.

Для улучшения читаемости текста обозначу каждый вариант конфигурации процессора комбинацией двух чисел, например 4-8, где первая указывает на количество активных физических ядер, вторая — общее количество потоков.

Производительность в играх буду измерять в трех параметрах: AVG — среднее значение ФПС на тестируемом отрезке, 1 % — среднее значение 1 % меньших ФПС и 0,1 % — среднее значение 0,1 % меньших ФПС. Из этих трех показателей самым интересным, пожалуй, является 1 % — основываясь на этом значении, можно составить представление о плавности и комфортности геймплея.

Тесты

Настройки в играх буду подбирать для облегчения нагрузки на видеокарту, но сохраняя сложность построения сцены для процессора.

В качестве отправной точки для сравнения буду использовать вариант с 4 физическими ядрами без использования многопоточности SMT.

3D Mark Time Spy CPU Test

Первой дисциплиной будет синтетический CPU тест игровой производительности из пакета 3D Mark.

Как и полагается искусственно созданной нагрузке с оптимизациями под многопоток — результат растет почти линейно вместе с количеством ядер и потоков.

Из интересных результатов — преимущество 6 физических ядер над 4 с включенным SMT, и 6-12 конфигурации над 8-8. Для процессоров Intel результат был бы похожим, за исключением почти идентичных результатов 6-12 и 8-8, Hyper Threading в среднем менее эффективен, чем SMT у AMD. Примечательность сравнения этих комбинаций ядер-потоков в прямой конкуренции реальных процессоров в игровых сборках.

Assassin’s Creed Odyssey

Первый игровой проект и сразу один из самых процессорозависимых. Полностью избавиться от влияния видеокарты на результат не удалось, но и в таких условиях сравнение возможно.

Вопреки полученным выше результатам синтетического теста 3D Mark, восьмипоточный вариант 4-8 оказался производительнее 6-6, а 8-8 — быстрее 6-12. Реальное положение дел отличается от теоретических вычислительных возможностей.

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

Четыре ядра без SMT показывают достаточный для одиночной игры уровень ФПС, но сильно отстают от более оснащенных конфигураций. Вариант 2-4 подойдет только для совсем непритязательных игроков.

Far Cry 5

Far Cry не является игрой, сильно зависящей от количества потоков процессора, но протестировать такие проекты тоже необходимо.

Скриншоты с мониторингом параметров системы в вариантах 4-4 и 12-12 показывают отсутствие влияния видеокарты на результат теста, загрузка мощностей видеокарты не более 60 %.

Даже два ядра с включенным SMT показывают достойный уровень производительности во встроенном тесте, а 4-4 уже вплотную подбирается к максимально возможным для 3900Х на частоте 4,35 ГГц результатам. Классическая четырехпоточная игра.

Интересной особенностью Far Cry 5 является странная работа с процессорами без технологий логической многопоточности, причем это касается и процессоров AMD, и Intel. Статтеры в вариантах 6-6 и 8-8 роняют значение 0,1 % ФПС очень сильно и отражаются на комфорте игрового процесса для придирчивых игроков. При этом 4-4 и 12-12 конфигурации лишены таких проблем — для четырех ядер это верно и для процессоров Intel, 12 проверить не удалось.

Вот так огрехи оптимизации игры могут снизить итоговый ФПС при увеличении количества ядер и вычислительной мощности процессора.

PlayerUnknown’s Battlegrounds

PUBG уже не так популярен, как в былые времена, но все еще подходит под определение онлайн игры с большим количеством участников. В качестве тестового использовался отрезок повтора с двухминутным проездом на транспорте мимо активных боевых действий и красной зоны.

Скриншот мониторинга для варианта 4-4.

Конфигурации до 6-6 показывают приличный средний уровень ФПС, но мощности процессора явно не хватает — 1 % ниже 60 кадров в секунду уже нельзя назвать комфортным для сетевого шутера. 4-8 претендует на роль минимально приемлемого варианта.

World of Tanks enCore RT

WoT — яркий пример малопоточной онлайн игры, результаты в отдельном бенчмарке трудно считать реальным тестированием именно этого онлайн проекта, но вполне показательно в разрезе аналогичных игр, не требовательных к процессору.

Скриншот тестирования 8-16 варианта, количество кадров, подготавливаемых процессором, очень высоко: даже 720p не выручает — загрузка видеокарты более 80 %.

Любая из тестируемых конфигураций процессора показывает запредельный уровень ФПС. Начиная с 4-8, производительность достигает максимума и уже не меняется с ростом числа ядер и потоков.

Четырех ядер без SMT вполне достаточно для этой и подобных игр.

Red Dead Redemption 2

Вышедший на ПК эпичный вестерн доставляет больше проблем видеокарте, но и для процессора работа найдется, проект будет представлять портированные с приставок на настольный компьютер игры.

Скриншоты мониторинга вариантов 2-4 и 12-12, загрузка видеокарты велика для любого производительного варианта, но в этой игре это не мешает выявить разницу производительности процессоров.

Заметна оптимизация игры именно под 8 потоков: варианты 4-8 и 8-8 самые производительные. Примечательно, что даже 2-4 конфигурация позволит окунуться в атмосферу дикого запада с комфортом, если мощности видеокарты позволят.

Wolfenstein: Youngblood

Wolfenstein попал в сравнение как современная, хорошо оптимизированная игра.

Скриншот теста максимальной конфигурации 12-24 с мониторингом, избавиться от влияния видеокарты на результат не удалось, RTX 2080 Super оказалось недостаточно.

Все протестированные комбинации показывают отличные результаты, 4-4 не выглядит сильно отстающим.

Внимание привлекает отличная оптимизация игры под многопоточные процессоры — результаты в целом очень похожи на синтетический тест 3D Mark, 6-12 быстрее 8-8. С более мощной видеокартой рост производительности возможно сохранился бы и выше 8-16 варианта.

Итоги

Тенденция на увеличение ядер процессора в среднем ПК не обошла и игровую индустрию, многие проекты уже сейчас содержат оптимизации под многопоточные варианты. Переход приставок на x86 архитектуру, несомненно, тоже повлиял на этот процесс.

Можно с уверенностью сказать, что эра четырехядерных игровых процессоров подходит к концу, но прямо сейчас их производительности еще достаточно для относительно комфортного времяпрепровождения за любой игрой.

Естественно, главным ограничителем уровня кадров в секунду как и прежде является видеокарта, но, имея производительный шестиядерный процессор, уже можно рассчитывать на высокий ФПС в большинстве игр. А, начиная с 6-12 конфигураций, прирост кадров в секунду от увеличения потоков почти отсутствует.

Именно шесть ядер и двенадцать потоков скорее всего станут ориентиром для разработчиков игр в ближайшее время, но не стоит забывать о консолях с их восьмиядрной начинкой.

Источник

Реализация многопоточной архитектуры игрового движка

1. Введение

1.1. Обзор

Многопоточная архитектура игрового движка позволяет использовать возможности всех процессоров платформы по максимуму. Она предполагает параллельное выполнение различных функциональных блоков на всех доступных процессорах. Однако реализовать подобную схему, оказывается, не так просто. Отдельные элементы игрового движка часто взаимодействуют между собой, что может привести к появлению ошибок при одновременном их выполнении. Для обработки подобных сценариев в движке предусмотрены специальные механизмы синхронизации данных, исключающие возможные блокировки. В нем также реализованы методы одновременной синхронизации данных, за счет чего время выполнения удается свести к минимуму.

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

2. Состояние параллельного выполнения

Состояние параллельного выполнения — это ключевое понятие многопоточности. Только разделив игровой движок на отдельные системы, работающие каждая в своем режиме и практически не взаимодействующие с остальной частью движка, можно добиться наибольшей эффективности параллельных вычислений и сократить время, необходимое на синхронизацию. Полностью изолировать отдельные части движка, исключив все общие ресурсы, не представляется возможным. Однако для таких операций, как получение данных о положении или ориентации объектов, отдельные системы могут использовать локальные копии данных, а не общие ресурсы. Это позволяет свести к минимуму зависимость данных в различных частях движка. Уведомления об изменениях общих данных, выполненных отдельной системой, передаются менеджеру состояний, который помещает их в очередь. Это называется режимом обмена сообщениями. Данный режим предполагает, что, завершив выполнение задач, системы движка получают уведомления об изменениях и соответствующим образом обновляют свои внутренние данные. Такой механизм позволяет значительно сократить время синхронизации и зависимости систем друг от друга.

2.1 Состояния выполнения

Чтобы менеджер состояний выполнения работал эффективно, рекомендуется синхронизировать операции по определенному тактовому импульсу. Это позволяет всем системам работать одновременно. При этом частота тактов не обязательно должна соответствовать частоте передачи кадров. Да и длительность тактов может не зависеть от частоты. Ее можно выбрать таким образом, чтобы один такт соответствовал времени, необходимому на передачу одного кадра (вне зависимости от его размера). Иными словами, частоту или длительность тактов определяет конкретная реализация менеджера состояний. На рисунке 1 показан «свободный» пошаговый режим работы, в котором не требуется, чтобы все системы завершали выполнение операции за один и тот же такт. Режим, при котором все системы завершают выполнение операций за один такт, называется «жестким» пошаговым режимом. Он схематично изображен на рисунке 2.

Рисунок 1. Состояние выполнения в свободном пошаговом режиме

2.1.1. Свободный пошаговый режим

В свободном пошаговом режиме все системы работают непрерывно в течение заранее заданного промежутка времени, необходимого для завершения очередной порции вычислений. Однако название «свободный» не следует понимать буквально: системы синхронизируются не в произвольный момент времени, они лишь «свободны» в выборе числа тактов, необходимого на выполнение очередного этапа.
Как правило, в этом режиме недостаточно отправить менеджеру состояний простое уведомление об изменении состояния. Необходимо также передать обновленные данные. Это вызвано тем, что система, которая изменила общие данные, может находиться в состоянии выполнения, в то время как другая система, ожидающая эти данные, уже готова выполнить обновление. В этом случае требуется больше памяти, так как нужно создавать больше копий данных. Поэтому «свободный» режим нельзя считать универсальным решением на все случаи жизни.

2.1.2. Жесткий пошаговый режим

В этом режиме выполнение задач всех систем завершается за один такт. Такой механизм проще в реализации и не требует передачи обновленных данных вместе с уведомлением. Действительно, при необходимости одна система может просто запросить новые значения у другой системы (разумеется, в конце цикла выполнения).
В жестком режиме можно реализовать псевдосвободный пошаговый режим работы, распределяя вычисления между различными шагами. В частности, это может потребоваться для расчетов ИИ, где за первый такт вычисляется начальная «общая цель», которая постепенно уточняется на следующих этапах.

Рисунок 2. Состояние выполнения в жестком пошаговом режиме

2.2. Синхронизация данных

3. Движок

При разработке движка основное внимание уделяется гибкости, необходимой для дальнейшего расширения его функциональности. Это позволит оптимизировать его для использования в условиях определенных ограничений (например, по памяти).
Движок можно условно разделить на две части: фреймворк и менеджеры. Фреймворк (см. раздел 3.1) включает в себя части игры, которые тиражируются в процессе выполнения, то есть существуют в нескольких экземплярах. В него также входят элементы, участвующие в выполнении основного цикла игры. Менеджеры (см. раздел 3.2) представляют собой Singleton-объекты, отвечающие за выполнение логической составляющей игры.
Ниже представлена схема игрового движка.

Рисунок 3. Общая архитектура движка

Обратите внимание, что функциональные игровые модули, или системы, не являются частью движка. Движок лишь объединяет их между собой, выступая в роли связующего элемента. Подобная модульная организация дает возможность загружать и выгружать системы по мере необходимости.

Взаимодействие движка и систем осуществляется при помощи интерфейсов. Они реализованы таким образом, чтобы предоставить движку доступ к функциям систем, а системам — к менеджерам движка.
Подробная схема движка представлена в приложении A, «Схема движка».

3.1. Фреймворк

Фреймворк служит для объединения всех элементов движка. В нем происходит инициализация движка, за исключением менеджеров, экземпляры которых создаются глобально. В нем также хранится информация о сцене. Чтобы добиться большей гибкости, сцена реализуется в виде так называемой универсальной сцены, которая содержит универсальные объекты. Они представляют собой контейнеры, объединяющие различные функциональные части сцены. Подробная информация приведена в разделе 3.1.2.
Основной цикл игры также реализован во фреймворке. Схематично его можно представить следующим образом.

Рисунок 4. Основной цикл игры

Движок работает в оконной среде, поэтому на первом шаге цикла игры необходимо обработать все незавершенные сообщения окон ОС. Если этого не сделать, движок не будет реагировать на сообщения ОС. На втором шаге планировщик назначает задачи с помощью менеджера задач. Этот процесс подробно описан в разделе 3.1.1 ниже. После этого менеджер состояний (см. раздел 3.2.2) рассылает информацию о выполненных изменениях системам движка, на работу которых она может повлиять. На последнем шаге, в зависимости от статуса выполнения, фреймворк определяет, следует ли завершить или продолжить работу движка, например, для перехода к следующей сцене. Информация о состоянии движка хранится у менеджера среды. Подробнее см. в разделе 3.2.4.

3.1.1. Планировщик

Планировщик генерирует опорный тактовый сигнал выполнения с заданной частотой. Если в режиме эталонного тестирования требуется, чтобы следующая операция начиналась сразу после завершения предыдущей, не дожидаясь окончания такта, частота может быть неограниченной.
По тактовому сигналу планировщик с помощью менеджера задач переводит системы в режим выполнения. В свободном пошаговом режиме (раздел 2.1.1) планировщик опрашивает системы, чтобы определить, сколько тактов им понадобится на завершение задачи. По результатам опроса планировщик определяет, какие системы готовы к выполнению, а какие завершат работу в конкретный такт. Планировщик может изменить количество тактов, если какой-либо системе требуется больше времени на выполнение. В жестком пошаговом режиме (раздел 2.1.2) все системы начинают и заканчивают выполнение в один и тот же такт, поэтому планировщик ждет, когда завершится выполнение всех систем.

3.1.2. Универсальная сцена и объекты

Универсальная сцена и объекты являются контейнерами для функциональности, реализованной в других системах. Они предназначены исключительно для взаимодействия с движком и не выполняют никаких других функций. Однако их можно расширить, чтобы использовать функции, доступные другим системам. Это позволяет добиться слабой связанности. Действительно, универсальная сцена и объекты могут использовать свойства других систем, не будучи привязанными к ним. Именно это свойство исключает зависимость систем друг от друга и дает им возможность работать одновременно.
На схеме ниже изображено расширение универсальной сцены и объекта.

Рисунок 5. Расширение универсальной сцены и объекта

Рассмотрим принцип работы расширений на следующем примере. Допустим, выполнено расширение универсальной универсальная сцены сцена расширена на для использование использования графических, физических и других свойств. В этом случае за инициализацию дисплея будет отвечать «графическая» часть расширения, а за реализацию физических законов для твердых тел, например силы тяжести, — его «физическая» часть. Сцены содержат объекты, поэтому универсальная сцена тоже будет включать в себя несколько универсальных объектов. Универсальные объекты также можно расширить намогут быть расширены для использование использования графических, физических и других свойств. Например, прорисовка объекта на экране будет реализована графическими функциями расширения, а расчет взаимодействия твердых тел — физическими.

Подробная схема взаимодействия движка и систем приведена в приложении B, «Схема взаимодействия движка и систем».
Следует заметить, что универсальная сцена и универсальный объект отвечают за регистрацию всех своих «расширений» в менеджере состояний, для того, чтобы все расширения могли получать уведомления об изменениях, внесенных другими расширениями (то есть другими системами). В качестве примера можно привести графическое расширение, зарегистрированное для получения уведомлений об изменениях положения и ориентации, выполненных физическим расширением.
Подробную информацию о компонентах системы см. в разделе 5.2, «Компоненты системы».

3.2. Менеджеры

Менеджеры управляют работой движка. Они являются Singleton-объектами, то есть менеджер каждого типа доступен только в одном экземпляре. Это необходимо, поскольку дублирование ресурсов менеджеров неизбежно приведет к избыточности и отрицательно скажется на производительности. Кроме того, менеджеры отвечают за реализацию общих функций для всех систем.

3.2.1. Менеджер задач

Менеджер задач отвечает за управление системными задачами в пуле потоков. Чтобы обеспечить оптимальное n-кратное масштабирование и предотвратить назначение лишних потоков, исключая неоправданные издержки на переключение задач в операционной системе, пул потоков создает по одному потоку на каждый процессор.

Планировщик передает менеджеру задач список задач для выполнения, а также информацию о том, завершения каких задач необходимо дождаться. Он получает эти данные от различных систем. Каждая система получает только одну задачу для выполнения. Такой метод называют функциональной декомпозицией. Однако для обработки данных каждую такую задачу можно разделить на произвольное количество подзадач (декомпозиция данных).
Ниже приведен пример распределения задач между потоками для четырехъядерной системы.

Рисунок 6. Пример пула потоков, используемого менеджером задач

Помимо обработки запросов планировщика по доступу к основным задачам менеджер задач может работать в режиме инициализации. Он последовательно опрашивает системы от каждого потока, чтобы они могли инициализировать локальные хранилища данных, необходимые для работы.
Советы по реализации менеджера задач даны в приложении D, «Советы по реализации задач».

3.2.2. Менеджер состояний

Менеджер состояний является частью механизма обмена сообщениями. Он отслеживает изменения и рассылает уведомления о них всем системам, которых эти изменения могут затронуть. Чтобы не рассылать ненужных уведомлений, менеджер состояний хранит информацию о том, какие системы оповещать в том или ином случае. Этот механизм реализован на основе шаблона «Наблюдатель» (см. приложение C, «Наблюдатель (шаблон проектирования)»). Если говорить вкратце, данный шаблон предполагает использование «наблюдателя», который следит за любыми изменениями субъекта, при этом роль посредника между ними выполняет контроллер изменений.

Механизм работает следующим образом. 1. Наблюдатель сообщает контроллеру изменений (или менеджеру состояний), изменения каких субъектов он хочет отслеживать. 2. Субъект уведомляет контроллер обо всех своих изменениях. 3. По сигналу фреймворка контроллер оповещает наблюдателя об изменениях субъекта. 4. Наблюдатель отправляет субъекту запрос на получение обновленных данных.

В режиме свободного пошагового выполнения (см. раздел 2.1.1) реализация этого механизма несколько усложняется. Во-первых, обновленные данные придется отправлять вместе с уведомлением об изменении. В этом режиме отправка по запросу неприменима. Действительно, если на момент получения запроса система, ответственная за изменения, еще не закончит выполнение, она не сможет предоставить обновленные данные. Во-вторых, если какая-то система еще не готова получить изменения в конце такта, менеджер состояний должен будет удерживать измененные данные до тех пор, пока все зарегистрированные для их получения системы не придут в состояние готовности.

Во фреймворке для этого предусмотрено два менеджера состояний: для обработки изменений на уровне сцены и на уровне объекта. Обычно сообщения, касающиеся сцен и объектов, независимы друг от друга, поэтому использование двух отдельных менеджеров исключает необходимость обработки ненужных данных. Но если в сцене необходимо учитывать состояние какого-либо объекта, ее можно зарегистрировать на для получение получения уведомлений о его изменениях.

Чтобы не выполнять лишней синхронизации, менеджер состояний формирует очередь уведомлений об изменениях отдельно для каждого потока, создаваемого менеджером задач. Поэтому при доступе к очереди никакой синхронизации не требуется. В разделе 2.2 описан метод, который можно использовать для объединения очередей после выполнения.

Рисунок 7. Уведомление о внутренних изменениях универсального объекта

Уведомления об изменениях не обязательно рассылать последовательно. Существует способ их параллельной рассылки. Выполняя задачу, система работает со всеми своими объектами. Например, по мере того как физические объекты взаимодействуют друг с другом, физическая система управляет их перемещением, расчетом столкновений, новых действующих сил и т. п. При получении уведомлений объект системы не взаимодействует с другими объектами своей системы. Он взаимодействует со связанными с ним расширениями универсального объекта. Это означает, что универсальные объекты теперь независимы друг от друга и их можно обновить одновременно. Такой подход не исключает крайних случаев, которые следует учитывать в процессе синхронизации. Однако он позволяет использовать режим параллельного выполнения, когда казалось, что действовать можно только последовательно.

3.2.3. Менеджер служб

Менеджер служб предоставляет системам доступ к функциям других систем, которые иначе были бы им недоступны. Важно понимать, что доступ к функциям осуществляется с помощью интерфейсов, а не напрямую. Информация об интерфейсах систем также хранится в менеджере служб.
Чтобы исключить зависимости систем друг от друга, каждая из них обладает лишь небольшим набором служб. Кроме того, возможность использования той или иной службы определяется не самой системой, а менеджером служб.

Рисунок 8. Пример менеджера служб

У менеджера служб есть и другая функция. Он предоставляет системам доступ к свойствам других систем. Свойствами называются специфичные значения конкретных систем, которые не передаются в системе обмена сообщениями. Это может быть расширение разрешение экрана в графической системе или величина силы тяжести в физической. Менеджер служб открывает системам доступ к таким данным, но не позволяет напрямую их контролировать. Он помещает изменения свойств в специальную очередь и публикует их только после последовательного выполнения. Обратите внимание, что доступ к свойствам другой системы требуется достаточно редко и не стоит им злоупотреблять. Например, он может понадобиться для включения и отключения режима каркасной сетки в графической системе из окна консоли или для изменения разрешения экрана по запросу игрока из интерфейса пользователя. Данную возможность преимущественно используют для установки параметров, которые не изменяются от кадра к кадру.

3.2.4. Менеджер среды

3.2.5. Менеджер платформы

Менеджер платформы реализует абстракцию для вызовов операционной системы, а также обеспечивает дополнительную функциональность помимо простой абстракции. Преимуществом такого подхода является инкапсуляция нескольких типичных функций в рамках одного вызова. То есть их не придется реализовывать отдельно для каждого вызывающего элемента, перегружая его подробностями о вызовах ОС.
Рассмотрим в качестве примера вызов менеджера платформы для загрузки динамической библиотеки системы. Он не только загружает систему, но также получает точки входа функции и вызывает функцию инициализации библиотеки. Менеджер также хранит дескриптор библиотеки и выгружает его после завершения работы движка.

Менеджер платформы также отвечает за предоставление информации о процессоре, например о поддерживаемых SIMD-инструкциях, и за инициализацию определенного режима работы процессов. Других функций формирования запросов системы использовать не могут.

4. Интерфейсы

Интерфейсы являются средствами взаимодействия между фреймворком, менеджерами и системами. Фреймворк и менеджеры являются частью движка, поэтому они могут взаимодействовать друг с другом напрямую. Системы к движку не относятся. Более того, все они выполняют разные функции, что приводит к необходимости создания единого метода взаимодействия с ними. Поскольку системы не могут взаимодействовать с менеджерами напрямую, для них необходимо предусмотреть другой способ доступа. При этом не все функции менеджеров должны быть открыты для систем. Некоторые из них доступны только фреймворку.

Интерфейсы определяют набор функций, необходимых для использования стандартного метода доступа. Это избавляет фреймворк от необходимости знать детали реализации конкретных систем, поскольку он может взаимодействовать с ними только посредством определенного набора вызовов.

4.1. Интерфейсы субъекта и наблюдателя

Основное назначение интерфейсов субъекта и наблюдателя — регистрация того, каким наблюдателям оправлять уведомления о каких субъектах, а также отправка таких уведомлений. Регистрация и разрыв связи с наблюдателем являются стандартными функциями для всех субъектов, включенными в реализацию их интерфейса.

4.2. Интерфейсы менеджеров

Менеджеры, несмотря на то что они являются Singleton-объектами, напрямую доступны только для фреймворка. Другие системы могут получить доступ к менеджерам только через интерфейсы, которые представляют лишь часть их общей функциональности. После инициализации интерфейс передается системе, которая использует его для работы с определенными функциями менеджера.
Не существует единого интерфейса для всех менеджеров. Каждый из них имеет свой отдельный интерфейс.

4.3. Интерфейсы системы

Чтобы фреймворк мог получить доступ к компонентам системы, ей необходимы интерфейсы. Без них поддержку каждой новой системы движка пришлось бы реализовывать отдельно.
Каждая система включает в себя четыре компонента, поэтому и интерфейсов должно быть четыре. А именно: система, сцена, объект и задача. Подробное описание см. в разделе 5, «Системы». Интерфейсы — это средства получения доступа к компонентам. Интерфейсы системы позволяют создавать и удалять сцены. Интерфейсы сцены, в свою очередь, позволяют создавать и уничтожать объекты, а также запрашивать информацию об основной задаче системы. Интерфейс задач в основном используется менеджером задач при постановке задач в пул потоков.
Поскольку сцена и объект, как части системы, должны взаимодействовать друг с другом и с универсальной сценой и объектом, к которым они привязаны, их интерфейсы также создают на основе интерфейсов субъекта и наблюдателя.

4.4. Интерфейсы изменений

Эти интерфейсы служат для передачи данных между системами. Все системы, выполняющие изменения определенного типа, должны реализовать такой интерфейс. В качестве примера можно привести геометрию. Интерфейс геометрии включает в себя методы определения положения, ориентации и масштаба элемента. Любая система, вносящая изменения в геометрию, должна реализовать такой интерфейс, чтобы для доступа к измененным данным не требовалась информация о других системах.

5. Системы

Системы являются частью движка, которая отвечает за реализацию игровой функциональности. Они выполняют все основные задачи, без которых движок не имел бы смысла. Взаимодействие между движком и системами осуществляется при помощи интерфейсов (см. раздел 4.3, «Интерфейсы системы»). Это необходимо, чтобы не перегружать движок информацией о различных типах систем. Благодаря интерфейсам процесс добавления новой системы становится гораздо проще, поскольку в движке не требуется учитывать все детали реализации.

5.1. Типы

Системы движка можно условно разделить на несколько заранее определенных категорий, соответствующих стандартным компонентам игры. Например: геометрия, графика, физика (столкновение твердых тел), звук, обработка входных данных, ИИ и анимация.
Системы с нестандартными функциями относятся к отдельной категории. Важно понимать, что любая система, которая изменяет данные конкретной категории, должна знать об интерфейсе этой категории, поскольку движок не предоставляет такую информацию.

5.2. Компоненты системы

Для каждой системы необходимо реализовать несколько компонентов. Вот некоторые из них: система, сцена, объект и задача. Все эти компоненты служат для взаимодействия с различными частями движка.
На схеме ниже изображены взаимодействия между различными компонентами.

Рисунок 9. Компоненты системы

Подробная схема связей между системами движка приведена в приложении B, «Схема взаимодействия движка и систем».

5.2.1. Система

Компонент «система», или просто система, отвечает за инициализацию системных ресурсов, которые практически не будут меняться в процессе работы движка. Например, графическая система анализирует адреса ресурсов для определения места их нахождения и ускорения загрузки при использовании ресурса. Она также задает разрешение экрана.
Система является основной входной точкой для фреймворка. Она предоставляет информацию о себе (например, тип системы), а также методы создания и удаления сцен.

5.2.2. Сцена

Компонент «сцена», или системная сцена, отвечает за управление ресурсами, которые относятся к текущей сцене. Универсальная сцена использует системные сцены для расширения функциональности за счет использования их функций. В качестве примера можно привести физическую сцену, которая используется при создании нового игрового мира и при инициализации сцены определяет в нем силы гравитации.
В сценах предусмотрены методы создания и уничтожения объектов, а также компонент «задача» для обработки сцены и метод доступа к нему.

5.2.3. Объект

Компонент «объект», или системный объект, принадлежит сцене и обычно связан с тем, что пользователь видит на экране. Универсальный объект использует системный объект для расширения функциональности, предоставляя его свойства как свои собственные.
Примером может послужить геометрическое, графическое и физическое расширение универсального объекта для отображения деревянной балки на экране. Геометрические свойства будут включать в себя положение, ориентацию и масштаб объекта. Для его отображения графическая система будет использовать специальную сетку. А физическая система наделит его свойствами твердого тела для расчета взаимодействий с другими телами и действующих сил гравитации.

В определенных случаях в системном объекте необходимо учитывать изменения универсального объекта или одного из его расширений. Для этой цели можно создать специальную связь, которая позволит отслеживать выполненные изменения.

5.2.4. Задача

Компонент «задача», или системная задача, используется для обработки сцены. Задача получает команду на обновление сцены от менеджера задач. Это сигнал для запуска системных функций на объектах сцены.
Выполнение задачи можно разбить на подзадачи, распределяя их также с помощью менеджера задач на еще большее число потоков. Это удобный способ масштабирования движка на несколько процессоров. Такой метод называют декомпозицией данных.
Информация об изменении объектов в процессе обновления задач сцены передается менеджеру состояний. Подробную информацию о менеджере состояний см. в разделе 3.2.2.

6. Объединяя все компоненты

Все описанные выше элементы связаны между собой и являются частью одного целого. Работу движка можно условно разделить на несколько этапов, описанных в следующих разделах.

6.1. Этап инициализации

Рисунок 10. Инициализация менеджеров и систем движка

6.2. Этап загрузки сцены

Рисунок 11. Инициализация универсальной сцены и объекта

6.3. Этап цикла игры

6.3.1. Выполнение задачи

Рисунок 12. Менеджер задач и задачи

6.3.2. Обновление данных

6.3.3. Проверка выполнения и выход

Итоговый этап цикла игры представляет собой проверку состояния среды выполнения. Существует несколько таких состояний: работа, пауза, следующая сцена и т. п. Если выбрано состояние «работа», будет запущена следующая итерация цикла. Состояние «выход» означает завершение работы цикла, освобождение ресурсов и выход из приложения. Можно реализовать и другие состояния, например «пауза», «следующая сцена» и др.

7. Заключение

Основная идея данной статьи изложена в разделе 2, «Состояние параллельного выполнения». Благодаря функциональной декомпозиции и декомпозиции данных можно реализовать не только многопоточность движка, но и его масштабируемость на еще большее количество ядер в будущем. Чтобы исключить издержки на синхронизацию, продолжая поддерживать данные в актуальном состоянии, используйте менеджеры состояния в дополнение к механизму обмена сообщениями.

Шаблон «Наблюдатель» — это функция механизма обмена сообщениями. Важно хорошо понимать принцип ее работы, чтобы выбрать оптимальный способ ее реализации для движка. Фактически это механизм взаимодействия между различными системами, который обеспечивает синхронизацию общих данных.

Важную роль в распределении нагрузок играет управление задачами. В приложении D приведены советы по созданию эффективного менеджера задач для игрового движка.

Как видите, многопоточность игрового движка удается реализовать благодаря четко определенной структуре и механизму обмена сообщениями. С ее помощью можно значительно повысить производительность современных и будущих процессоров.

Приложение A. Схема движка

Запуск обработки выполняется из основного цикла игры (см. рис. 4, «Основной цикл игры»).

Приложение B. Схема взаимодействия движка и систем

Приложение C. Наблюдатель (шаблон проектирования)

Шаблон «Наблюдатель» подробно описан в книге «Приемы объектно-ориентированного проектирования. Паттерны проектирования», Э. Гамма, Р. Хельм, Р. Джонсон, Дж. Влиссидес («Design Patterns: Elements of Reusable Object-Oriented Software», Gamma E., Helm R., Johnson R., Vlissides J.). На английском языке она впервые была издана в 1995 году издательством Addison-Wesley.

Основная идея данной модели заключается в следующем: если каким-то элементам необходимо получать уведомления об изменениях других элементов, они не обязаны просматривать список всех возможных изменений, пытаясь найти в нем нужные данные. Модель подразумевает наличие субъекта и наблюдателя, которые используются для отправки уведомлений об изменениях. Наблюдатель отслеживает любые изменения субъекта. Контроллер изменений выступает в роли посредника между этими двумя данными компонентами. Следующая схема иллюстрирует данную связь.

Рисунок 13. Шаблон «Наблюдатель»

Приложение D. Советы по реализации задач

Существует множество разных способов реализовать распределение задач. Однако лучше всего поддерживать количество рабочих потоков равным количеству доступных логических процессоров платформы. Старайтесь не привязывать задачи к определенному потоку. Время выполнения задач различных систем не всегда совпадает. Это может привести к неравномерному распределению нагрузки между рабочими потоками и сказаться на эффективности. Чтобы упростить этот процесс, используйте библиотеки управления задачами, например Threading Building Blocks от Intel.

Источник