Именно цпу-шный и есть. ВСЕ там замеряют фпс, ВСЕ мониторинги. Только FCAT железка может померить что реально выходит из карты. Однако, не забывай про бассейны - они не могут переполнятся. И тут возникает как бы обратная связь, если всё уперлось в видеокарту - проц не нарисует новый кадр, пока ВК не отрисует старые и не освободит буферы. А значит через этот фпс фактически видно и видеокарту. Но, что происходит при тестировании при упоре в цпу - пока открытый вопрос.
К тому же, пока по предварительным слухам, видеокарта может выбрасывать кадры и браться за более новые, но при каких условиях и действительно ли это так - мне пока точно не известно.
Но, сравнение FCAT и фрапса делали в нашей лабе - средний и обычный минимальный фпс совпадают, а вот графики фреймтаймов - нет. Фрапс показывает картину намного хуже, чем она выглядит на мониторе - то что видит FCAT. Поэтому я и угараю с красных придурков, которые носятся с этими 1 и 0,1 процентными графиками райзена, снятыми разумеется фрапсом.
Чтобы получить тебе стабильный 240фпс, тебе надо выставить такие настройки графики, чтобы видяха была загружена менее, чем на 85% и одновременно фпс был выше 250фпс по обычным циферкам фрапса на экране. Проц должен тащить этот фпс, разумеется. После этого не меняя настроек включаешь VSYNC на 240гц. И тогда уже оценивай плавность.
Все эти Гсинки и фрисинки по сути фигня, скорее кастыль для бомже-пека в 45фпс, против честных Vsync 120+гц когда система может рисовать эти 120+фпс. Мое мнение.

Добавлено спустя 4 минуты 44 секунды:
Записать много фпс видеозахватом? Я не знаю как записать 300фпс, видеокарта может и справится с 300фпс на 480р, однако MSI AB(он походу единственный кто имеет регулировку фпс) может писать максимум со 120фпс, а этого мало. Надо 360фпс и потом в редакторе замедлить в 6 раз до 60 фпс. Нужен строго кратный фпс - 120, 180, 240,360,420.
Как вариант - есть фотоаппараты ( не мыльницы, а такие уже бодрые по 400+$) которые умеют писать 300 и 480фпс, но в разрешении 480х360р или около того. Хотя для оценки плавности этого хватит. Можно у знакомых поискать такой фотик во временное пользование.

Добавлено спустя 3 минуты 48 секунд:
Alex TOPMAN
Ты умеешь пользоваться Reshade? Если нет, лучше научиться, полезная штука. Там есть шейдер Motion blur, стоит попробовать с ним поискать дзен плавности. А вдруг на глаз мойшон блар при 60гц круче, чем герцовка 240гц без мойшона?

"Так ведь, меня интересует не сколько мужу где-то там на заводе зарплату платят, а сколько денег он - домой приносит!" (С) народное (хоть и только что сам придумал). Так ты хочешь сказать, что до сих пор меня так некрасиво обманывали на счёт получаемого мной фпс? Вот, где, хоть в одной статье прямо и честно сказано, что показываемые на графиках цифры фпс, это не то, что я вижу у себя на мониторе (и как, кроме меня, думает подавляющее большинство читателей этой статьи), а количество кадров, которое где-то там внутри ПК ЦПУ передаёт ГПУ (а что с ними дальше происходит - одному богу известно)?
(это я себе)

Добавлено спустя 44 минуты:

Переполняться - это понятно. Но, кто сказал, что ЦПУ не может продолжать рисовать новые кадры? Как раз, наоборот: если может, то должен! Ждать ГПУ, а только потом приступать к новому кадру - это непроизводительная потеря времени. В идеале, новый кадр должен быть готов ровно к тому моменту, когда он понадобится ГПУ. На основании таймингов предыдущих кадров это спрогнозировать нетрудно. Если ГПУ тратит по 12 мс на кадр, а ЦПУ по 7, то при выставленном локе фпс, ЦПУ должен приступать к следующему кадру примерно спустя 5 мс после готовности предыдущего. Если ЦПУ тратит на кадр 5 мс, то даже без лока пусть молотит лишние, т.к. ГПУ сможет взять самый последний - более востребованный кадр (просто выкинув предыдущий). Напомню: тройной буфер и перезапись кадров в буфере - никто не отменял.
Так что, на ЦПУ и на ГПУ это совершенно независимые и асинхронные процессы. Имхо, должны быть - если писатели дров с головой дружат и не поставили ЦПУ и ГПУ в жёсткую связку, как описал в своём посте ты.

Добавлено спустя 10 минут 18 секунд:

Тут как раз всё понятно: при лимитировании ЦПУ, ГПУ либо ждёт в синхронизации следующего такта, чтобы снова опросить буфер на наличие (появление в нём) кадра от ЦПУ, либо в асинхроне ждёт команды, что кадр в буфере появился. ГПУ всё время ожидания, ессьно прохлаждается, ибо про интерполирование промежуточных кадров при малом фпс, я что-то до сих пор ни от одной игры и от драйвера не слышал. А не мешало бы!
Про "выкидывание" - читай чуть выше, о случае с 5 мс на ЦПУ против 12 на ГПУ (2+ кратное превосходство).

Добавлено спустя 4 часа 8 минут 4 секунды:

Именно так вчера и проделал с X3:ReunionRollingDemo. Всё предельно плавно. Красота неописуемая. Синки, не синки - плевать. Выглядит одинаково отлично.

Добавлено спустя 12 минут 2 секунды:

Проблема в том, что я терпеть не могу любые Motion Blur, DOF и пр. мылоэффекты в любом их виде. За 30 лет общения с играми (в основном на ПК, но не только) я понял одну простую вещь: игры интересны не как кино с их в большинстве дебильными спецэффектами, а как "окно" в другую реальность. И чем детальнее вид за "окном" и физичнее анимация - тем лучше. Как конкретный пример: последний тест от Unigine - Superposition, я иначе, как "симулятором плохого зрения" не назову. Да, вот так грубо и категорично! Пусть его создатели на меня обидятся, но у них не получится сильнее, чем обижаюсь на них я.
Вернёмся ненадолго к Reshade. НО, если под упомянутым тобой Motion Blur скрывается банальная интерполяция фпс (как я уже вспоминал выше), то это в корне поменяет дело (тогда зачем назвали не к месту? из-за плохого качества интерполирования и похожести на блюр?).

Добавлено спустя 41 минуту 14 секунд:
Немного продолжения на данную тему пришлось отписать здесь: Все о технологии SLI #14712760.

Ты забыл про бассейны? Зачем процессор будет всё время рисовать кадры? Какой смысл, если через тебя замыкается обратная связь в игре: рука-мышка-ПК-монитор-глаза-рука-мышка-... Всё равно на отрисовку в ВК пойдет только самый свежий кадр. При упоре в гпу процессор ждет(простаивает) пока видеокарта освободит для него буфер, отрисовав кадр из очереди. При ожидании процессор переходит в состояние простоя C3. Это можно увидеть из мониторинга HWInfo по проценту времени нахождения процессора в C3.
Когда рендеринг упирается в цпу, то его ждет видеокарта, которая снижает свои частоты.
Есть другой вариант работы системы - FastSync. Видеокарта выводит кадры ровно, но рисует сама себе сколько может. Однако лично у меня на Кеплере ФастСинк показывает жуткий микростаттер, мне иногда кажется, что на экран выводятся старые кадры после новых - при плавном вращении камеры джойстиком объекты в кадре как бы дрожат, иногда как бы возвращаясь назад - проскакивают старые кадры.


Ну, где-то так да, этот фпс не настоящий, но близкий к этому. Мониторинг системы это сложный вопрос. Вот как мониторинг за поведение света. Пока не наблюдают за ним - он волна, а как начали подглядывать - хренак и он частица. Потому что любое наблюдение влияет на системы. Если захотеть наблюдать очень точно, то сам факт такой точной отчетности системы о своих действиях может довести до того, что эта отчетность займет половину или больше времени работы системы ( прямо как на работе при плохих манагерах ). Что ты тогда получишь? Половину фпс? И какая конечная польза?
А выкидывание картой кадров - просто услышал такое, без пруфов и теорий, надеюсь скоро этот чел запилит видос и про этот момент. Мои знания уже закончились. Лезть дальше - слишком много усилий, непрофильных. Подождем, может профи расскажут.
Вообще нам бы тут помог Serj, но он кажется уже оставил этот форум.

Все должно быть в меру. Мойшон разрабы не редко делают как кисель, и хорошо если они дали крутилку силы мойшона. Решейд же позволяет настроить силу под себя. Мойшон блюры, тупо анализируя векторы движения прошлых кадров, смазывают текущий кадр. Они не делают промежуточных кадров. Собственно его механизм больше похож на монитор с 12мс матрицей. Хотя тут надо ставить живые эксперименты: тормознутая матрица vs быстрой + MB vs Н264. А то все хотят модных 1-2мс + лайтбуст. Вдруг зря? Вдруг вся эта не плавность - следствие впаренной матрицы 2мс и надо было брать кисельную 8мс? Вопрос.

Ты сам описал связь не обратную, а догоняющую по кругу. Она не требует ожидания на отдельных этапах перед последующими действиями. Это как бег по кругу: можно синхронно эстафетой, с ожиданием в конкретной точке старта, а можно просто бежать, асинхронно, пока не догонишь на круг. Ключевое слово: "замыкается". Не обязательно делать это фиксированно. Пока ты думаешь сделать ли инпуты, можно нагенерировать кучу кадров и без них. Ведь игровой мир продолжает меняться и независимо от игрока. И наоборот, при частых инпутах - стоит пропускать их до начала следующего тика рендера и там уже брать для очередного кадра последние/средние/суммарные инпуты (у кого что). Имхо (как программиста), гораздо сложнее ловить момент начала создания ЦПУ очередного кадра, чтобы он поспел как раз свеженьким к освободившемуся (не ждущему!) ГПУ. Если же наоборот, тупо без заморочек: отработал один, следом начал другой, а остальные в это время отдыхают - то это крайне непроизводительная потеря времени и ресурсов. Такой подход оправдан лишь на начальном этапе, пока технология свежая и всем в диковинку. Но, на обкатанных за годы рельсах за такую "оптимизацию" - больно и сразу бить надо.
А про бассейны я не забыл (написал же выше). Кадры ЦПУ может генерировать и в null. Гораздо проще ему не отвлекаться на всякие "надо ли" и "не надо ли" и тупо штамповать кадры без остановки ("поручик Энергосбережение - молчать!"), чем отвлекаться на подобный анализ. (просто поверь, если сам не пробовал) При этом: поступит инпут - учтём в ближайшем (не текущем!) кадре. Не поступит - ну и пусть. Всё равно шоу маст гоу он.

Добавлено спустя 2 часа 1 минуту 17 секунд:

Ну так я выше и про ЦПУ то же самое написал. Готовит сколько может и складывает в один буфер (если он двойной) или по очереди (если буфер тройной), пока из другого читает ГПУ. Эта схема работы стара, как мир.

Добавлено спустя 9 минут 13 секунд:

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

И тут опять не всё так просто. Например есть проблема вывода на экран видео 25к/с, когда монитор 60гц. Т.е. ему удобнее выводить 15-30-45-60фпс. А 25 не вписывается никуда. Поэтому существует режим 3:2 pooldown или как-то так. Что-то он там химичит, гавно какое-то короче.
Смысл в чем. У тебя 60гц - 60 временных окон. Допустим проц или ВК рендерит 90к/с. Нет кратности. Это приведет к тому, что при линейном движении камеры в игре какой-то объект будет перемешаться не линейно, а будет 2 коротких по дистанции перемещения и одна дистанция длинная, или наоборот. Ты же предлагаешь брать самые свежие кадры. Они наверняка будут не кратные и с нелинейной разницей перемещения объектов. А это же старый добрый микростаттеринг.
Возможно я это и вижу с фастсинком, потому что у меня плазменный телек как монитор, а у него матрица скоростью менее 1мс, вроде бы 0,1мс. Все плазмы такие по технологии. Т.е. я могу видеть все кадры.
Но можно же рендеритть и 120фпс и фастсинком выводить 60, тогда есть кратность. Да, но опять же - я вижу фпс после цпу, а что там делает ВК - blackbox. Хз что идет по факту на монитор при этом фаст синке. Может возникать та же нелинейность перемещения обьектов из-за не точной кратности выборки свежих кадров - было несколько тормозных кадров и последовательность нарушилась.
Я думаю мы тут с тобой не до чего толкового по итогу не докопаемся, нужны более глубокие знания.

Не-не. "Неправильной стороной ты, Дядя Фёдор, бутерброд ешь" (С) сами знаете, кто.
Рассматриваем пока классический случай с всинк на 60, т.к. проблемы мы имеем даже в нём. Временные окна идут через равные промежутки времени. И для случая, когда ЦПУ успевает их настругать раза в 2 и больше, у ГПУ на очередное окно имеется выбор, брать самый свежий кадр, или не самый. На следующее временное окно выбор снова тот же: новый предыдущий кадр, или новый последний. Фокус в том, что все "предыдущие" кадры, были актуальны 1/120 сек назад в середине временного окна, пока показывался один из предыдущих кадров. А сейчас, к началу нового фрейма, он перестаёт быть актуальным из-за появления нового - последнего, более актуально отражающего игровое состояние для игрока, т.е. на 1/120 сек. назад, когда он подал или не подал свежие инпуты, а не на 1/60 сек. ранее. И такие "устаревшие" кадры - только выбрасывать. Они никогда уже не смогут быть показаны. И это нормально. Ничего страшного тут нет. Однако, лочить фпс и их "не готовить вообще" - хуже, чем готовить, но потом выкидывать, т.к. в игровом мире, в последнем случае, инпуты будут движком обработаны и засчитаны. Особенно актуально это для сетевых шутанов. Не отправлен сетевой пакет - считай, что ты "ничего не делал".

Добавлено спустя 4 минуты 16 секунд:

правильнее pulldown вроде как

Добавлено спустя 4 минуты 54 секунды:

Да не надо целый огород городить. Вставляешь свой счётчик на выход кадра из буфера (любого, а лучше все буфера по отдельности посчитать) и меняешь его значение на +1 при считывании из него кадра (начале и завершении считывания - для верности). Чего сложного-то?

Добавлено спустя 7 минут 1 секунду:

Вот, хоть убей, не понимаю, зачем портить мне готовый и чистый кадр n или n+1, если всё равно считать между ними ту же самую разницу (n + n+1)/2 (попиксельно, ессьно)? Втыкать интерполированный же в 100 раз логичнее! Пустой фрейм - всегда найдётся, т.к. фпс чаще не хватает. А кому хватает - у них плавность есть и никакие блюры и в попу не упёрлись (да и модные нынче ips матрицы сами блюрят будь здоров).

Добавлено спустя 21 минуту 4 секунды:

Проще некуда. Мы сейчас пишем про внутренние буферы между ЦПУ и ГПУ. Там нет никакой привязки к 60 Гц и т.п. Как хочешь их - так и тактуй. Имхо, HPET вообще должен позволить делать это асинхронно: ЦПУ когда положил - тогда положил, а ГПУ когда взял - тогда взял. И никаких кратностей не нужно. Всё это должно работать без лагов и задержек (см. скорость клока системного таймера).

Добавлено спустя 3 часа 16 минут 47 секунд:

По ссылкам выше Серж пиcал, что без команды Present от ГПУ об "освобождении от работы над последним кадром", ЦПУ работу над новым не начнёт.
Если такая ситуация и по сей день, то это очень и очень печально...
В свете последней энергосберегающей моды я не поленился (ещё в прошлом году) и залез в эти настройки у ЦПУ: посмотрел их, подёргал...
Короче говоря, пока ЦПУ ждёт Present от ГПУ - он в 100% случаев (если не подбадривать его "сторонней" работой) успевает уснуть или даже запарковать часть ядер.
Так что, в расчёт накладных затрат на подготовку кадра можно смело закладывать ещё и время пробуждения ядер ЦПУ и время выхода их частот на полные (это происходит не мгновенно).

Сколько не проверял относительную плавность дает толmrj Всинк принудительный. Остальное все шлак везде рывки либо разрывы. И да надо что б система как минимум тащила монитор и запаса хватала +. Хотя мониторы с адаптивными (синками) это вполне себе неплохой костыль. Ибо когда система немогет а стоит всинк то картинка вообще печальная ибо система отрисовать не успевает даже то что находиться в очереди буфера. И там начинаются реальные тормоза.

Гонял вчера свой монитор ASUS PG258Q на частотах 60, 120 и 240 Гц. Никаких всинков! Плавность в некоторых играх есть (без рывков и разрывов), в некоторых нет. Даже на 60 Гц после 240 и то почти также плавно кажется, правда шлейфы за объектами видны сильнее (что всё же портит плавность, а не помогает, как пишут некоторые). Это из-за более медленного зажигания/тушения пикселов. Впрочем, www.testufo.com точно такой же эффект и показывает. Как кто-то правильно на форуме заметил: любой монитор стоит юзать не только в родном разрешении, но и на его штатной частоте, ибо всё иное - ухудшает восприятие. Разрывов меньше с правильным локом фпс - который максимально близко к частоте обновления. Но, его подбирать сложно, т.к. далеко не везде круглые 60/120/144 и пр. Гц. А задавать лок часто можно только целым числом. Из-за этого, изредка разрыв по экрану всё же проплывает. И тем он реже, чем точнее подобран лок к частоте. Я пробовал, как иногда советуют, задавать на кадр/два и больше и меньше. Но разрыв во всех таких случаях появляется чаще (и этому есть вполне простое и понятное математическое объяснение).

А вот интересный материал о технике рендеринга постэффектов: https://habrahabr.ru/company/pixonic/blog/327442/
Как я уже указал ранее, каждый дополнительный проход на свой спецэффект, только добавляет инпут лаг (вместо того, чтобы задуматься о его максимальном снижении).
И понятно, что упрощение настроек качества, детализации и сложности каждого отдельного шейдера, не отменит того факта, что поверх картинки накладывать придётся всё то же самое количество эффектов (число проходов рендеринга не снизится, только если сам шейдер не был предельно упрощён до их меньшего числа). Поэтому, заметно снизится скорее число задействованных блоков ГПУ, но не длительность исполнения такого конвейера шейдеров (что мы часто и наблюдаем в виде недозагрузки ГПУ при недозагрузке и ЦПУ тоже). Решение, как подсказывает нам статья - пробовать в настройках/конфигах полностью отключать (т.е. совсем, а не убирать на минимум) какие-то спецэффекты, пока лагание не снизится до приемлемо "незаметного". Попытки же "смазать" начавшую лагать от большого числа эффектов картинку ещё одним дополнительным постэффектом, станут сродни "лечению поноса сменой памперсов".

В связи с вышеизложенным, для нас становится наиболее интересным значение мгновенного frame time, потраченного на один конкретный кадр. Сразу же замечу - посчитанного ни в коем случае, не тупо разницей времени между выданными финально предыдущим и последующим кадром. Это важно! Усреднённое же значение frame time, которое даёт нам ряд программ мониторинга, может "исказить" для нас понимание реального инпут лага (при чём, часто он считается вообще только на этапе ЦПУ! Почему - читайте посты ранее.) на величину вплоть до в N раз (где N - число параллельных потоков рендера). Поясню это на примере: автобус перевозит 50 пассажиров по маршруту в 10 остановок за 50 минут (вместе с высадкой/посадкой). Для повышения производительности, добавили на этот маршрут ещё 4 автобуса. Пассажиров стали перевозить уже 250 за то же время на весь маршрут, но пассажиры, что в одном, что в пяти автобусах, по прежнему, находятся в пути все 50 минут. Другими словами, "инпут лаг" от входа пассажира в автобус до его выхода оттуда, остался ровно тем же самым. При этом, частота перевозки, в среднем на 1 пассажира (аналог нашего фпс) увеличилась, а среднее время перевозки одного пассажира(аналог нашего frame time) уменьшились в 5 раз.

Тройная буферизация, лага нет почти.

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

Причём тут монитор, если есть статтеринг даже без всинка или фаст синка?)) Кривую игру 240Гц не спасут.
Микростаттеринг - неравномерность времени кадра
Статтеринг - зависание от нескольких кадров и до секунд, намного заметнее
Лаги - сетевые задержки

Ага, попробуй сделай 120 фпс в фоллауте. Хоть 4 карты купи и 12-ядерный проц, а 120 фпс там не будет.
Гсинк идеально подходит для фпс ниже частоты монитора, а фастсинк для фпс выше. И всинк на 120фпс не лучше фаст синка на 240-360.
В фоллауте по ощущениям всинк даже плавнее, чем фаст синк, кстати.

А ещё там освещение как в пересвеченных пресетах для гта И жрёт фпс так же, 30 на 1080 в 1080р.

Только что об этом написал постом ранее.
Вчера, кстати, пробовал сесть заиграться в НидФоСпиды The Run и Rivals. Это просто капец какой-то. Гонка не автомобилей, а голимых спецэффектов.

Добавлено спустя 1 минуту 55 секунд:

Не соглашусь только с последним определением. Лаг - гораздо более широкое понятие. В твоём случае лучше было так и указать - сетевой лаг.

В играх у него одно определение - задержка, вызванная высоким пингом, потерей пакетов и т.п.

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

Я начинал играть в пару нфс только ради эффектов, нитры и крутых аварий. Ни одну из них не прошёл до конца, т.к. унылые гонки по 5 кругов надоедают уже через пол часа.

ок. пусть.


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

Alex TOPMAN Это не решение) Motion blur я и так не включаю, а без ReShade играть невозможно. Не игровое же сглаживание использовать

Опять ты не понял (далеко вперёд со своими мыслями ты убежал, похоже).
Решейд не имеет никакого отношения к игровому движку (любом). А я писал именно про него. Имхо, разработчики сейчас сильно увлеклись зарисовыванием картинки пост эффектами (чтобы не моделировать честно, там, где не особо или не сразу заметно, что и как подменено декорациями или мылом). Выключать я советовал именно игровые посты. А свои - ставь пожалуйста. Себе любимому ты ведь каку не подсунешь. Блюр не включаешь - я рад за тебя. Но часто по умолчанию он включен и его в этом случае надо лично залезть в настройки и выключить, а не "жрать что дают", как проще делать многим. Так что .

Alex TOPMAN
Никак пост эффекты не влияют на плавность. Сейчас играю в Homefront - The Revolution, все пост эффекты включены, даже Motion Blur поставил на средний.
Не во всех играх блюр в движении сделан так, что получается сплошная размазня, в некоторых он практически незаметен. В итоге за сотню фпс и абсолютная плавность.
Тот же фоллаут 4, что не отключай, никогда не будет так плавно идти, т.к. там постоянно провалы фпс и мелкие фризы.

В разных играх по разному. Если в игре "всё включено" идёт плавно и без вопросов, то нечего в ней крутить настройки пост эффектов и искать то, чего там нет.

http://nvworld.ru/news/2017/08/16/#480- ... -prototype
Цитата: "Удваивая частоту кадров, вдвое уменьшается дистанция между копиями изображений, образуя стробоскопический эффект. Это сказывается на FPS играх (например, мерцание при взгляде на волосы, а затем наблюдается шаговый эффект при повороте), — пояснили инженеры. Фактически, даже 1000 Гц при опросе мыши становится ограничивающим фактором..."
На секундочку! Я вот сейчас не понял. Это что же значит, при установленной на мониторе герцовке, вдвое большей чем fps в игре, изображение на экране 2 раза подряд дублируется не на одном и том же месте, а со смещением согласно перемещения мыши за время показа первой копии кадра?? Я проверю это лично, конечно... Но, что за балбес такое придумал, вообще?

Ответ на вопрос данной темы, всплывший вот здесь: Всё о GeForce для Windows XP/Vista/7/8/8.1/10 [WHQL: 387.92 от 9 октября; Hot Fix: 387.98 от 12 октября] #15110762
Цитата из следующего поста из ссылки:
"Но в моем случае, как только сгруппировал, то сразу почувствовал лучшую отзывчивость игрули."
Коллеги, а вам не кажется, что правильный ответ тут достаточно очевиден? Дело в том - с какой длиной очереди процессов работают планировщики (Винды, ЦПУ...). Ведь, с каждой новой виндой процессов всё больше и больше (в т.ч. и тех, что нам не показывают ). Пока до нашего "активного" процесса дойдёт длинная очередь к планировщику, чтобы... понять, что "ему нужно было без очереди".
Я же правильно понял, что группировка svchost виртуализирует его до "одного" процесса именно для планировщиков ресурсов? (тут, кстати, вообще - логичнее группировка процессов по приоритетам исполнения, а не по... названию ) И, имхо, я точно правильно понял коллегу iG0Lka "либо четкая легкая, быстрая реакция, либо как аутист ждешь пока игруля среагирует на действие чтобы начать следующее действие". Только я добавлю здесь от себя про случай именно "ватности" прицела, которое совсем не одно и то же (имхо) в сравнении с описанным "аутизмом". "Ватность": это когда игровое время и отображение всех, кроме мышиного, событий в игре идут без заметного лага, а опаздывает только мышь (точнее отображение реакции игрока или, ещё точнее, это выглядит как заторможенность реакции именно игрока на игровые действия, хотя по ощущениям и на самом деле он реагировал заметно раньше). А вот "запаздывание реакции игры": это когда тебе уже всё происходящее в игре показывают с некоторой заметной задержкой относительно твоих действий. Эти две вещи на самом деле чувствуются и воспринимаются по разному. Про последнее я уже даже писал здесь несколькими постами ранее (Обсуждение "плавности" в играх, технологий *Sync и т.п. #14752204), когда пояснял, как на это может влиять перегруженность игры графическими эффектами (особенно ресурсозатратными постэффектами).

Это не меняет ничего-активность всех дочерних никуда не делась,достаточно запустить tasklist /svc до и после изменений, в случае с группировкой,на процесс вешаются по-3-4- и больше задач.

Видно по команде. А так ну красивее диспетчер. Считайте упал 1 хвост упали все-3-4 процесса, + жор памяти. Разбиение очень грамотный ход на мой взгляд. Мелкие куски работают в своем пуле памяти не большом -к каждому привязан процесс. Очень наглядно,и гораздо безопаснее и думаю в каких-то сценариях и быстрее.

На 7-ке был такой ключ реестра- запускать каждую копию проводника в отдельном explorer.exe- корни этой идеи ещё с тех времён.