Meta* использует планировщик для Steam Deck на своих серверах

Готика1 и GTA3 передают привет.

В GTA не играл, но в Готике 1 всё было чересчур плотно напихано. Чуть не туда свернул, удирая от орка, и его рубят стражники, а потом избивают тебя :) И при этом размер долины шахт упёрся в предельный для движка. Для 2-й игры пришлось делать на острове 3 локации.

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

Ну а ГТА уже стала настоящей ГТА, ровно такой же как современные игры. Причём в ГТА4/5 можно врубиться в тормоза фоновой подгрузки, а в 3/VC/SA - нет.

там была именно что подргузка и она была фоновой и в 1 потоке

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

Думаю скриптово-коордиатые вопросы. Или даже сюжетно-производственные. Например пока одна часть команды рисовала Хоринос с окрестностями (а там на самом деле довольно скромные просторы), вторая часть абсолютно независимо могла перерисовывать и отлаживать сюжетку Рудной Долины. А потом после выхода начать работать над Ночью Ворона с планами внедрить её на уже начатые игры. И всё это - с минимальными изменениями движка. Они же подключаются друг к другу как отдельные игры!

Игры нынче многопоточные - один поток сабмиттит команд буферы, другой грузит ресурсы, третий считает физику, четвёртый работает с сетью (если есть мультиплеер) и т. д.

Так что хоть приоритетный процесс скорее всего и один (что тоже не вполне верно, ибо надо как минимум ещё чтобы X11/Wayland процесс не тормозил, а также какой-нибудь PulseAudio), но потоков в нём много.

Однопоточные только какие-нибудь ретроигры из эпохи одноядерных процессоров.

Чистый риалтайм это не про производительность, а про предсказуемость.

Что ты, например, делаешь sleep 10мс и уверен, что твой процесс проснётся ни миллисекундой раньше, ни миллисекундой позже. Это важно какой-нибудь плате управления роботом, потому что там рассогласование управления двигателями может привести к фатальным последствиям.

Риалтайм реализуется в том числе в ущерб общей производительности системы.

Можно провести аналогию с общественный транспортом - плохо не только если автобус опоздал, но и если приехал раньше (так как люди кто пришёл ровно к отправлению или у кого пересадка не успеют на него сесть) - и водитель, видя что опережает график, может специально тормозить и ехать медленнее, дополнительно ждать на остановках и т. д. Такси, у которого цель приехать из точки A в точку Б за минимальное время доезжает быстрее автобуса при прочих равных (но не гарантирует ни время отправления, ни время прибытия).

Короче, не нужен жёсткий риалтайм ни на серверах, ни в играх. Там нужен затюненный ненастоящий риалтайм. Чтобы не тупить дольше, чем можно (сообразно целевому FPS или Response Time), но не упускать возможностей сделать дело быстрее плана.

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