Обведено кружочком красным. Специально же обвел.

Ты пост внимательно читал? Запись видео сделана справочно, чтобы понимать что и где я делал. Запись сделана с 15фпс 480р NVENC, чтобы показать нормально потоки, ибо при качественной записи их количество падает до трех основных, ибо запись любая нагружает и так перегруженный проц. Даже эта запись сжирала 10фпс из 120. Полноценная запись 720р@60fps снижает фпс до 70кадров. Я не стал снимать телефоном экран.

Вот с Vsync, а первый скрин выше был без vsync


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

Мониторинги все, и фрапс и АВ, снимают данные на выходе из игры, до отправки данных в ДХ и драйвер и видеокарту.
#77

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

Alex TOPMAN
Я собственно к чему этот вопрос поднял. Корректно ли оценивать производительность процессора в играх через замеры этих 1% и 0,1% ?
Вот типа у Райзена крутые проценты эти 1% и 0,1%. Хочу разобраться подробнее что и где происходит.

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

При использовании SLI обязательно включение Vsync. При этом процессор должен иметь приличный запас мощности на рендер кадров, как кстати и видеокарты. И проц и ВК не следует нагружать более 80-90%, пререндер кадров 2 или 3, тройной буфер в панели дров. Попробуй подогнать настройки под эту концепцию и слайдшоу должно пропасть.
А зачем у тебя разгон через шину? Предел множителя у памяти преодолеваешь?

Еще у Нвиди кажется есть какой-то Vsync плавный для SLI, специальный. Если я правильно понял, то там применяется типа амдешного Frame Pacing - дрянь еще та. Показывает тебе старые кадры, которые были 2-3 кадра назад, когда новый кадр не пришел вовремя. В мониторинге выглядит круто и плавно, а на деле гавно лютейшее и лагодром.

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

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

Да. Только у КП, а не самой памяти. Он много модулей не любит.

Перепост сюда, т.к хочется вычислить бяку, а в теме по DPC молчат

У меня бы так не подгорало, если на старых титанах серии 7хх и вин7 были те же траблы. Но их не было. Даже на квадСЛИ.

Slimchanskiy
Заменить мышку (повысить/понизить частоту опроса порта), попробовать эмуляцию мыши нумпадом клавы, убрать разгон монитора (наверняка же не тестировали это фотоаппаратом, да?), не использовать fastsync или другие нестандартные vsync.
Alex TOPMAN
А пробовал на шине 100мгц? Вдруг видяхам не нравится твоя шина.

Конечно же, это первое, что я пробовал возвращать в сток. Не помогло.

Подскажите, господа.
Монитор и телевизор подключены соответственно по dp и hdmi к одной карточке.
При выводе изображения только на телевизор - все ок, при разделении или дублировании экрана - тиринг (касается только телевизора, с монитором все хорошо в любых комбинациях).
Я научился с этим жить, но может есть решение?
Как прекрасно было бы жить в мире, где не нужно нажимать ctrl+P, чтобы посмотреть фото котиков на 40 дюймах.

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

ReXaN
Я тоже это вижу. Я задавался этим вопросом и выяснил.
Дело в h.264 кодеке, который делает кадры смазанными. Нажми на паузу в любом видео и оно будет смазано. Без смазывания пишут такие кодеки как MJPEG - там все кадры тупо дискретные фотографии. Игра это тоже тупо дискретные фотографии. Поэтому для похожей плавности в игре нужен.... мойшон блар. Если его нет в игре, то можно добавить решейдом, но это хуже, потому что лучше это сделает движок игры, который в отличии от решейда имеет доступ к нескольким старым кадрам.
Ну а кроме этого, видеоряд в h264 имеет полностью равномерный фреймтайм.

У меня даже была идея пропускать видеовывод с видеокарты через какую коробку, которая жмет в h264 и разжимает на лету. Есть такие удлинители HDMI на сотню метров. Но поизучав обзоры, я выяснил, что меня ждет лаг видеоряда в 300-600мс. Короче бред выйдет. Тогда я поставил эксперименты по фреймтаймам, которые можно посмотреть на прошлой странице. Это ничего не дало в плане плавности как на видеозаписи. Т.е. дело только в кодеке.

Кстати, из-за смазывания кадров h264 - на видео не получится показать микрофризы. В этом поможет MJPEG и желательно писать со 120фпс, причем внешней картой захвата. Пережимать такое видео в h264 разумеется нельзя - все микрофризы будут удалены построением межкадровой разницы - сути такого сильного сжатия видеопотока. Т.е. на ютуб такое выкладываать - бред. Только на файлообменник. Размеры видеофайла будут просто ацки конские. Более 2 гигабайтов за 1 минуту.
Хотя, если сделать захват в 180фпс MJPEG и замедлить видео в 3 раза, а потом замедленное сжать в h264 60фпс, то может быть получится показать микрофризы на ютубе.
А микрофризы которые видны на обычном видео ютуба - это уже писец какие лаги.

Genrix, спасибо за ответ . Я думал, может что нужно что-то с монитором сделать или ещё что.

Плюс в карму за расследование. Но фокус-то в другом. Кодек лишь исправляет то, что уже есть. А почему оно есть?
Я вот, вчерась до установки 1080ти ещё раз проверил проблему "инпутлагдиписигдетыплавность" на старом ПК с Q9450, X48 и gtx480, запустив сначала Деда Спейса первого, а потом вслед за ним новый флатаут 4, отключив у всех все "киношные" эффекты. Так вот. Проблема - есть. И не в паскалях она. Дед-то - ещё как тряхнул стариной. И, умеет, ведь - не коробить глаза... А флат - чуть неудобный, по мнению частоты развёртки, фпс, так сразу себе глаза выцарапать хочется. Так что это? Директиксы раньше, как трава - зеленее были? Или мультиплатформенность движков так сказывается, как в том анекдоте про "одной ногой здесь, а другой в коммунизме - на раскоряку стоять"? Индусов могу ещё вспомнить, но надо ли...

Глаз способен различать уровень мерцания, она же частота фпс, до 250 или 280 Гц. Где-то читал я про такие исследования. Сказать сколько - глаз не может. Но сказать, что мерцание лампочки на 150гц отличается от 280гц - может. Глаз - аналоговое устройство и он замечает дискретность игры. Смазывание дискретности обманывает глаз и он видит картинку менее контрастными вспышками.
Какое мерцание глаз лучше заметит - если лампочка будет тухнуть до 0% яркости или до 50%? Вспоминаем кстати лайт буст эффект в мониторах.
Alex TOPMAN Что-то нарисовалось в голове? Т.е. когда реально показываемый фпс перевалит за 300, то глазу ненужен будет мойшон блар. Моники 240гц уже начали производить. Надо только еще комп такой собрать, чтобы смог.

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

а у тебя в дедспейсе фпс наверное был раза в два выше, чем в фаллауте. Да? И не факт, что мойшон блар отключается полностью. Надо проверять на записи MJPEG-ом

Вообще директы раньше были другими, но емнип это было до дх9.

Разница в производительности прямого и отложенного

Загрузку CPU в студию! Очень похожее было в ROTR, когда из X3440@3.8GHz сделал Core i5-760@3.8GHz и проц на 100% упарывался.

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

А как вообще с всинк можно играть? Там же инпут лаг адовый появляется, и не важно какая видеокарта у тебя.

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


Не понял, шутку юмора, а чем shadowplay не угодил? Он даже на 2-х ядерных селеронах фпс практически не дропает.
NVIDIA Capture Server загрузка CPU 0.2 - 0.6%!!!


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

Соглашусь, играл в Rise of Tomb Rider DX12, фпс хороший 60+, но ощущение, как, примерно от 45, запускаю только что отснятое видео из этой игры, и запись идеально плавная. Один из способов бороться с "неплавностью" - это покупка 120Гц+ монитора, на таких мониторах, во первых, просадки до 45-50фпс ощущаются не так страшно, как на 60Гц, а фпс 75-80+ уже кажется практически идеально плавным.

Воооот! Наконец-то, нашёлся человек, который пояснил нам, где "собака зарыта". Перед раскрытием основной темы - уточню:
Я ведь, правильно понял, что "отложенные" движки делают на ВК несколько проходов рендеринга ровно столько раз, сколько "захочется душе поэтаразработчика"?

Я думаю да. Но, тут задача из школы с кучей последовательных бассейнов. 1-2-3-4-5. Первый это инпут с мышки, 5 - выход на кабель монитора. Между - директ, дрова, сама ВК. Это означает, что кол-во проходов у ВК в принципе не имеет значения для инпут лага, потому что вода по бассейнам должна литься с определенной скоростью 60+фпс везде и у ВК на 1 кадр в любом случае есть только 16,6мс. Конечно, сам многопроходный рендер может делать себе хоть 10 буферов для хранения промежуточных результатов, это лишь перегружает шину памяти. Конечный кар все равно должен быть нарисован за 16,6мс.
Нам важно сколько будет буферится готовых кадров при этой технологии.
Хорошо, если один дополнительный, в сравнении с прямым рендером. Я так понимаю, что прямой сразу записывает в буфер из которого монитор забирает кадр. А для отложенного нужно минимум еще один, в котором проходами формируется кадр, а потом копируется в буфер откуда его заберет монитор, а пока монитор забирает, ВК уже начала формировать новый кадр проходами. Ну или прямой юзает 2 буфера - 1создание и 2для монитора, а отложенный 3 - 1многопроходное создание кадра, 2 стыковочный, 3для забора монитором. Потому что запись и чтение из каждого буфера (даже монитором) занимает время, поэтому чтобы не было простоев (не толкались жопами - кто читает а кто пишет) - буферов несколько.
Но подробнее - уже за моими пределами, тут у девелоперов надо спрашивать.

Вот тут, я в корне не согласен с выводами. Хотя, пример про бассейны - удачный. Давай не забывать, что работу над кадрами можно и нужно вести параллельно сразу над несколькими, чтобы оптимально и под завязку загружать очень многопоточные ресурсы видеокарты. При этом, обеспечить на общем выходе с конвейеров желаемые 60 фпс можно очень даже просто. Если для одного потока - нужно уложиться в 16,(6) мс., то для десяти параллельных потоков можно будет вполне вольготно рендериться каждым потоком в отдельности и до 166,(6) мс. Учитывая, что от кадра к кадру фпс резко скачет крайне редко, да и то, в основном при кардинальной "смене игровой обстановки", т.е. когда плавность, по сути, никого и не интересует вовсе, а значит серьёзная синхронизация всех потоков и не требуется. Достаточно стартовать каждый следующий поток рендера ровно на 16,(6) мс позднее предыдущего и всё будет ок. И из всей этой математики прекрасно видно, что каждый конкретный кадр, как ответ на свои игровые действия, юзер будет получать на экране через х1+х2+х3+х4+х5 мс (где цифры - номера бассейнов), где именно наш конкретный бассейн х3, добавит либо всего 16,(6) мс, либо "ужасные" 166,(6) мс.

Недавно перехватил себе с рук недорого ASUS PG258Q с честной матрицей 240Гц. Об опыте пользования (про плавность) - по порядку:
1. В винде 240Гц чувствуется сразу по отображению движения курсора мыши. Чётко видные на 60 Гц отдельные фреймы прорисовки курсора (кстати, можно их число где-то настраивать? На 60 Гц круг мышой раз в секунду содержит нифига не 60 фреймов, а заметно меньше), видны и на 120/144 Гц, но уже как быстрое слайдшоу - на 240 почти превращаются в единый шлейф. Может это пока глаза не привыкли к новой скорости, но всё же - гораздо приятнее смотрится. И явно ощущается даже некая герцовая "моща" монитора, по сравнению с остальными. Имхо - полный зачёт Асусу и матрице.
2. Из игр: в КС не играю (но позже поставлю и проверю обязательно, как выглядит), пока только в Survarium нашёл нужные и более-менее стабильные 240+ фпс (это пока временно на ЦПУ Q9450 c 1080 Ti сижу). И... не плавно ни черта! И г-синк включал/отключал. И лок фпс на 242 делал (через Бандикам, т.к. RTSS больше 200 лочить "не умеет"). Ничего не помогает. Дёрганость (статтеры/микростаттеры/лаги - я уже запутался, как их правильно называть) присутствует. Пробовал вчера - много вариаций подёргать не успел. Так что, пишите как ещё проверить.
Кстати, если кто научит, как записать видео на полных фпс, а потом его замедленно воспроизводить, чтобы явно лаги видеть - напишите. Видео - с меня (для его записи есть Samsung 960 PRO или поставлю Рамдрайв или i-Ram на 4 ГБ).

Добавлено спустя 4 часа 6 минут 12 секунд:
Самое интересное (забыл добавить), что при активации г-синк, частота монитора (а pg258q умеет оверлеем из своего меню выводить её значение на экран в любое время) даже по почти стабильных 240 фпс (меню игры Сурвариум - сцена одна и та же без изменений, инпутов нет), скакала так резво и амплитудно, как на балалайке сыграть никто никогда не сможет. Хотя по описаниям технологии г-синка, должны были получиться те же герцы, что и фпс, просто выведенные не обязательно равномерно (с разницей в значении тайминга каждого кадра). Таким образом, в моём случае я должен был увидеть почти ровные 240 Гц (ну, может +/- немного кадров), а не такую свистопляску. Очень сомневаюсь, что это кривой железный мониторинг у самого ASUS. Что это может быть? У кого-то ещё было подобное?

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

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