Почему? В выбранном для примере тесте никаких сменов эпизодов нет. И в абсолютном большинстве тестов тоже - камера летает по определенной траектории, а смена сцены это уже следующий тест. Никаких затемнений тоже нет - что это за бенч такой, который бы показывал какой-нить текст на черном фоне без текстур. За эти несколько секунд он и 1000FPS легко покажет. Думаю, не нужно объяснять, сколькими способами можно запороть результаты, но это не говорит о неправильности метода.

Посмотрите, как называется статья:

Вот, что написано во вступлении:

Вот, что в заключении:


Статья доведена до логического конца. Я не утверждаю, что это нужно брать за эталон, методика определения причины лага это другая, более сложная задача. Оценка стабильности FPS - уже третья. Только Дмитрий Софронов с 3Dnews описывал похожую методику, но в работу она не пошла, т.к. он остановился только на нормальном распределении (десяток систем уже не сравнишь), да выдумывать заново способ вычисления основной массе людей будет лень, я же приложил готовый расчетный файл.

Сейчас я вижу только критику "этого недостаточно" и монструозные картинки типа таких или таких, а в статьях всё те же колбаски со средним FPS. Или "почему тестил так?" - я не результаты теста железки выкладываю, а рассказываю о методе. Главное, что бы другие прониклись сутью идеи, а какие графики, в виде кривой или в виде гистограммы - не важно. Надеюсь, что мой шаг лишь первый, буду рад, если другие предложат более подробные и не менее наглядные способы.

Наконец-то, повеяло научным подходом. Тут можно поиграть с процессорозависимостью, объемом ОЗУ и видеопамяти. Открываются новые просторы.

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

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

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

В реальных современных играх к основному сюжету подмешиваются определенные случайные возмущающие воздействия, что приводит к уникальности фреймов каждого прогона игры. Т.е. ожидаемых результатов и/или их повторяемости можно и не получить. И не надо привязываться к смене эпизода. Возьмите вместо этого изменение LOD объектов и виртуализацию памяти. Есть и еще много вариантов.

Поэтому лучше бы сразу предостеречь крутых бенчеров об узких местах, а не просто писать об "открытии новой методики".

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

Дорогу осилит идущий, желаю вам успехов.

статья получилась офигенная, автору (-ам) большой респект
тематика достойна внимания, как минимум , изложение продумано, есть и результаты и выводы - чего еще желать ?


вполне возможно что и некая "защита от дурака" сработает - ибо

Т.е., если хватило ума правильно получить и обработать большое количество данных - хочется верить, что и правильно осознать их тоже ума хватит.

п.с. вспоминаются чьи-то-там высказывания, что, мол - фрапс это вата, ни на что не способен и вообще им ничего нельзя мерить

Dentarg Я думаю вы понимаете что построив график с суммарным временем по оси ординат, а с количеством кадров/с от 0 до 30 по оси абсцисс вы показали людям лишь часть Гаусовского распределения. И если бы вы построили график с полным диапазоном кадров/с то мы бы увидели до боли знакомую картину.#77
если построить полные графики распределения на системах со "слабым процессором", "со слабой видеокартой", с малым количеством оперативы, и т.д. и все это для одной игры! то можно будет нащупать оптимальную конфу для нее. Но каждая программа индивидуальна.
Все нормальные люди понимают что делать 5 графиков для каждой игры и это перебор! (но труд стоит свеч, для фанатов игр это будет откровение божье )
Я предлагаю выяснить функциональную зависимость общего характера на кривую распределения.
К примеру по графикам видно что при добавлении в систему более мощной видеокарты среднее распределение смещается в сторону большего количества кадров/с(это как говорится и ежу...), а при добавлении более слабого процессора распределение кадров/с растягивается вдоль оси абсцисс.
Поэтому к тесту игр достаточно будет добавить только один график распределения и знающие люди уже смогут "прикинуть" как игра пойдет на их системе.
Спасибо за внимание.

Emperror911 А вот и не нет график будет сооовсем другой... Т.к. Тут суммарная вероятность...

Polarglow что это значит совсем? Это есть и будет график плотности вероятности. Просто он не будет нормальным.

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

Возьмите экскаватор и копните глубоко, мониторинг загрузки процессора(с приоритетами) ЖД, оперативной видео памяти, степень фрагментации файла подкачки (вообще если он есть) Процессы самой винды отслеживать тоже нужно, нельзя просто так тыать пальцем во "фриз" толку 0
И причина фриза? глюк кода игры\драйвера, поддгрузка с ЖД (опять же сколько фрагментов задействовано) Файла подкачки(опять же где он? и есть ли?) или это глюк райд контроллера??? как в случае второй системы...

Вы затронули льдинку на вершине большого айсберга....

S3 Но лучше тронуть льдинку чем проплыть мимо айсберга верно??

Polarglow график будет опускаться т.к. суммарное время среднего количества кадров будет гораздо выше чем например суммарное время 300 кадров/с.
график скорее будет вот такой логнормальный: #77

Emperror911 Убедили... Причем этот график более правдоподобен.....

Polarglowконечно лучше, но ещё лучше будет немного покопать... хотябы выснить что вызывает конкретный фриз (ЖД драйвер игра) а потом почему найдя слабое звено попытаться его устранить, не это ли OVERCLOCKING

S3 Абсолютно согласен... Но это только начало... Была высказана идея и теперь некоторые люди могут приступить не к ловле фризов.... а к их изучению......

Отличная статья. Я уже давно, читая обзоры по железу, сравнивающемуся в играх по среднему fps, вопрошаю "Ну где же распределения?!!" )) Скучно. А вот так - гораздо лучше!!



Ха! И описывать пару "игра-конфиг" параметрами функции распределения! )))

только не количество, а суммарное время ими занимаемое (это далеко не одно и то же), ну да Вы смотрю там сами поправились


Ой не факт, нормальное распределение там может и не получиться (и как раз при фризах скорей всего не получится), но не суть, то что предложено в этой методике вполне устраивает (1 хороший характерный график)