Комментарии 6
С переходом на вулкан/дх12 использовать один поток нельзя. Раньше графика работала в отдельном потоке, а теперь нет и даже memcpy в GPU-память занимает кучу времени.
Параллелизм хорошо работает в физически распределенных системах. В рамках одной машины параллелизм означает больший расход энергии и соответственно более быстрый перегрев процессора, что приводит к троттлингу. И вот казалось бы то что должно было работать быстрее, теперь работает еще медленнее чем раньше. Параллелизм на одной машине это как закись азота в гонках в какие-то критические моменты можно его врубить, но постоянно на нем не покатаешь.
Суть оптимизации в том чтобы сделать ту же самую работу меньшим количеством действий и ресурсов, а не в том чтобы одновременно делать много.
Масштабируемость сильно зависит от реализации. Часто в опенсорсе вижу архитектуру, когда все задачи синхронизируются в одном месте, а это затык для большого количества потоков.
Как-то реверсил idTech, они в 6 потоков рендерят, не то что UE. Но там движок с нуля написан, это проще, чем перенести огромное легаси на новую архитектуру.
Еще на GDC был доклад, где сетевой шутер (хало?) запускал симуляцию независимо от рендера. То есть симуляция стабильно работает на своих 30/60Гц, а рендер добавляет интерполяцию и может рисовать больше кадров.
Интерполяция на стороне рендера так себе идея потому что чтобы сделать ее правильно нужно понимать природу движения. То что объект сначала был в позиции 10, а потом в 30 не всегда означает, что между этими кадрами он был в позиции 20 потому что он мог телепортироваться например, а рендерер покажет мелькание. Правильная интерполяция должна быть внутри обычного шага симуляции обновляющего состояние объектов, но на местах вместо полного вычисления может использовать предыдущие вычисления с учетом природы движения объекта для получения результата.
Task-based мышление в игровых движках