Ранее, в теоретической части материала рассматривались особенности построения картинки в играх и влияние на этот процесс нестабильности потока кадров. Но это были теоретические размышления, настала пора проверить, что же происходит в действительности.
Программы мониторинга работы видеокарт существуют в различных вариантах исполнения и их можно использовать для анализа построения картинки. Вот только… применение готового инструментария сразу начинает ограничивать возможности, а хочется всего и сразу. Что же, придется написать собственный простенький мониторинг.
Для получения адекватного ответа по построению кадров необходимо как-то получить достоверную информацию о том, «какой» кадр выводится и его продолжительность (количество строк на экране). На начальном этапе хотелось бы просто убедиться в том, что мониторинг работает адекватно, а потому какие-то «программные анализаторы» были оставлены на потом. Программа просто формирует маркеры, которые можно наблюдать на экране дисплея.
Этот прием совсем не подходит для автоматизированного измерения, но такой задачи и не ставилось. Цель – оценить, что же мы видим и как на это влияет нестабильность потока кадров. В качестве средства захвата можно использовать обычный фотоаппарат, к его характеристикам нет жестких требований, лишь бы маркеры четко различались.
Эти условия означают, что программа должна генерировать маркеры. Я использовал два типа – статический по левому краю и динамический, который смещается при выводе каждого кадра.
Фотоаппарат может захватывать показ нескольких кадров, поэтому на снимке отобразятся маркеры всех кадров, которые были показаны за прошедшее время.
Левый маркер выдается в каждом кадре тем же цветом, что и динамический маркер, цвета выбраны обычные – серый, зеленый, красный, синий. Если при выводе не возникает коллизий, то цвет левого маркера усредняется во времени и будет казаться белым. При возникновении пропусков или повторений станет преобладать какой-то оттенок, причем будет отслеживаться не только изменение цвета, но и место сбоя.
При построении изображения «в окне» в обязательном виде выполняется буферизация и синхронизация с частотой развертки, следовательно вертикальная линия маркера окажется непрерывной на всем протяжении.
Посмотрим на маркеры поближе.
При съемке фотоаппарат открывает и закрывает шторки, на что тратится некоторое время. В результате начало и окончание процесса сопровождается относительно плавным повышением и снижением яркости маркеров. На снимке хорошо заметно, что самый левый маркер является первым – его яркость повышается с низкого значения до нормального. Далее следует три нормальных маркера и их завершает последний, на котором шторки начали закрываться и яркость снижалась. Из этой информации легко вычисляется выдержка и время переключения шторок в фотоаппарате, но кому это надо?
Режим вывода «в окне» означает, что линии всегда выводятся целиком, то есть кадры всегда синхронны развертке, но что будет происходить при скорости вывода ниже 60 к/с? Вообще-то, должно последовать повторение кадра. Сделаем еще один снимок:
Никакого оптического обмана, «зеленые» маркеры ярче других, они показываются на экране дважды. Если не очень заметно, то приведу еще один снимок при тех же условиях:
На данном снимке ярче стали голубые маркеры, сравните с предыдущим случаем. Эффект повышения яркости связан с двукратным показом этого (голубого) маркера. Разберемся подробнее, как это происходит. Вначале формируется кадр с «зеленым» маркером, затем «красным» и «голубым». После этого игра не успевает сформировать кадр на момент появления синхроимпульса и система вывода начинает повторный показ того кадра, что был ей передан ранее, то есть с «голубым» маркером.
В результате это место на экране подсвечивается в два раза дольше, по сравнению с соседними маркерами, и оно фиксируется «ярче». Во время открытых шторок происходит накопление заряда в матрице фотоаппарата, который пропорционален яркости и длительности. К слову, именно поэтому при съемке ярких композиций устанавливается малая длительность, а темных – продолжительная.
Переходим к режиму «полное окно» с отключенной синхронизацией.
Маркеры уже отличаются длиной не во весь экран, что говорит о наличии нескольких кадров в пределах одного изображения. Впрочем, пока это не важно, обратите внимание на ту особенность, что окончание одного маркера всегда означает начало следующего.
Вначале красный переходит в синий, затем белый в зеленый и красный в синий. Так и должно быть, интерфейс на монитор передает изображение построчно, поэтому смена кадра вывода на передней поверхности не может изменить то, что было передано ранее. Для данного случая вначале выводится кадр с красным маркером, затем он был замещен кадром с синим маркером (и так далее) и это замещение четко прослеживается на экране монитора.
Важный момент, настоятельно прошу запомнить – начало следующего маркера обязано совпадать с концом предыдущего. В обязательном порядке, это жестко задано условиями передачи данных на монитор. Единственное «но» – во время обратного хода луча (переход от нижней стороны экрана к верхней) изображение не выводится, поэтому «стыки» между маркерами не видны. Увы, это очевидный недостаток метода и придется «догадываться».
Измерение характеристик и съемка результатов осуществлялась на следующем оборудовании:
Программное обеспечение:
«Говорильни» в первой части было много и это всем надоело, теперь чистая практика.
В качестве объектов исследования можно было использовать массу игр и завалить читателя неподъемным объемом информации, но в этом нет никакого смысла – драйвер видеокарты ведет себя достаточно предсказуемо и результаты весьма четкие. Это не пустые слова, было отсмотрено поведение игр в разных ситуациях, настройках и мере производительности центрального процессора, на что ушла уйма времени.
У примененного метода есть серьезный недостаток – маркеры позволяют быстро оценить характер поведения, но для получения численного результата требуется выполнить слишком много действий, причем автоматизация здесь не поможет. Прошу извинить, детального мегаобзора не будет, да он и не нужен. Основная задача состоит в исследовании поведения системы и выявлении закономерностей, а уж прикладное применение – дело второе. Для чего-то хороша «лупа» – быстро и удобно, но под детальный разбор требуется «микроскоп».
Напоминаю, все сказанное относится к видеокартам AMD Radeon HD 6970 в режиме CrossFireX. Итак, игры.
Borderlands (Direct3D9)
Маркеры специально подобраны по цветовому оттенку – серый (точнее желтоватый) и красный соответствуют четным кадрам, а голубой и зеленый – нечетным. Впрочем, понятия «четный» и «нечетный» чисто условны, программа лишена привязки к какой-то конкретной видеокарте из пары.
Соотношение длительности показа четных и нечетных кадров неодинаково – одни короче других, причем заметно. Это явная «особенность работы CrossFireX» и она хорошо предсказуема. Но чем именно вызвана рассинхронизация видеокарт? Может, высокой частотой кадров? На приведенном фрагменте указано 395 к/с. Возьмем другую сцену,… а лучше ту же самую, но несколько иначе.
Позволил себе вольность интенсивно «покрутить головой», множество перекрещенных линий в центре являются следами от единственного провода на заднем фоне. Тихо продолжаю «восхищаться» картинкой с отключенной синхронизацией. Впрочем, извините, статья не о том.
На приведенной картинке «хорошее» соотношение длин кадров и это при том, что ни место, ни скорость кадров существенно не изменились. Но 400 к/с не показатель, стоит понизить планку.
Скорость уменьшилась до 236 к/с, как и число сегментов на экране (четыре, против восьми на предыдущей картинке), а в остальном изменений нет – все маркеры одинаковой длины. Попробую найти место с более низкой скоростью кадров, 236 все же многовато.
Все то же самое, кадры выводятся нормально. Вывод на экран довольно «размешенный», а как обстоят дела со случаем кратного соотношения скорости кадров и регенерации экрана?
Скорость построения 120 к/с, на экране показываются два кадра, причем весьма стабильно. Привязка к кадровому синхроимпульсу отсутствует вовсе, поэтому смена сегментов отдельных кадров происходит в средней части экрана. К картинке претензий нет и можно уже радоваться? Или стоит вспомнить о первой картинке?
Да нет, дефект на том же месте – длительность показа четных и нечетных кадров различается. Логика прослеживается, но весьма смутно, требуется больше данных. Значит, снимем еще.
В первой строчке собраны снимки с «нормальным» соотношением длительности вывода кадров, во второй – «проблемные». Анализ пока проводить рано.
Borderlands 2 (Direct3D9)
Еще одна игра на DirectX 9, схожая с предыдущей, но есть и отличия – в ней отсутствует «привязка» к двум ядрам и она спокойно масштабируется на большее количество потоков. Это означает, что следует ожидать более плавного построения картинки, что и наблюдается – игра Borderlands 2 идет значительно «мягче» Borderlands. Посмотрим картинки:
|
|
|
|
|
|
|
|
Игра демонстрирует как нормальный режим вывода кадров (первая строка таблицы), так и «с проблемами» (вторая строка).
Что интересно, переход из одного состояния в другое может произойти в любой момент времени без видимых воздействий. Например, в абсолютно «спокойном» месте, два снимка подряд:
Соотношение длительности фрагментов может быть как фиксированным, так и «плавать» между «устойчивыми» состояниями.
S.T.A.L.K.E.R. (Direct3D9/11)
Игра может работать через графические расширения различного уровня, что позволяет оценить возможные зависимости устойчивости изображения к версии графического расширения. Для примера возьмем режимы DirectX 9 и DirectX 11.
От смены номера DirectX видимых отличий не особо много, да и характер изменения кадров практически схожий. Переключение режима вывода DirectX 9/11 процесс долгий, поэтому ограничусь только более новой (и перспективной) редакцией графического интерфейса. Все последующие снимки будут сделаны под DirectX 11.
Заставки программы:
Характер поведения меняется, соотношение длительности может быть нормальным, а может … жутким.
Два снимка подряд:
В одном случае соотношение кадров нормальное, ой, почти нормальное (обратите внимание на длительность красных и белых маркеров на левом снимке). Но это мелочи, с правым все гораздо хуже. Между снимками прошло буквально пару секунд.
Возьмем какую-нибудь сцену и посмотрим подольше, будет ли что меняться в характере картинки. Для примера вполне сойдет место тайника на Кордоне:
|
|
|
|
|
|
|
|
На снимках наблюдается изменение вывода кадров от нормального до полного вытеснения четных или нечетных кадров, что выражается в характерном пропадании сине-зеленых или бело-красных маркеров.
Другие сценки игры:
|
|
|
|
|
|
|
|
Стабильность кадров неплохая. Иначе говоря, дефект расхождения вывода кадров может появляться случайно, его трудно предсказать. Тем более, что без «маркеров» обнаружить неправильную работу графической системы можно лишь по «странному» падению плавности картинки, которое удается отследить только во время движения. Если вы стоите и ничего не происходит, то факт «сваливания» вывода останется незамеченным.
Завершает серию игр «DirectX 9» традиционный участник – тест производительности фирмы Futuremark.
3DMark05 (Direct3D9)
Тест запускался в разрешении 2560х1440, остальные настройки оставлены без изменений.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Почти весь тест прошел с нормальным результатом, лишь несколько сцен в конце прогона вызвали резкое ухудшения стабильности кадров. Последние четыре снимка показывают простые «синтетические» примеры, на которых явно фиксируется дефект формирования кадров. От себя отмечу, что дефект стабильный. Чем «проще» картинка, тем «четче» проявляется сбой.
Переходим к играм DXGI. Ай, простите, DirectX 10-11.
Crysis 3 (Direct3D11)
Почему именно «Crysis 3», существует же масса игр? При установке последних драйверов 13.6-13.8 крутится заставка этой игры.
Что же, это «повод». Если сам производитель проталкивает данную марку, значит с ней-то все должно быть «шоколадно».
Давайте взглянем подробнее, сцен и режимов будет достаточное количество, надеюсь. Места оценки производительности никак специально не подбирались. В начале игры сюжет переключается по некоторым сегментам – пробежал «30 метров», другой сюжет.
Механизм выбора прост - я выбирал подходящее место, где сразу не убивают, и делал снимки. Сама игра позволяет менять уровень качества прорисовки, что вызывает изменение скорости вывода кадров, и этим не грех воспользоваться – картинки будут представляться для трех режимов: низкого качества, среднего и высокого.
И еще несколько уровней:
|
|
|
|
|
|
Игра демонстрирует все то же, что отмечалось ранее – стабильность вывода кадров может нарушаться, хотя до полного вытеснения «нечетных» кадров дело не доходит.
Но это был «Crysis 3», что мешает посмотреть более раннюю реализацию? Ничего, благо используется то же графическое расширение DirectX 11.
Crysis 2 (Direct3D11)
Игра схожа по сюжету и наполнению с ранее представленной «Crysis 3», но требования к производительности графической системы несколько ниже. Сама игра вышла при спонсорстве:
М-да … впрочем, так даже интереснее, тестирование выполняется на видеокартах AMD.
С первых же кадров игра демонстрирует откровенное «спаривание» вывода, выводятся только четные кадры. Для «Crysis 3» я предоставлял три режима качества картинок, но в данной игре переключение между «низким» и «средним» качеством формирования графики мало влияет на скоростные характеристики, поэтому в таблице будет только два столбца – низкое и высокое качество.
Что же, начнем:
Игра очень легко «сваливается» в состояние полного вытеснения нечетных кадров. Для «Crysis 3» дело не доходило до полного провала, чаще происходило лишь изменение пропорций вывода четных и нечетных кадров, а в данной игре наблюдается весь «диапазон», от нормального до полного игнорирования нечетных кадров. Вот характерный случай:
Почему «Crysis 3» более стабилен, чем «Crysis 2», понять сложно, но общие тенденции все же прослеживаются – игра «Crysis 2» менее «насыщенная» с повышенной скоростью формирования кадров и, уж извините, более простой картинкой.
Все это наталкивает на мысль, что появление дефекта выталкивания нечетных кадров как-то связано с соотношением загрузки процессора и видеокарты. Чем «проще» картинка, тем больше шансов получить дефект.
FarCry3 Blood Dragon (Direct3D9/11)
Игра из разряда «поиграл и забыл», хотя некоторые моменты доставляют истинное удовольствие. Ее можно было смело «пропустить», но у нее есть одна редкая особенность – способность работать как через DirectX 9, так и через DirectX 11. Другим распространенным представителем является «S.T.A.L.K.E.R.», но о нем речь уже была. Сравним результаты.
В DirectX 9 произошло полное выталкивание нечетных кадров, в редакции DirectX 11 дефект не столь категоричен. Если бы перед этим я не видел данных по игре «Crysis 2», то мог бы сделать вполне логичный, хотя и неправильный, вывод о лучшей работоспособности DirectX 11.
Однако «Crysis 2» показывает, что не в версии DirectX счастье, любые его редакции могут вызывать неравномерный вывод кадров. Просто в DirectX 11 это происходит реже.
Еще несколько снимков из игры:
|
|
|
|
|
|
|
|
Картинка аналогична предыдущим играм DirectX 11 – не одинаковое время показа четных и нечетных кадров, каких-либо специфических особенностей не прослеживается.
Для проведения работ требуется производить измерения, но по «играм» это выполнить весьма затруднительно – объекты изменяются, «боты» норовят подстрелить, да и сам игрок может совершать движения в неподвижном состоянии. Нужен какой-то абстрактный тест производительности без произвольно изменяющихся параметров.
Первая мысль была о каком-нибудь 3DMark, но в нем затруднительно остановиться, да и процесс переключения между графическими устройствами DirectX 9/11 вызывает очевидные сложности. Поэтому выбор пал на Unigine Heaven Benchmark 4.0. Тест производительности устраивает почти всем, разве что в нем отсутствует поддержка DirectX 10, но … «не больно то и хотелось». В современных играх вряд ли кто будет использовать Dx10, если существует Dx11, официально поддерживаемый операционной системой Windows 7, и выше.
Программа Heaven 4.0 позволяет останавливать картинку и легко менять ее качество, что позволяет получить больше полезной информации. Как и ранее, я выбрал несколько точек и представлю разделение на три уровня качества – низкое, среднее и высокое. Рабочее разрешение то же, что и для игровых приложений – 2560х1440.
DirectX 9:
Практически на всех сценах и уровнях сложности наблюдается одинаковая картина – нечетные кадры практически отсутствуют. Съемка отражает статическое изображение, но это состояние может иначе проявляться в динамике. Для контроля можно попробовать снять «фильм», но следует сразу оговориться, что это действие будет сопровождаться рядом недостатков:
Иначе говоря, запись «фильма» сопряжена с массой недостатков, но она позволит оценить устойчивость вывода в процессе прохождения теста, хотя бы «на взгляд».
Вы можете посмотреть небольшие отрывки для среднего (5.14 Мбайт) и высокого (4.80 Мбайт) качества. Объем файлов около 5 Мб каждый, время 1 минута 50 сек. Для просмотра лучше использовать плеер с возможностью покадрового просмотра. Если таковой отсутствует, рекомендую воспользоваться Media Player Classic.
Полученное качество картинки не позволяет проводить ее последующий анализ, но некоторые закономерности прослеживаются достаточно четко – маркеры постоянно «окрашены» или в желто-красную или в сине-зеленую гамму. Вкрапления других цветов встречается «не часто». Что же, фильм подтверждает сделанные снимки – видеокарта часто выводит только половину кадров, что означает «обман» пользователя почти в два раза. Очень мило, спасибо.
А вообще, складывается довольно комичная ситуация. Переход на «сдвоенное» решение повышает производительность в 1.5-1.7 раза, но последующий фазовый сдвиг уменьшает это значение в два раза. В результате - в два раза больше затрат на аппаратуру, проблемы с стабильностью картинки и итоговая производительность ниже, чем одиночная видеокарта. К слову, у одиночного решения и задержка меньше.
Переходим к DirectX 11.
Ситуация очень напоминает «Crysis 3» - повышенная дефектность вывода кадров присутствует, хоть и не в столь категоричной форме.
Позвольте представить для контроля пару видеофрагментов, для среднего (5.19 Мбайт) и высокого (5.00 Мбайт) качества картинки. Характер поведения соответствует снятым картинкам – почти всегда длительность четного и нечетного кадра не одинакова и это отличие весьма существенно.
Думаю, пищи для размышлений достаточно, переходим к анализу.
Приведенные ранее картинки показывают, что довольно часто, а в некоторых играх и «всегда», вывод четных и нечетных кадров на CrossFireX выполняется не одинаковой продолжительности. Т.е. выполняется показ длительного и короткого фрагмента парами.
Для анализа качества того, что видим на экране, следует «привести» абстрактные данные с счетчика «FPS» в то, что действительно видно на экране. Зачем это надо? Давайте применим обычную элементарную логику. Что же происходит в том случае, когда видеокарта пропускает нечетные кадры? Я приводил массу примеров такой ситуации, например:
На снимке присутствуют синие и зеленые маркеры, чего нельзя сказать о желтых и красных. Если говорить формально, на экран то они выводятся, вот только видны всего лишь 1-3 строки, что весьма трудно заметить глазом, даже если специально присматриваться и точно знать место. Фактически, их нет. На данной картинке показан счетчик производительности, который показывает «124 к/с». Это значение получено подсчетом количества всех кадров, которые были выведены за последнюю секунду. Но, простите, половины из них мы никогда не увидим!
С точки зрения элементарной логики, полученное число требуется поделить на два. Противоречий и сомнений нет? У меня нет, извините. Если «показано» в два раза меньше кадров, чем «выведено», то истинным числом будет результат после деления на два – меня мало волнуют «кукурузные» FPS. Важно лишь то, что «видно», а «личные проблемы» видеокарты – это ее личное дело.
С одним определились и, надеюсь, окончательно – если видеокарта не показывает половину кадров, то «реальный» счетчик кадров СЛЕДУЕТ разделить на два. Возьмем прямо противоположный случай, длительность вывода кадров полностью одинакова, что происходит при нормальном формировании изображения. В этом случае «видимая» и «насчитанная» скорость вывода кадров совпадает. Эти рассуждения позволяют определить два крайних значения – по мере ухудшения стабильности вывода кадров «видимая» скорость кадров может меняться от 1/1 до 1/2 к данным счетчика производительности.
Остается лишь определить вид кривой пересчета между процентным соотношением длительности показа кадров к «эквивалентному» равномерному потоку кадров. Как модель пересчета можно использовать среднее значение скорости и меру нестабильности каждого кадра.
При сложении «среднего значения» с «нестабильностью каждого кадра» получится эквивалентное (простите, «реальное») значение скорости кадров. Именно то, что и происходит на экране. Проверим граничные состояния:
Состояние полного выбивания каждого второго кадра «свойственно» DirectX 9, а в DirectX 11 это скорее редкость, чаще встречается небольшое расхождение. Например, возьмем длительности кадров как «3» к «4», что обеспечит среднее значение в 3.5 кадра и нестабильность 0.5 кадра. В результате эквивалентная длительность кадров составит 3.5 + 0.5 = 4. Разница между «эффективной» и «насчитанной по сигналу окончания рисования» будет 0.5 единицы, или 14%.
Нарушение равномерности небольшое, но это уже привело к снижению производительности графической системы на 14% по отношению к демонстрируемым значениям счетчиков. Восприятие картинки основано на «интегрирующем» (усредняющем) восприятии изображения на экране, поэтому длительность фрагментов и продолжительность показа следует оценивать по вероятностному принципу, что приводит к «линейной» зависимости длительности кадра к его условному весовому коэффициенту.
Иначе говоря, нестабильность должна линейно пересчитываться в эффективную скорость кадров, что описано выше. Какой либо иной вид пересчета, «квадратичный», «логарифмический» или «пороговый», окажется неверным. Впрочем, пусть этим занимается тот, кто будет изготавливать программу вычисления
Давайте сделаем модель «неравномерного» варианта и посмотрим на результат. Положим, что видеокарта выводит кадры с соотношением длительности показа кадров как «3» к «4». Продолжительность периода кадрового синхроимпульса понимается как «3». В качестве варианта для сравнения возьмем случай вывода одинаковых кадров, но с длительностью несколько больше «трех», что обеспечит вывод кадров с частотой ниже скорости развертки монитора.
Если не придираться к мелочам, то можно было бы сказать, что в обоих случаях строится картинка одинаково качества. Попеременный вывод кадров длительности «3» и «4» эквивалентен выводу одинаковых кадров «3.5». На данном примере хорошо видно, что на семь выведенных кадров на экране монитора приходится один «пропуск». Для случая неравномерного вывода «пропуск» следует:
В случае равномерного вывода кадров с длительностью, несколько большей длительности периода кадрового вывода на монитор (второй пример):
Неравномерный вывод похож на равномерный с такой же длительностью, но есть и различие – протяженность по вертикали «повтора» между кадрами, и этот «пустячок» является краеугольным камнем. Зона наложения экрана при пропуске определяет величину и характер повреждения картинки на экране. Замена неравномерных кадров «3» и «4» на равномерные «3.5» означает 'банальное' усреднение (3+4)/2=3.5 , а его 'полезность' оценена этой статьей.
Поэтому к двум вариантам представления добавлен третий - при формировании картинки равномерными кадрами, но более осмысленной длины. Как результат, итоговое значение «средней скорости кадров» снизилось с «6/7» до «3/4». Все верно, неравномерные кадры снижают реальную производительность.
Возьмем более «агрессивный» случай, «1» к «3» и соответствующие эквивалентные варианты с равномерным выводом кадров:
Для равномерного вывода кадров все просто и логично – каждая часть экрана выводится с пропуском одного кадра из четырех, что означает результирующую скорость вывода кадров как 3/4 от частоты кадровой развертки монитора. При неравномерном выводе тоже выводится «3/4», но лишь как «средняя» величина. В данном примере верхняя часть экрана будет обновляться в два раза реже, чем нижняя. Это означает очевидно ‘неодинаковую’ эквивалентную скорость вывода в различные части экрана, причем разница весьма чувствительная – в два раза и это уже серьезно.
Если не оценили нюанс, возьмем обычный случай – игра обеспечивает 45 FPS по счетчику. А что, очень даже неплохая цифра, вполне «играбельно». Положим, игра видеокарта создает кадры с соотношением «1» к «3», что является очень даже типичным случаем, смотрите данные по играм, представленные выше. В результате вы будете наблюдать на одной половине экрана 30 FPS, а на другой 60. Если к «60» претензий нет, то «30» сразу вызовет ступор. Счетчики производительности «обещали» 45, а в действительности есть только 30….. Ой. Откорректированная модель (третий вариант) представляет результат «2/3», что более соответствует действительности.
Если длительности/частота окажутся не кратны частоте развертки, то принцип разделения на 1/2 и 1/1 не изменится, эти «зоны» лишь начнут перемещаться по экрану и чем дальше окажется уход частоты от кратности к развертке, тем больше «размазывается» (усредняется) этот дефект.
Из общих рассуждений можно сделать два вывода:
Иначе говоря, «неравномерный» вывод кадров надо пересчитывать в эквивалентный «равномерный», иначе представляемые данные окажутся лишенными всякого смысла. Формула пересчета должна учитывать неравномерность длительности самих кадров и, по мере возможностей, их меру синхронности к частоте развертки монитора.
Небольшая поправка – под длительностью вывода кадров следует понимать то время, которое они отображаются на экране монитора, а вовсе не то, что показывают логи FRAPS. Милый пустячок
У некоторых программ есть возможность подсчитывать скорость кадров и формировать лог «Frametimes» в виде списка времени получения сигнала окончания рисования. Способ полезный, он дает возможность получить больше ценной информации об игровом процессе и оценить производительность компьютера. Но такое впечатление создается только при поверхностном взгляде, в действительности все сильно запущено. Дабы не рассуждать об абстрактных понятиях, возьмем широко известную программу FRAPS и сразу засунем нос туда, куда не просят – в ее внутренности.
Для измерения производительности программа FRAPS перехватывает выполнение команды «Present», выдаваемую в конце каждого кадра как сигнал о конце «рисования» процессором и передаче «сырого» кадра для дальнейшей обработки графическим процессором видеокарты. При этом программа может выполнять графический вывод на экран или «захват» содержимого для выполнения снимка или записи видеофрагмента. Все эти действия удобно производить до выдачи признака об окончании рисовании, т.е. до прохождении «Present» из игровой программы в DirectX. Собственно, «там же» и находится место снятия времени получения кадра. Мне сложно объяснить побудительные мотивы размещения измерения в этом месте, но так сделано.
Альтернативный вариант? Можно взять время на момент выхода из обработчика DirectX. Различие в том, что время «входа» не представляет ничего ценного. Игра формирует кадр, на что тратится какое-то время, после чего индицирует об окончании рисования и по этому признаку снимается время «чего?». Да ничего осмысленного. Сформированные данные о кадре еще будут обрабатываться в видеокарте и лишь затем полностью готовый кадр отобразится на «Front buffer».
Ну хорошо, а чем же лучше «выход» из обработчика «Present»? Давайте немного помедитируем над работой с кадрами. Процессор должен сформировать описание кадра, которое «складывается» в блоки, в одном блоке описание одного кадра. Внутренне представление в драйвере (и видеокарте) может различаться, но суть всегда остается одинаковой – существуют блоки описания каждого кадра и количество таких «ячеек» ограничено. У фирмы NVIDIA используется понятие «Pre-Rendered Limit», AMD - … ничего не использует, эта настройка сгинула из панели управления.
Неважно, в любом случае драйвер готов принять не более некоторого числа кадров на обработку. Если центральный процессор способен формировать кадры быстрее, чем способна обработать видеокарта, а это выполняется почти всегда, то вся очередь «заготовков» кадров оказывается забита и поступление нового кадра возможно только в случае освобождения одной из ячеек очереди – пока не обработается (и скопируется на экран) какой-то кадр. Во время обработки команды «Present» DirectX выполняет некоторые действия по окончанию работ с данным кадром, после чего возвращает управление и игра может начинать строить новый кадр.
Одно «но» - ‘во что’ строить? Если DirectX не позаботится о наличии хотя бы одного блока для формирования нового кадра, то наступит полный крах – данные «перельются через край». Дабы избежать такого сценария, DirectX (скорее «драйвер») задерживает возврат из функции до тех пор, пока не освободится блок. Современные компьютеры достаточно производительны и очередь заданий по кадрам всегда оказывается полной. Как итог, «вход» в обработчик «Present» и «выход» из него – это две большие разницы.
Первое ничего осмысленного не представляет, зато второе сообщает о факте вывода кадра на экран. Ну сами посудите, в какой момент может освободиться блок в очереди? Именно тогда, когда в его содержимом уже нет нужды – кадр сформирован и «выдан». Вот это событие уже интересно, оно «как-то» коррелирует с тем, что изображено на экране монитора. Зная момент вывода кадра и номера текущей строки вывода (что легко получается из ScanLine) не составляет труда отследить положение и размер сегмента вывода на экран монитора. Здесь есть одна тонкость, но о ней чуть позже – не стоит смешивать разные проблемы.
Довольно любопытно, что «вход» в процедуру хоть и мало что значит, но представляет практически то же, что и «выход» из нее. Причина кроется в цикличности процесса рисования и мало меняющихся затратах времени процессора на формирование кадра. После «выхода» проходит почти постоянный интервал (время процессора), затем следует «вход» в обработчик «Present» и этот момент фиксируется FRAPS. Если «время процессора» не имеет резких изменений по длительности, то «выход» и «вход» будут показывать практически одно и то же, просто немного сдвинуты во времени один относительно другого.
Ну а если программа не старается выдержать «время процессора» постоянным? Тогда примерное равенство окажется нарушенным и логи будут содержать большую величину «шума», чем есть в действительности. Впрочем, стоит сразу вернуться к «действительности» - момент оценки времени кадра по «выходу» из обработчика не гарантирует полной тождественности освобождения блока очереди. Дело в том, что ‘какой-то’ кадр может быть закончен во время формирования последнего кадра. Тогда драйвер не будет ждать освобождения очереди, ведь одна из ячеек уже освободилась.
Т.е. если между «входом» и «выходом» затрачивается время на ожидание, то это означает, что именно в этот момент произошел вывод на экран. Если дополнительных потерь времени не последовало, то событие «выход» никакой полезной информации уже не несет – кадр был выведен за время формирования этого кадра. Чем выше скорость кадров, тем менее точную информацию можно получить.
Позвольте сделать пару выводов, они нам пригодятся:
Я долго не мог понять, почему 20-50 к/с легко и довольно точно пересчитываются из логов FRAPS в изображение на экране монитора, а с 200-300 к/с начинается морока - результат в 1.3-1.5 лучше того, что происходит в действительности. Оказывается все просто, сигнал «Present» лишь условно синхронизирован с выводимой картинкой. Можно или выполнить несложный пересчет или игнорировать, ценность в корректном измерении скоростей выше 150 к/с весьма призрачна.
Кроме потока отсчетов о времени кадров хорошо бы получить хоть какую-нибудь осмысленную информацию от драйвера. Увы, ничего ценного выудить не удалось. Единственно, что декларировано в описании DirectX – оценка отброшенных кадров, но эти данные особого интереса не представляют. Отслеживание статистики по кадрам оказалось первым, что было реализовано и результат наблюдений – «пустышка». Если не переключать «на ходу» разрешение экрана, то максимальное количество «droop frames» никогда не превышало «2». При этом практически всегда в логах фигурирует число «0» и заметить что-либо отличное от нуля я смог лишь добавив в программу поиск максимума.
Драйвер не отбрасывает кадры, по крайней мере ATI/AMD. Если я правильно разбираюсь в хлебных крошках, то FRAPS не смотрит статистику по отброшенным кадрам, но это и не нужно, коль скоро их практически не бывает. Это значит, что данные FRAPS (все равно) соответствуют действительным. Вот только во всем этом действие мало смысла, коль скоро не учитывается соотношение длительности выводимых кадров на мониторе.
Теоретически, собственная программа может собирать больше информации, чем представляют логи FRAPS, но, в данном случае, есть сопутствующая беда – на добавление нормального вывода в программе требуется написать этот самый «нормальный вывод», на что уйдет много времени, а результат желательно получить «сейчас». Кроме того, мне действительно стало интересно, возможно ли вообще из лога FRAPS вытянуть хоть что-нибудь разумное. Для «издевательств» есть Fraps-Calc и реальный вывод на монитор, через «маркеры», можно попробовать найти разумные закономерности. Под «разумные» я понимаю логически правильные выводы, а не подгонку результатов
Затратив некоторые усилия я подобрал нечто, отдаленно напоминающее правильный результат, хотя иногда наблюдалось не слишком удачное соответствие с происходящем на экране. Например, при высокой скорости кадров и практически полном отсутствии нечетных кадров программа сообщала лишь о 50-70 процентном снижении производительности, хотя должно быть почти 100%.
Причина описана выше и она может быть скорректирована. Существовали и серьезные «проколы», когда программа сообщала о высоком качестве вывода, хотя на экране отсутствовала половина кадров. Но это отмечалось лишь пару раз, причем на скорости порядка 500 к/с. Увы, недостаток метода. Повторюсь - частично он может быть скомпенсирован, ведь средняя ошибка предсказания вывода на экран по сигналу «Present» пропорционально скорости кадров. После коррекции вполне возможно обеспечить точность 5-15% для скоростей кадров 30-120 к/с, причем эта погрешность будет затрагивать только прибавку к средней частоте кадров, которая считается достаточно точно.
В результате, ошибка вычисления «эквивалентной» скорости будет не столь уж и большой. Кроме описанных проблем, отмечались отдельные приложения, формирующие весьма специфический поток кадров, которые вносят повышенную меру несоответствия между логом и действием на экране. Подобное я наблюдал лишь в «откровенной синтетике», реальные игры более предсказуемы. Впрочем, все сказанное лишь мое скромное мнение и самое время добавить «IMHO».
В качестве тестовой программы используется Heaven 4.0 и его зависимости формирования кадров отследить совсем не трудно.
Heaven (DirectX 9)
На диаграмме кадров добавлены два графика:
Кроме того, в разделе «Resume» добавилась (предполагаемая) усредненная частота кадров, видимая на экране монитора. Понятно, что все это чистый воды «шаманство», но оно используется для конкретного приложения, по отдельным точкам эти показания проверены и скоростной диапазон укладывается в «нормальные» рамки 30-120 к/с.
DitectX 11:
Сравним данные двух реализаций.
| DirectX | Средняя скорость кадров, к/с |
Стабильность соседних отсчетов, % |
Скорость кадров по Vsync, к/с |
На мониторе, к/с |
| 9 | 90.9 | 37.6 | 54.8 | 54.5 |
| 11 | 91.6 | 52.6 | 57 | 62.7 |
Все цифры рапортуют о лучшей картинке в DirectX 11. О том же говоря и фотографии, снятые ранее. Это все, финал, больше ничего сделать нельзя и следует мириться с «данным»?
Давайте попробуем «что-нибудь» сделать. Первое, что приходит на ум – включить вертикальную синхронизацию. При этом видеокарта сможет полноценно буферизировать вывод, что должно сгладить неодинаковость соседних кадров. Да и факт привязки к кадровому синхроимпульсу избавит изображение от разрыва объектов. В качестве испытательного объекта я возьму тест производительности игры Hard Reset.
Игра сделана с использованием DirectX 9 и, по отзывам, очень не дружественна к CrossFireX и SLI. Запускаться тест будет на сборке из двух видеокарт AMD Radeon HD 6970 и то, что игра «что-то не любит» нам только на руку. Цель – получить как можно более плавную картинку на экране монитора.
Обычный режим, вертикальная синхронизация отключена:
Поведение «красной» линии вызывает тоску. Средняя частота кадров 46.1, из них на мониторе окажется лишь 32.2, скучно.
Включим синхронизацию:
Что любопытно, средняя скорость кадров практически не изменилась, но ряд характеристик стал хуже. Можно ли сделать что-то еще? Панель управления Catalyst ничего путного не предоставляет, но есть замечательная программа RadeonPro, которая способна исправить это недоразумение. Воспользуемся дополнительными режимами управления синхронизации.
Динамическая синхронизация.
Действие основано на активном управлении режима синхронизации с кадровой разверткой монитора. Если игра обеспечивает скорость формирования кадров выше частоты развертки монитора, то вертикальная синхронизация включается. Если не сможет обеспечить, то синхронизация отключается.
Двойной Vsync.
В описании к программе информация представлена весьма запутано. Можно воспользоваться переводом Google, но помощь в этом весьма спорна.
Технология двойного Vsync как-то связана с удвоением количества синхронизирующих сигналов, что позволяет выполнять подстройку не только на частоте кадровой развертки, но и на частоте в два раза ниже ее. Программа RadeonPro может не только управлять режимом синхронизации, но и ограничивать минимальную длительность между сигналами конца рисования. Давайте воспользуется этим сервисом и дополнительно поставим предел на 60 и 120 к/с.
Двойной Vsync с ограничением скорости кадров на уровне 60 к/с.
Двойной Vsync с ограничением скорости кадров на уровне 120 к/с.
Теперь вроде все, можно составить таблицу с результатами.
| Вертикальная синхронизация: |
Средняя скорость кадров, к/с |
Стабильность соседних отсчетов, % |
Скорость кадров по Vsync, к/с |
На мониторе, к/с |
| Отключена | 46.1 | 13.7 | 40.4 | 32.2 |
| Включена | 41.4 | 33.9 | 41 | 26.9 |
| Управляемая | 46.6 | 50.7 | 45.2 | 36.2 |
| Двойной Vsync, ограничение 60 к/с | 57.3 | 96.1 | 57.2 | 55.3 |
| Двойной Vsync, ограничение 120 к/с | 57.3 | 89.5 | 56.5 | 49.5 |
Проанализируем цифры. Но перед тем должен еще раз подчеркнуть, что столбец «на мониторе» является ориентировочным и его достоверность под большим вопросом.
Синхронизация отключена.
По логике вещей, отключение синхронизации должно обеспечивать наибольшую производительность системы. Но, по полученным данным, она скорее представляет весьма посредственную скорость. Можно забыть о последнем столбце, но «посредственность» затрагивает все столбцы. Причина очевидна – «шум» вывода соседних кадров, свойственный CrossFireX (а возможно и SLI).
Синхронизация включена.
По той же логике, включение синхронизации должно резко снижать производительность, так и происходит – в этом режиме все характеристики хуже. Но, постойте, все ли? Да, средняя скорость кадров оказалась меньше, но скорость кадров по Vsync повысилась. С одной стороны это логично, включение синхронизации ни коем образом не должно повлиять на симулятор синхронизации к Vsync, что и произошло. С другой стороны, включенная синхронизация означает сниженный уровень «шума» от нестабильности кадров из-за CrossFireX, что так же повышает значение в этой позиции.
Управляемая синхронизация.
В этом режиме программа RadeonPro активно управляет состоянием синхронизации, включая и отключая ее при установлении скорости кадров выше или ниже скорости развертки монитора. К сожалению Hard Reset демонстрирует скорость кадров ниже 60 к/с, поэтому синхронизация включается лишь на короткий интервал времени и больших дивидендов предоставить не может. Время работы Vsync хорошо заметно в последней трети графика по резкому снижению «шума» и прохождению линии строго по границе 60 к/с.
Двойной Vsync, ограничение 60 к/с.
Основные проблемы CrossFireX (и SLI?) связаны с нестабильностью соседних кадров, формируемых одновременно первой и второй видеокартой. Сборку CF/SLI можно осуществить не только с двумя, а и с большим количеством видеокарт, но, в виду очевидной редкости таких построений, речь идет только о двойных решениях.
Итак, видеокарты формируют поток кадров, но получаемой производительности не достаточно для полноценной синхронизации к частоте развертки монитора. Не беда, драйвер умеет выполнять синхронизацию на половинной частоте, что позволяет осуществлять синхронизацию частот кадров не только «выше 60», но и в диапазоне 30-60. Ниже 30 технология двойного Vsync работает так же, как и управляемая синхронизация – отключается.
В принципе, отказ от синхронизации при частоте кадров ниже 30 к/с не должен как-то ухудшать качество восприятия картинки, ведь это уже ‘полный провал’. Ну кто будет играть с 25 к/с? … Так что, в явные недостатки это свойство записывать не стоит. Впрочем, пора вернуться к таблице.
Этот режим позволяет добиться самых лучших результатов, причем об этом рапортуют все характеристики. Возросла даже средняя скорость кадров, чего (вроде бы) произойти не должно. Однако позвольте напомнить, игра «Hard Reset» не слишком любезна к многопроцессорным решениям. Вероятно, включение улучшенной синхронизации обеспечило устойчивую и постоянную работу системы генерации кадров в игре. Вполне возможно, что этим и вызвано улучшение скоростных характеристик.
Двойной Vsync, ограничение 120 к/с.
Программа RadeonPro, кроме всего сказанного, может ограничивать скорость кадров. Предположительно, механизм основан на гарантировании фиксированного интервала между сигналами «Present». Установкой ограничения по уровню 120 к/с я указал минимальный интервал между соседними кадрами (со стороны процессора). При общей двойной синхронизации это привело к повышенному «шуму» кадров.
Для предыдущего случая было установлено ограничение в 60 к/с, что соответствовало периоду кадровой развертки и появления «шума» подавлялось. Итак, ‘благое пожелание’ повысить производительность снижением уровня ограничения привело к увеличению нестабильности и, как следствие, скорость снизилась. Чем «шумнее» поток кадров, тем хуже.
Короче говоря, если у вас AMD, то программа RadeonPro вам в помощь.
Не так давно компания AMD выпустила не совсем обычную редакцию драйвера, в котором сделаны некоторые подвижки в сторону улучшения качества выводимой картинки. На данный момент существует лишь бета версия этого драйвера, что явно намекает о его незавершенности. К слову, «глючный» он, но попробовать то стоит.
Ранее я приводил съемку маркеров, нет никаких препятствий привести данные и для этого драйвера. Дабы не раздувать статью, ограничимся лишь Heaven 4.0.
DirectX 11, драйвер из комплекта 13.8 бета:
Теперь самое время привести лог FRAPS.
Весьма любопытная картинка. Складывается такое впечатление, что драйвер ничего не «балансирует», а выполняет тривиальную синхронизацию к сетке частот, кратных кадровой развертке. А что, очень красивое решение! Но у него есть один недостаток, отмеченный ранее - при неодинаковых размерах кадров важно всячески избегать синхронности к частоте развертки, иначе последует резкое возрастание дефектности картинки.
Несколько выше я приводил сравнение кадров «1» к «3» и эквивалентных «3/4». Кадры «1» к «3» разбивают выводимую картинку на два поля, 1/1 и 1/2 (60 Гц и 30 Гц). Для снижения этого неприятного дефекта следует «размешивать» эти два поля, что можно получить старательно избегая синхронности к частоте развертки. Так что, реализация AMD очень красивая, но потенциально «проблемная». По приборам «все хорошо», а вот «на взгляд» …
Драйвер позволяет отключать функцию «Frame Pacing», попробуем без нее:
Знакомая картина. Для полноты сравнения, аналогичный режим для драйвера 13.6beta2:
А знаете, можно попробовать сделать собственный балансир фазы между потоками видеокарт. Простенький делается «на коленке», получилось следующее:
Стабилизация сопровождается некоторым эффектом «качания» и это сделано специально, дабы уменьшить синхронность к частоте развертки (дефекты перемешиваются).
Сравним результаты:
| Режим работы | Средняя скорость кадров,к/с |
Стабильность соседних отсчетов, % |
Скорость кадров по Vsync, к/с |
На мониторе, к/с |
| 13.8b, «Frame Pacing» включен | 93.4 | 86.8 | 59.5 | 81.2 |
| 13.8b, «Frame Pacing» выключен | 94.6 | 39.2 | 57.2 | 61.3 |
| 13.6 beta 2 | 91.6 | 52.6 | 57 | 62.7 |
| 13.8b, собственный балансировщик. | 91.8 | 83.2 | 59.1 | 77.5 |
Самые лучшие результаты у драйвера 13.8b с включенной функцией «Frame Pacing», что вполне ожидаемо. Немного неожиданно, что различается характер работы драйверов 13.b2 и 13.8b с отключенной функцией «Frame Pacing». Похоже, его весьма основательно «перепахали». Что до моей «затычки», то она показала вполне вменяемые результаты, хотя была состряпана за 10 минут
DirectX 9, драйвер 13.6b2:
DirectX 9, драйвер 13.8b:
DirectX 9, различные версии драйвера:
| Версия комплекта драйвера: | Средняя скорость кадров,к/с |
Стабильность соседних отсчетов, % |
Скорость кадров по Vsync, к/с |
На мониторе, к/с |
| 13.6 beta 2 | 90.9 | 37.6 | 54.8 | 54.5 |
| 13.8 beta | 81.2(!) | 31 | 42.6 | 38.9 |
Драйвер из комплекта 13.8b просто ужасен. Он умудрился «провалить» тест даже по средней скорости кадров, которая вообще не учитывает какую-либо нестабильность вывода картинки. Про другие характеристики просто не хочется вспоминать. Вполне очевидно, что редакцию под DirectX 9 разобрать - разобрали, а собрать забыли. ((
В самом начале этого раздела я отмечал о «глючности» драйвера 13.8, настала пора это доказать. В данном тестировании я довольно много ссылался на игру «Crysis 3», но знаете, что я увидел сразу, после перестановки драйвера с 13.6b2? Познакомьтесь, это «Псих»:
Веселенький у него воротничок, не находите? И бронекостюм «Пророка» почему-то оброс кольями. Дефект наблюдался только на «Психе» и только в пределах уровня, потому «стабильным» его назвать нельзя, хотя симптом неприятный. Надеюсь исправят. «Crysis 3» сделан на DirectX11, а вот DirectX 9 – с ним очень плохо. И дело вовсе не в снизившейся производительности, возросла дефектность картинки. При анализе Heaven этот недостаток проявился очень четко. Давайте я соберу характеристики драйверов в общую таблицу, так будет заметнее.
DirectX 9, стабильность кадров (%).
| Стабильность кадров по периоду, мс |
13.6b2 | 13.8b |
| 13 | 37.6 | 31 |
| 26 | 89.8 | 32.8 |
| 65 | 89.5 | 37 |
| 130 | 91 | 37.7 |
| 260 | 93.4 | 80 |
| 650 | 94.8 | 89.1 |
| 1300 | 93 | 83.3 |
Дефекты с периодом 13 мс (80 Гц) глазом не замечаются, 26 мс (40 Гц) могут лишь отмечаться как некоторая «неустойчивость». Что до 65 мс (15 Гц) и 130 мс (7.5 Гц), то они заметны весьма четко. Драйвер 13.6b2 вносит дисбаланс только на соседние кадры, а вот 13.8b распространяет нестабильность на большую длительность кадровой последовательности.
Наверное, вы скажете – «Ну и что, подумаешь цифирь?» При просмотре Heaven много движения и почти всегда происходит смещение всего изображения. На драйвере 13.6b2 ничего необычного не наблюдается, лишь легкое подергивание, а вот 13.8b смотрится безобразно. Уж простите меня за столь не технический термин, но я затрудняюсь дать более корректное определение того, что «переливается» на экране, когда на счетчике показывается 60-100 FPS. При перерисовке движение происходит рывками.
Методика измерений и особенности запуска тестов выходят за рамки данной статьи, но, честно говоря, очень хочется сразу избавиться от вопросов вида «а почему у меня этого нет?». Конфигурация системы не менялась долгое время, последняя пересборка со сменой процессора была осуществлена около полугода назад.
Излишней любознательностью я не страдаю и «а-бы-что» на компьютер не устанавливалось, вирусов не было. Возможно, это ошибочно, но состояние системы можно охарактеризовать как «типичная». После выполнения измерений я занялся несколько неформальной деятельностью с графической системой, в результате Windows «рухнула». После установки Windows «с нуля» были выполнены те же тесты и данные результатов изменились.
Прохождение «Hard Reset» стало еще «дерганее», программа вообще отказалась считать стабильность вывода соседних кадров. Но средняя скорость возросла.
Heaven 4.0, DirectX 9, драйвер 13.6b2:
DirectX 9, драйвер 13.8b:
Драйвер комплекта 13.8b представляет жуткую нестабильность кадров и после переустановки Windows с нуля получаемые результаты стали только хуже. Эта нестабильность содержится в потоке кадров, формируемом игрой, программа Fraps-Calc сама такое придумать не способна. Как следствие, все характеристики снизились, хотя средняя скорость кадров возросла, как и в «Hard Reset». Можете сравнить, графики и анализ представлен в предыдущем разделе статьи.
К сожалению, все тестирование проходило на продукции фирмы AMD, что принципиально неверно. Но, увы, ничего стоящего из аппаратуры NVIDIA у меня просто нет. Единственный доступный адаптер находится на работе, да и то очень древний. Я не собирался использовать его в тестировании, просто снял данные и забыл. Потом разбирал архивы и повторно испытал шок от увиденного.
Первый раз это произошло, когда после запуска программы генерации маркеров увидел, что драйвер внаглую украл половину кадров, это безобразие описано выше. Второй раз – после просмотра данных этой старенькой видеокарты NVIDIA.
В качестве музейного экспоната участвует:
На драйвере:
Видеокарта совсем старая и для каких-либо сравнений производительности совершенно не пригодная. Но не стоит пропускать этот раздел статьи, иначе, зачем бы я стал тратить на него время.
Вначале несколько кадров 3DMark05. Этот тест выбран потому, что он выполнен на DirectX 9, а более новые редакции DirectX не поддерживаются ускорителем.
S.T.A.L.K.E.R.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ничего странного не наблюдаете? Давайте я распишу маркеры нескольких снимков.
Чисто эстетически, эта картинка напоминает «кашу», но таковой она и является. А если соединить окончания-начало фрагментов?
Шторка фотоаппарата начала открываться, в этот момент оканчивался показ кадра с синим маркером (слева), после чего начался показ серого маркера. Окончание синего и начало серого отмечено стрелкой с номером 1, остальные отметки выполнены аналогично. Значительная часть фрагментов выдается правильно, но есть и нарушения.
Переход номер 3, после зеленого должен идти красный, но он пропущен и начался вывод синего. Переход 4 тоже неправильный, после синего должен идти серый, но видеокарта «вернулась» к выдаче пропущенного красного. Последующие переходы 5-8 выполнены нормально, затем переход 10 «назад». Я затрудняюсь оценить численно вредоносность скачков вывода к предыдущим кадрам, но она очевидно выше, чем простой «повтор».
Еще картинка для анализа:
Видеокарта отчаянно путает кадры, постоянно скачет вперед-назад. Один «короткий» кадр (слева) на этом фоне выглядит как мелкая шалость. Последовательность в правой стороне кажется «закольцованной», но это не так. После серого (выводится полный кадр плюс маленький повтор) начинается красный, затем синий (при повторе яркость маркера повышается, учитывайте это), затем верх красного с плавным снижением яркости и шторки фотоаппарата закрылись. Если мой анализ вызывает недоверие, можете посмотреть небольшой видеофрагмент (243 Кбайт).
И еще картинка:
Начало и середина процесса «обычные» для этой видеокарты, а вот окончание – жуть. В это время закрывались шторки фотоаппарата и по постепенному снижению яркости можно точно определить последовательность вывода на экран. После вывода синего начинается зеленый (пропуск кадра!), затем красный, затем серый (возврат на два кадра!!), затем снова вывод кадра с зеленым маркером.
Видеокарта тщательно путает кадры вывода, причем сами кадры сохраняются. Это означает, что в ней одновременно(!) присутствуют данные о нескольких(!) кадрах. Зачем это нужно, глупость же полнейшая! Безумный расход памяти, причем без какой бы то ни было необходимости. Гораздо проще построить кадр, выдать его на теневую поверхность и начать обработку следующего. Зачем надо хранить еще несколько кадров? Причем к системе кэширования это действие отношения не имеет.
У меня есть только одно разумное объяснение – обработка ведется не одним потоком, а несколькими. То есть существует несколько конвейеров, которые обрабатывают каждый свой кадр и они работают параллельно. Подобным разделением можно объяснить странную деятельность видеокарты по перепутыванию кадров – соответствующий конвейер просто не успевает выдать кадр и его обгоняет другой конвейер со следующим кадром. Так и получается вместо 1-2-3 вывод типа 1-3-2.
Остается только понять, сколько конвейеров используется. К слову, чем больше величина разбиения, тем выше задержка исполнения. Видеокарта и счетчики производительности информируют о количестве кадров в секунду, но ничего не говорят о задержке исполнения. Если существует разбиение на отдельные потоки, то производительность останется прежней (скорее даже возрастет), а вот задержка повысится и весьма заметно. Вы играете в игры, «тормознутость» в управлении не беспокоит? А вина может быть в самой видеокарте и, что особо неприятно, к скорости кадров (производительности) это не имеет прямого отношения.
Мера разбиения понятие неизвестное. Судя по приведенным картинкам, она должна быть равна трем (большего не встречалось), вот только «3» несвойственна аппаратным реализациям. На выручку приходит тест 3DMark. Если вы обратили внимание на картинки, приведенные ранее, то заметили (бы) на них странную аномалию. Вначале я подумал, что каким-то образом посадил дефект съемки, но фотоаппарат таким свойством не обладает. Он может испортить снимок, но «таким» способом – никогда. Дабы не присматриваться, позвольте показать интересующий фрагмент крупнее:
Видеокарта постоянно путает соседние кадры, что проявляется столь причудливым образом. Ранее отмечались сбои на три отсчета (кадра), здесь подобное и наблюдается, чаще всего. Но существуют зоны вывода, где сбой распространяется на четыре отсчета. Это означает, что конвейеров четыре. Зависит ли величина разбиения от типа видеокарты остается загадкой, но само значение «4» как раз очень логично.
У меня нет доступа к другим, более новым, видеокартам производства NVIDIA, что затрудняет получение точного ответа на данный вопрос о распределении вычислений в графическом ускорителе. С другой стороны, существуют логи тестирования одиночной(!) видеокарты NVIDIA GeForce GTX 570. Ранее я уже приводил эти данные с некоторыми комментариями, интересующиеся могут почитать первую часть статьи. Впрочем, по нужному нам вопросу там приведено не особо много полезного.
Для сравнения, AMD Radeon HD 6970:
Видеокарта NVIDIA GeForce GTX 570 самопроизвольно меняет характер формирования кадров. На графике видны как «спокойные» зоны, так и «шумные». Интересно, что «амплитуда» шума одинакова для разных участков. Видеокарта одиночная, поэтому никакого фазового сдвига, свойственного парной обработке, возникнуть не должно. Но дефект-то есть и его вполне реалистичное объяснение – «SLI» реализовано в самой видеокарте. Собственно, нечто подобное я и предполагал чуть ранее.
Еще один аргумент в пользу теории «псевдо-SLI» в одиночном графическом ускорителе можно получить, проанализировав снимки игры S.T.A.L.K.E.R.
Мониторинг сообщает о скорости 127 к/с, но посмотрите внимательно на то, что именно происходит на картинке. Точные подсчеты проводить не хочется, поэтому ограничусь обращением вашего внимания на наличие повторов(!), смотрите на «зеленые» и «красные» маркеры в средней и нижней части картинки. О каких еще повторах может идти речь, если средняя скорость 127 к/с? В самом худшем случае CF/SLI на двух видеокартах может «испортить» скорость вывода лишь в два раза. Здесь же следует нарушение больше, чем в два раза. Если «больше», значит разбиение выше, чем два независимых потока.
Сама нестабильность, когда самым причудливым образом смешаны сверхкороткие и чрезмерно длинные кадры – это тоже свидетельство в защиту моего предположения. В первой части статьи я приводил доводы в пользу увеличения дефектности картинки из-за параллельной работы нескольких видеокарт.
Фактически мера увеличения неустойчивости длин кадров пропорциональна количеству видеокарт (потоков обработки). Игра S.T.A.L.K.E.R. создает не особо равномерный поток кадров в видеокарту, процессор вынужден отвлекаться на неграфические расчеты. Но посудите сами, не может же ЦП быть загружен настолько хаотично? Да, небольшая девиация присутствовать будет, но откуда взяться столь резким скачкам?? Если вспомнить о «способности» CF/SLI решений усиливать нестабильность в несколько раз, то все встает на свои места.
К слову, на снимках CrossFireX по игре S.T.A.L.K.E.R. ничего экзотического не наблюдается. Да, есть «спаривание» соседних кадров, но какая-либо «пляска» между соседними кадрами даже в виде намека не просматривается. Хотя это не особо серьезный аргумент, все же между GeForce 9600 GT и Radeon HD 6970 большая разница в «возрасте». Однако аргументы представлены, решать вам
Использованный мною метод маркеров с последующей съемкой позволяет оценить формирование отдельных композиций, но откровенно глупо пытаться использовать его для меняющихся сцен или оценки реальной производительности видеокарты. Для этого надо осуществлять покадровый захват и анализ. Примерно таким образом работает комплекс FCAT, который продвигает фирма NVIDIA. Наверно, описание его работы приводить не стоит, это уже сделано, позволю себе вольность остановиться на двух моментах, фигурирующих в описании комплекса:
Во-первых, в качестве элемента формирования маркеров используется оверлей. Во-вторых, методика расчета с критерием учета кадров по «пороговому» методу.
Оверлей очень удобная вещь, его простейший пример – курсор мышки. При обычном режиме построения картинки, чтобы перенести изображение курсора, требуется стереть его в старом месте, восстановив изображение, которое было под ним, затем нарисовать в новом месте. Действия по постоянному перерисовыванию являются откровенной несуразностью, поэтому используется специально выделенный фрагмент (видео)памяти, где сформировано изображение курсора, а при выводе на экран монитора сама видеокарта подменяет вывод на ‘это’ изображение в нужном месте экрана. При этом не происходит какого-либо изменения в изображении того, над чем пробегает мышка.
Данный прием позволяет избежать постоянного рисования/восстановления. Идея хорошая, вот только теряется гарантия того, что оверлей применится именно в тот момент, когда выводится «его» кадр. Уж простите меня за этот скепсис. Моя программа врисовывает маркеры в картинку перед выдачей сигнала о конце построения кадра, что исключает возможность рассинхронизации. Оверлей может добавляться после обработки графическим процессором, а это самый конец цепочки. Если такая рассинхронизация возможна (если), то этим как раз и объясняется, почему FCAT не видит перестановку кадров, иногда (возможно) возникающую на некоторых видеокартах NVIDIA. Если вы прочитали предыдущий раздел, то понимаете, что я подразумеваю.
По методике расчетов – примененный анализ FCAT не учитывает длительность кадров. Просто говорится, если время показа кадра слишком мало, то не засчитывать. Простите, а если его длина чуть больше этого граничного значения, то его засчитывать за полноценный кадр (фрагмент)? Вообще-то, даже соотношение соседних фрагментов как «3» к «4» приводит к эквивалентному снижению скорости кадров на 14%. Ранее рассматривался пример, поэтому я ссылаюсь именно на эти значения. Посмотрите снимки, приведенные выше, шанс получить в игре неравномерные кадры, даже с небольшой степенью неодинаковости, весьма велик. FCAT это игнорирует и возвращает стопроцентное качество. Впрочем, я могу и ошибаться, лично у меня нет комплекса FCAT.
Хм. Кстати, попробуйте найти в свободном доступе так называемый «свободно распространяемый» комплект программ FCAT. Это уже странно. Впрочем, в недостатки это записывать не стану.
Любая нестабильность вывода кадров приводит к ухудшению качества картинки. Для борьбы с этим злом можно использовать либо какую-нибудь разновидность синхронизации, либо включить соответствующий режим балансировки в настройках панели управления драйвером. Конечно, если такая возможность есть. По продукции NVIDIA мне сказать нечего, увы, а вот ATI/AMD…
А знаете, эту компанию надо бы похвалить – занялись драйвером, решают проблемы, результат есть (что редкость, а потому ценно). Вот только… технология объединения нескольких видеокарт для работы с одним видеопотоком была анонсирована на международной выставке Computex 2005, проходившей в начале июня 2005 года. Сейчас, дайте взглянуть, середина 2013 года. Все это время выпускалась продукция и кто-то ею пользовался…
Извините, благодарить не за что.
