Измерение производительности видеосистемы: теория (страница 4)
реклама
Вариант номер 2 – «еще как влияет!»
Убедив в одном, давайте попробую убедить в прямо противоположном.
После всех стадий обработки и буферизации (кэширования) поток кадров попадает в последний буфер вывода и оттуда выводится на монитор. Пожалуйста, ответьте на простой вопрос – вы играете в игры с включенной синхронизацией? Утвердительно на этот вопрос ответят единицы, да и то, с оговорками. «Вредоносное» свойство жесткой кадровой синхронизации очевидно, к слову, как и тот вред изображению, которого она позволяет избежать. Но при раскладе «сильный провал производительности» против «дефекты изображения» для большинства пользователей выбор очевиден.
Что же происходит во взаимодействии «игра-драйвер-видеокарта» при частоте кадров выше частоты импульсов кадровой развертки? Небольшое время буфер «pre-rendered» может поглощать излишние кадры, но его емкость мала и быстро произойдет насыщение. Все остальные буферы в видеокарте небольшие и не способны выполнить сколь-нибудь существенную функцию буферизации избыточных кадров.
В результате, у цепочки «Direct3D»-....-«выход на монитор» остается только два варианта, или выкидывать кадр, или «насаждать», переустанавливать картинку прямо в буфере вывода. Последнее означает гарантированное повреждение целостности картинки. Например, нечто такое:
реклама
На картинке четко видно наложение двух кадров, примерно по середине. А именно – вначале выводится первый кадр, потом он был вытеснен на другой и вторая половина содержит уже второй кадр. Человеческий глаз не заметит мерцания и прочих дефектов с частотой 30-60 Гц, но появление чего-то нового или искажение линейных форм будет замечено сразу. Впрочем, вопросы эстетики и борьбы с этим недугом выходят за рамки данной статьи, позвольте лишь отметить очевидное – выключение кадровой синхронизации приводит к неприятным дефектам.
Впрочем, выключенная синхронизация может улучшать качество картинки. Отключение Vsync приводит к разрыву изображения, особенно при интенсивном движении. Но бывают ситуации, когда качество изображения становится лучше. Парадокс? Увы. Режим построения основан на покадровом расчете, при этом каждый кадр считается четко и в фокусе. Это хорошо для просмотра, но не слишком подходит для движения. Мозг привык воспринимать движущиеся объекты смазанными, это нормально, вот только в 3D сценах все всегда четко.
Скажете «глупости»? Простой пример – вы сидите в вагоне, который движется в тоннеле. При этом каждый кадр будет показывать мгновенный «снимок экрана» движения. Но что будет пониматься от такого движения? Дерганье, при любом FPS.
Включение кадровой синхронизации ничего не улучшит, ведь источником проблемы является высокая четкость каждого кадра. Здесь помогло бы «размазывание», только это может быть реализовано лишь средствами игры, видеокарта по собственной инициативе не способна исправить данный дефект. Если отключить кадровую синхронизацию и обеспечить заведомо высокую скорость потока кадров, значительно выше частоты кадровой развертки монитора, то на экране наступит «хаос» из налагающихся кадров, что снизит «дискретность» отдельных кадров. Впрочем, я отвлекся, извините.
При приходе избыточного кадра и включенной синхронизации, вызывающий поток останавливается до освобождения буфера. Фактически – до прихода Vsync. Если не происходит задержек в операционной системе, то следует простой цикл: поток игры выдает «Present», который сообщает о сформированности кадра, функция API Direct3D этот вызов принимает и не возвращает управление до тех пор, пока кадр не обработается. Причем не обязательно именно тот, который только что запросили – главное, освободить блок буферизации. После возврата из функции поток делает «свои дела», формирует задание по новому кадру и снова выдает Present... и этот цикл повторяется.
В случае существенной задержки операционной системы при поступлении «Present» API Direct3D не ждет и практически сразу возвращает управление, ведь за время вынужденного простоя одна ячейка буферизации освободилась. Вот так и появляются «шипы» (всплески) потоков программ мониторинга типа FRAPS. Типичный пример:
реклама
В начале графика длительность кадра соответствует интервалу Vsync, после которого следует один очень долгий интервал и один короткий. Скорее всего, повышенная длительность вызвана незапланированными задержками и за это время явно был пропущен Vsync. Таким образом, простейшие анализаторы лога покажут два события: пропущенный кадр и короткий кадр. Но это не соответствует действительности – полезную информацию несет лишь долгий кадр, но он не вызывает пропуска, о котором могут сообщать анализаторы, он лишь говорит, что была задержка обмена. При этом сама видеокарта работала в нормальном режиме и обсчитывала те кадры, которые были положены ранее (по умолчанию, 3 кадра).
И «тем более» понятно наличие «короткого» кадра сразу после «долгого» – в освободившуюся ячейку данные кладутся сразу, не дожидаясь освобождения, ведь она уже свободна. Вполне очевидно, что «дерганность» есть только в логах, в действительности ее нет. До тех пор, пока хватает «силы» системы кэширования в видеокарте, никаких дефектов нет, ускоритель работает без остановок. К слову, примерно так выглядит лог при спонтанной нагрузке операционной системы:
Первая строка показывает общее количество кадров в секунду, остальные позиции – отличие их длительности от номинальной. При незапланированной нагрузке всегда следует пара событий – один короткий и один длинный. Если посмотреть количество кадров на интервал Vsync, то вначале следует «длинный» (то есть пропуск кадра) и короткий плюс нормальный. В результате на второй интервал приходится два кадра. Все правильно, пропуском кадра видеокарта истратила внутренний резерв и на следующем его восполнила.
Для нормальной работы видеокарта должна формировать один кадр на каждый Vsync. Отключение синхронизации это требование отменяет, теперь надо сформировать «не менее одного» кадра на тот же интервал времени. Во всех остальных случаях будет пропуск кадра, что воспринимается пользователем не слишком хорошо. Одна видеокарта может поставлять кадры с интервалом времени «T» (положим), две видеокарты со схожей производительностью (положим еще раз) также могут поставлять кадры с интервалом времени «Т», каждая. Во втором случае, в режиме SLI/CF мы будем получать кадры с интервалом времени «Т/2»?
Как бы не так! При работе парами (SLI/CF) видеокарты могут работать эффективно, но обладать фазовым сдвигом. Ранее было представлено множество картинок – фазовый сдвиг вовсе не постоянный и может меняться произвольным образом. Как следствие, время прихода кадров будет составлять не «Т/2», а находиться в интервале от «Т/2» (удачная фаза, сдвиг 180 градусов) до «Т» (неудачная, обе видеокарты работают «одновременно»). Переход на SLI/CF означает, что будет использоваться дополнительный буфер, который сгладит скачки между соседними кадрами, но только в том случае, если используется кадровая синхронизация. В ином случае это лишь дополнительная задержка.
В моменты нестабильности кадров (то есть сдвига фазы) многопроцессорные решения будут создавать кадры с переменным интервалом времени, что означает два следствия:
- Переменный (случайный) размер фрагментов на экране монитора из-за наложения кадров с отключенной кадровой синхронизацией;
- Переменный интервал самих кадров, что может вызывать пропуск кадра при выводе на монитор.
Одиночная видеокарта обладает теми же недостатками, но у нее результаты расчета поступают четко без расхождения четного-нечетного кадра, в отличии от SLI/CF. Разницу можете оценить сами, приведу два варианта.
Раз:
Два:
Особенно красноречиво выглядит окно потока кадров. В первом случае получаем «эквивалентные» 39 FPS, во втором – 60 и без каких-либо пропусков.
Если с этим разобрались, то можно перейти к еще более запущенному случаю.
реклама
Вариант номер 3 – «ну, влияет».
Что же происходит, если жесткая кадровая синхронизация отключена? Система кэширования остается прежней, меняется лишь принцип работы с выходным буфером. При включенной синхронизации его обновление могло осуществляться только в момент активного состояния Vsync, пока информация не выводится на монитор. Если синхронизация отключена, то этой жесткой привязки нет и обновление может произойти в любой момент времени.
О дефектах изображения я упоминал ранее, сейчас нас больше интересует сам механизм взаимодействия. В работе видеокарты используется кэширование, что вызывает неявную кадровую синхронизацию, но ее эффективность мала. При приходе «лишнего» кадра драйвер может или его игнорировать (не исполнять) или «перезаписывать» текущий. Первое он сделать не имеет права, поэтому сосредоточимся на втором варианте.
Переполнение буфера «pre-rendered» осуществить невозможно, API Direct3D/драйвер просто не позволят вызывающему потоку положить на исполнение кадров больше, чем разрешено. Иначе говоря, скорость выдачи кадров зависит исключительно от того, как быстро видеокарта их обрабатывает. Не особо мудреная мысль, если подумать. Если видеокарта способна обработать больше, чем способен вывести интерфейс на монитор, то возникают «лишние» кадры. Эти кадры перезаписывают только что начавшийся вывод «правильных» кадров.
А именно, за время интервала одного Vsync создаются два (и более) кадров. Вначале, желательно по событию Vsync, в выходной буфер помещается нормальный кадр, потом он перезаписывается другим (а далее третьим-четвертым и так далее), пока не наступит время следующего Vsync. На мониторе это выглядит как сборник полей – верх от одного кадра, середина от другого, низ от третьего (и так далее), в местах соединения может наблюдаться разрыв. Думаю и так понятно, что мера искажений зависит от статичности изображения – если движение отсутствует, то все кадры выглядят одинаково и искажений не будет. Чем больше окажется разность в кадрах, тем выше дефектность.
Ранее приводились модели при включенной синхронизации. Если ее отключить, то получится примерно следующее:
При клике на картинку выше откроется «ускоренная» версия модели, можете оценить качество получаемой картинки с отключенной синхронизацией. Принцип работы модели тот же, что и у приводимых ранее – слева показан блок формирования изображения (строятся три цифры), в середине состояние буфера вывода, справа – информация, передаваемая на монитор. По сравнению с предыдущими моделями, здесь присутствуют два отличия: в два раза увеличена скорость формирования кадра и не используется жесткая привязка времени копирования кадра в выходной буфер.
Когда изображение формирует одиночная видеокарта (с одним графическим процессором) с отключенной кадровой синхронизацией, то ее поведение хорошо предсказуемо – при снижении или завышении скорости кадров над периодом Vsync происходит исчерпание (или насыщение) системы кэширования и выходной поток кадров повторяет временные соотношения поступающих данных на построение (по сигналу Present).
Понятное дело, что эта связь не «жесткая», временные затраты на обработку вносят свои поправки, но как «первое приближение» это работает. То есть логи FRAPS отражают качественное описание картинки. Однако напомню, что кратковременные «возмущения» могут исправляться системой кэширования в видеокарте, а потому здесь стоит говорить только о стационарных, медленно меняющихся процессах.
Переход на многопроцессорную обработку означает получение нескольких потоков кадров со сложной фазовой связью. Например, для типичного решения SLI/CF свойственно использование двух видеокарт, а это означает наличие двух потоков. Повторю иллюстрацию, которую приводил ранее:
На приведенной модели скорость формирования кадров каждой видеокартой одинакова и постоянна во времени, но реальные приложения (игры) такой стабильностью не обладают. Возьмем какую-нибудь игру на продукции фирмы NVIDIA, для разнообразия:
Одиночная видеокарта, но в течение небольшого отрезка времени (пять секунд) отмечаются состояния с различной стабильностью кадров – слева и в центре картинки они уже существенные, справа нестабильность практически исчезла. Виновником появления дефекта может быть сама игра, но кого это интересует? Важно лишь, что видно на экране.
Предположим, что был собран вариант SLI/CF на таких видеокартах и фазовый сдвиг между ними одинаков и неизменен (идеальный вариант). Таким образом, обе видеокарты будут поставлять кадры с длительностью формирования кадров 7-30 мс (30-140 Гц), примерно такой «разброс» кадров на центральной части приведенной картинки. Выходной буфер передатчика на монитор выбирает кадры поочередно из одной и другой видеокарт. Это означает, что разброс значений 7-30 мс одной карты превращается в... знаете, я затрудняюсь написать формулу пересчета, получаются отрицательные числа.
Положим, первая формирует (нечетные) кадры с интервалами 7, 30, 7, 30 мс или время 7, 37, 44, 74. Вторая плата получила схожую последовательность, только со сдвигом 180 градусов: 30, 7, 30, 7 мс или время 30, 37, 67, 74 мс. Фазовый сдвиг между потоками неизвестен, положим наилучший вариант ((30+7)/2 = ~20 мс), что дает временные отсчеты второго потока 50, 57, 87, 94. Коммуникатор на выходе должен выбирать отсчеты из первой и второй плат поочередно, что означает следующее соотношение:
Номер кадра |
|
|
|
|
|
|
|
|
Видеокарта № 1 |
|
|
|
|
|
|
|
|
Видеокарта № 2 |
|
|
|
|
|
|
|
|
В данной последовательности только первый и последний отсчет находится на своем месте, все остальное напоминает кашу. Что с этим делать контроллеру в ведущей плате? У него есть кэширование на один Vsync, поэтому задержать третий отсчет (37 мс) до прихода второго (50 мс) он сможет, но его ресурсы не беспредельны – отсчет №5 (44 мс) придет раньше №2 (50 мс). В этой ситуации контроллер может приостановить конвейер платы №1, если она была «ведущей», но для «подчиненной» выполнить эту процедуру будет много сложнее и потребует явной аппаратной поддержки.
Возможно, это одна из причин, почему NVIDIA не распространила функцию стабилизации потока кадров, реализованную в 6хх серии, на предыдущие поколения? Короче говоря, велик шанс выбрасывания кадра. Да, полноценный сформированный кадр будет выброшен, как бы неприятно это не звучало. При этом программы типа FRAPS отметят его наличие, хотя на монитор он не попадет. Впрочем, если FRAPS этих «мелких дефектов» и не видит (ему они неинтересны), то вовсе не обязательно, что драйвер о них не в курсе и эту информацию получить совсем нетрудно, без какого-то специального аппаратного мониторинга.
Короче говоря, переход на SLI/CF приводит к резкому возрастанию «дефектности» в работе игры, причем это сильно зависит от самой игры. Я приводил ранее картинку «Dirt 2» для NVIDIA, позвольте ее повторить:
Как говорится, «ну вот». Остается только добавить аналогичную картинку в редакции AMD:
Игра – игрой, но драйверы тоже что-то значат. Или аппаратура.
Впрочем, вернемся к нашим баранам. Многопроцессорная обработка увеличивает «дефектность» поступления кадров, уже присутствующую в игре, но интересен и другой момент – размер кадров на выходной картинке. Например, создаются два кадра со скоростью, превышающую кадровую развертку в 2 раза. Это означает наличие на изображении монитора двух кадров одновременно. Понятное дело, что два кадра, один поверх другого, вывести невозможно, картинка на мониторе плоская, хотя и пишут «3D». На экране будет видна часть одного кадра и часть другого. Логично, но есть и особенности:
- Начало и конец фрагментов не обязательно выровнены на начало/конец картинки;
- Ширина фрагмента зависит от того, как скоро начал выдаваться следующий кадр. Зависимость нелинейная, ведь кадр может начать замещаться позже, но выше по положению;
- Один фрагмент может выдаваться в нескольких кадрах, даже если он короткий (в конце предыдущего и начале следующего).
Опять хочется высказаться по недостаткам отключения кадровой синхронизации, но воздержусь.
Переход от одиночной видеокарты к SLI/CF решениям приведет к тому, что размер фрагментов и положение на экране станет очень нестабильным. Если частота кадров высокая, то глаз менее чувствителен к подобным проявлениям нестабильности и особых беспокойств сие не вызовет, если только не происходит нарушение линейности объектов. Разрыв и сдвиг дерева, как и похожие неприятности, будут заметны всегда и очень четко.
Иначе говоря, переход на SLI/CF может дать сильное ухудшение картинки там, где она и так плохая. Если же картинка нормальная, то и вред минимален.
реклама
Страницы материала
Лента материалов раздела
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Комментарии Правила