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

Ждём Ваших отзывов о материале:
Анализ журнала Fraps frametimes - выявляем фризы в играх.

Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
За статью можно проголосовать на странице материала.

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

отличная статья. интересно было бы глянуть на графики топовых карт, 5970 и 480

Спасибо за статью, очень интересно. Сам ни раз замечал на своей 5870, когда minFPS ~35 , но тормоза ощущаются сильно. Интересно посмотреть тесты карт 5870,5970,6870,480.

Интересно сравнить SLI vs Crossfire, какая система покажет меньше фризов...

автор, почему в таблице с основной платформой / платформой для сравнения стоит


в начале статьи
?

общий подход интересный, спасибо

Я почему то думал, что лаг это причина качества связи интернет, между сервером и клиентом. А фриз это причина железа, и драйверов компа. Я не прав?

Классная статья! Все в грамотно и ясно как в солнечный осенний день!
Обязательно протестирую свою систему!

Статья отличная.
Эх, добавить бы сюда методику определения причины лага (скажем, графики загруженности CPU/GPU/HDD и т.д.)...
P.S. надо понимать, что с экспериментальной точки зрения это не такой чистый эксперимент - FRAPS может вносить свои коррективы в работу системы, как и любое другое средство диагностики.

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

шикарная статья, пару моментов в голове обновила. Будет очень приятно, если данная методика еще будет подключена при тестировании следующих карт.

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

Методика подсчета неверная. Механическую группировку-отсев по времени рендеринга делать нельзя.
Заявление о том, что падение до 3фпс будет заметно, на чем основано? Ни на чем.

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

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

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


SabMakc
В каждой Windows есть Performance Monitor с записью и отображением в лог. Выбираете свой набор параметров и запускаете одновременно с тестируемой программой. Получите , к примеру, такой график (там я исследовал работу SSD vs HDD, поэтому набор параметров для той задачи):

#77

Методика определения причины лага требует иных инструментов и параметров - кроме времени рендеринга, еще и количество апишных DX/OGL вызовов, смен состояния рендерстейтов и пр.

Пару лет назад , когда в очередной раз на сайте придумывались "рейтинговые методики" по данным фрапса, я приводил некоторые графики, позволяющие отследить, что и почему проваливается (программа Pix из DX SDK):

#77

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

Dentarg
Спасибо за обзор.

Методика с некоторым натягом актуальна. Возможно в декабре или даже после НГ сяду ее ковырять. Сейчас на это нет времени, т.к. с головой занят разработкой скриптов AutoHotKey для полной автоматизации всего цикла тестирования.

Надо было тестить при включенном vsync + тройная буферизация (D3D Overrider).
Или вы (80%) играете без всинка с дёрганной картинкой... тода да.. маразм крепчал.

zauropod
Ценное замечание. Думал об этом, даже проводил эксперименты на "заметность/незаметность" фризов в разных ситуациях.
Так вот, даже "заминка" при смене плана вполне заметна и может негативно сказаться на комфорте игрока. Степень "заметности", разумеется, разная, но тут это имхо непринципиально.
Автоматизировать процесс полноценного выявления конкретной причины фриза и ситуации, в которой он произошел, на данный момент не представляется возможным. Хотя, опять же, наработки тут есть, будем стараться их развивать.
По мне так и уже предложенная методика представляет собой хороший шаг вперед.

zauropod
Про Performance Monitor знаем, слышали (в принципе, его и хотел указать, но название с ходу не вспомнил полное... Как оказалось, то что помнил и есть полное название ).
Но на сколько знаю, он не позволяет снимать данные загруженности GPU и видео-памяти. Для этого нужны другие инструменты.
+ с повышением числа инструментов понижается достоверность данных, т.к. каждый инструмент требует памяти, процессорного времени и записи лога на диск.
P.S. изучение этой статьи может дать очень хороший инструмент для поиска причин микролагов.
Но опять же: чем детальней инструмент, тем выше и трудоемкость...

Скажем так - не полная, но хотя бы позволяющая отлавливать фризы (вычисление причин - это отдельный вопрос, которые в идеале вообще не должен возникать, ибо фризы - зло)
Есть ещё неравномерность fps - но это пока вообще малоизученный момент (есть мнение что 25 стабильных fps лучше чем дёргание в диапазоне 25-45, несмотря на то что вроде бы второй случай всегда больше)
Игровые расчёты и отображение конечно тоже связаны, не буду спорить, что можно так криво написать движок что при плавном fps будут визуальные подёргивания (и никакой vsink не поможет), но обычно это не зависит от видеокарты.
А вот если видеокарта иногда считает кадр долго - то никакой движок не сможет это исправить (т.е. методика как минимум рабочая, хотя может быть она отлавливает вовсе не проблемы видеокарты - тесты и анализ покажут)

Очень интересная статья, спасибо!

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