Производительность графической подсистемы Windows 7

Одной из областей Windows, которая подвергается пристальному вниманию и значительному количеству тестов, является производительность графики, которая крайне важна в CAD-приложениях и играх. Широчайший спектр поддерживаемых устройств и сценариев использования постоянно вносят свой вклад в экосистему, порой имея совершенно разные задачи: от базовых возможностей до высочайшей частоты смены кадров на максимально возможном количестве мониторов. В разработке Windows 7 мы поставили перед собой задачу увеличить производительность при выполнении каждодневных задач, но и другие приложения не были забыты. Собственно, в Windows 7 мы и наши партнеры приложили все усилия, чтобы увеличить производительность: мы внесли соответствующие изменения в код, они – подготовили устройства и драйверы (обратите внимание, что драйверы, работающие в Windows Vista, продолжат работать в Windows 7, при этом мы продолжаем сотрудничать с партнерами над драйверами для Windows 7, многие из которых уже размещены на Windows Update). В этой статье мы рассмотрим спектр инженерных работ, а также методы измерения графической производительности. Мы хотели бы обратить ваше внимание на проделанную в Windows 7 работу, хотя оставляем место для различных форумов, сравнивающих производительность Windows 7 на различных конфигурациях и в различных сценариях. Автором сегодняшней статьи является Амит Читре (Ameet Chitre), программный менеджер команды Desktop Graphics. – Стивен

Если вы отправитесь в путешествие по онлайн-магазинам чтобы приобрести новый компьютер, то заметите, что высокие значения графической и общей производительности являются одними из основных аргументов при покупке и, соответственно, продаже. Увидев подобные характеристики, покупатели ждут от таких систем возможности редактировать фотографии, смотреть видео в высоком разрешении и играть в новейшие игры, а иногда переключаться между этими задачами. Очень немногие заглядывают на различные форумы и сайты, где публикуются результаты графических тестов. Традиционно графическая производительность измерялась и анализировалась по 3D-играм, но необходимо учитывать и сценарии обычной работы, к примеру, при открытии окон или прокрутке в Word или IE. Требования к графической производительности в таких сценариях работы существенно отличаются от требований к производительности в 3D-играх. На самом деле, именно поэтому в Windows Vista Experience Index (WinEI) мы решили разделить эти сценарии:

Рис. 1. Пример окна WEI с выделенными графическими характеристиками.

Графическая производительность, как правило, оценивается через различные тесты, которые можно условно разделить на 2 категории:

· Тестирование сценариев: такие тесты оценивают производительность в конкретных сценариях, например, количество кадров в секунду при полете над поверхностью земли в авиа-симуляторе. Во многих популярных играх есть встроенные тесты, демонстрирующие насколько производительна та или иная графическая карта в типичных сценах игры.

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

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

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

Отзывчивость

Многие сталкивались с проблемой, когда какое-либо приложение или Windows сама по себе переставала отвечать на запросы пользователей. Подобного рода проблемы, которые мы называем проблемами с отзывчивостью, часто вызваны производительностью графики. Увеличение отзывчивости – как в прямом смысле, так и с точки зрения избегания замираний – является ключевым способом увеличения общей производительности. И ее тоже нужно измерять.

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

С помощью этой методики мы проанализировали тысячи трассировок, когда тестеры сталкивались с подвисаниями системы продолжительностью от 100мс до нескольких секунд. Причиной подвисаний могло быть что угодно: от блокировки антивирусом доступа к диску в момент обновления сигнатур до попыток обращения к сети из потока UI. В значительном количестве случаев мы выявили, что одно GDI-приложение ждет другое GDI-приложение, которое столкнулось с подвисанием ввиду чрезмерной активности, связанной с подкачкой. До сего момента эта проблема была одной из самых распространенных причин снижения отзывчивости, которую вряд ли можно было обнаружить без соответствующей методики. На основе наших исследований была начата работа над усовершенствованием архитектуры в двух ключевых областях:

· Параллелизм GDI: увеличить отзывчивость при работе нескольких одновременно запущенных приложениях. Это требует серьезной переработки кода вокруг объектов синхронизации GDI (абб. от Graphics Device Interface) или «блокировок».

· Сокращение общего потребления памяти Windows: сократить потребление памяти в работе Desktop Window Manager (далее DWM), который является одним из основных компонентов, ответственных за визуализацию рабочего стола. Это позволяет снизить общую активность при подкачке, что особенно важно на компьютерах с маленьким объемом памяти и, в частности, устройствах с разделяемой графической памятью.

Параллелизм GDI

Некоторые из трассировок, изученных нами в контексте отзывчивости, натолкнули на мысль о дизайне механизма синхронизации в GDI. Архитектура GDI в Windows Vista предполагает, что лишь у одного приложения в заданный промежуток времени может быть эксклюзивное право на общесистемную блокировку. Сегодня это может показаться странным, но когда это решение принималось, характеристики производительности различных элементов системы делали такое оптимистическое решение вполне разумным.

Рис. 2. Существующая архитектура согласования GDI.

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

Рис. 3. Архитектура согласования GDI в Windows 7.

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

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

В результате этой работы увеличилась производительность визуализации несколькими одновременно выполняющимися GDI-приложениями на многоядерных процессорах. Многоядерные компьютеры от этого только выигрывают, потому что теперь одновременно могут визуализироваться более одного приложения.

После того, как на пути к бета-версии были выполнены работы по распарелливанию GDI, мы увидели существенное сокращение количества проблем, связанных с отзывчивостью и вызванных борьбой приложений за эксклюзивное владение ресурсами. Чтобы убедиться в масштабируемости новой реализации, мы создали тесты по прорисовке 2D-примитивов и замерили скорость визуализации, запустив несколько копий таких тестов. Скорость замерялась путем сложения показателей частоты кадров (FPS) всех запущенных приложений. Ниже приведены результаты на четырехядерной системе.

Рис. 4. Параллелизм и масштабируемость GDI.

Без параллелизма GDI-приложений в Windows 7 скорость визуализации ограничена производительностью одного ядра процессора. Ввиду того, что лишь одно приложение может осуществить захват глобальной блокировки, а другие вынуждены ждать, такой сценарий нисколько не выигрывает от использования многоядерных процессоров. Это показывает, что GDI-приложения в Windows 7 менее зависимы друг от друга. Новые драйверы при этом не требуются – достаточно драйверов для Vista (WDDM 1.0) или более новых.

Настольная графика – потребление памяти

Еще одним фактором, имеющим существенное влияние на отзывчивость системы, является потребление памяти. Увеличение объема памяти (RAM) приводит к увеличению активности, связанной с подкачкой, а это, в свою очередь, приводит к снижению отзывчивости системы. Таким образом, для обеспечения максимальной отзывчивости системы необходимо, чтобы приложения и компоненты ОС использовали системную память по минимуму.

В Windows Vista объем памяти, необходимый для работы с несколькими окнами, линейно зависел от количества открытых окон. Это приводило к значительному потреблению памяти в случае работы с большим количеством окон или в случае использования монитора с высоким разрешением. Ситуация усугублялась, если вы использовали несколько мониторов. По мере изучения различных способов увеличения отзывчивости ОС мы получили отличную возможность сократить потребление памяти менеджером DWM. В Windows Vista каждое окна GDI-приложения занимало две области памяти, в которых содержалась абсолютно идентичная информация – одна в видеопамяти, другая – в системной. DWM отвечает за построение рабочего стола с помощью графической карты. Информация размещается в видеопамяти для быстрого доступа графической карты. Дубликат присутствует в системной памяти потому, что GDI визуализируется главным процессором без помощи ускорителя графической карты. Поскольку CPU осуществляет все задачи по визуализации GDI-приложений, ему требуется быстрый доступ к кэшированной копии памяти.

Рис. 5. Текущее распределение памяти.

Windows 7 хранит всего один экземпляр для каждого окна приложения, полностью избавляясь от копии в системной памяти. Таким образом, для одного отдельно взятого окна GDI-приложения потребление памяти снизилось в два раза.

Рис. 6. Распределение памяти в Windows 7.

Нам также удалось снизить потребление системной памяти путем ускорения основных GDI-операций с помощью графической карты – WDDM-драйверы ускоряют операции, чтобы снизить влияние производительности обратного чтения из видеопамяти. Это было необходимо, поскольку выполнение таких операций силами CPU может оказать негативное влияние на производительность. Для того, чтобы решить, какие именно операции необходимо ускорить, важно понимать схемы использования памяти различными GDI-приложениями. Мы выбрали 100 самых популярных GDI-приложений, чтобы изучить их схемы обращений к памяти, частоту и природу GDI-операций.

Рис. 7. Схемы обращений к памяти и частота GDI -операций для 100 популярных GDI-приложений.

На базе полученной статистики, фрагмент которой можно наблюдать выше, мы помогли партнерам обеспечить поддержку ускорения наиболее часто используемых GDI-операций в драйверах. Системы под управлением Windows 7 с этими обновленными драйверами, обозначаемыми WDDM v1.1, используют преимущества от работы по снижению потребления памяти. Обратите внимание, что драйверы версии WDDM 1.0 корректно работают и полностью поддерживаются в Windows 7. В ходе бета-тестирования вы, пожалуй, могли видеть драйверы версии 1.1 на Windows Update, но они носили статус "Beta".

Рис. 8. Сравнение потребления памяти DWM при использовании WDDM 1.1 и WDDM 1.0.

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

Безусловно, ради этого приходится идти на уступки. Так, к примеру, избавление от дублирования памяти, которое ускорило некоторые операции, в некоторой степени снизило производительность, потому что теперь процессору приходится считывать данные из видеопамяти. Анализ реально существующих приложений показал, что такие операции крайне редки. Тем не менее, определенные микротесты GDI, которые осуществляют эти операции, показывают незначительное падение производительности. Это важно знать, если вы запускаете тесты, повторяющие определенные операции GDI, ведь подобные тесты плохо отражают реальную производительность. Наши исследования показали, что это падение производительности не имеет прямого влияния на работу пользователей, при этом снижение потребления памяти очень благотворно сказывается на общей отзывчивости Windows 7. Все внесенные изменения особенно заметны на компьютерах с небольшим количеством системной памяти и с разделяемой графической памятью.

Производительность в играх

Никакая из статей о графической производительности не может считаться завершенной без разговора об играх, которые до сих пор являются одним из самых обсуждаемых аспектов графической производительности. Существует ряд популярных тестовых пакетов, как 3D Mark, а также встроенные игровые тесты, имитирующие игровые нагрузки без участия пользователя. Все эти пакеты постоянно обсуждаются на игровых сайтах, а в заключении статей выдаются рекомендации пользователям.

При разработке Windows 7 мы активно сотрудничали с партнерами, производящими графические карты, помогая им улучшить игровую производительность WDDM-драйверов с учетом архитектурных изменений Windows 7 и без нарушения совместимости. Наши непрерывные инвестиции в инструменты оценки производительности помогли и им отследить и проанализировать различные проблемы, приводящие к снижению графической производительности, и устранить их в последующих версиях драйверов. Фундаментальные основы WDDM в Windows 7 остались неизменными. Изменились лишь некоторые политики планирования GPU и управления памятью в целях увеличения производительности в некоторых сценариях.

В связи с тем, что подобные тестовые пакеты весьма чувствительны к определенным устройствам, микропрограммам, драйверам, а также из-за их широкого распространения, мы оставим сравнительное тестирование третьим лицам. Как в случае с другими областями Windows 7, мы стремимся обеспечить лучшую производительность в разных направлениях. Мы искренне считаем, что лучше один раз увидеть, чем сто раз услышать. Что касается Windows 7, мы рекомендуем проводить сравнительное тестирование с Windows Vista SP1, приняв во внимание, что драйверы WDDM 1.1 все еще находятся в разработке.

В заключение

Как видите, разрабатывая Windows 7, мы усердно трудились над улучшением архитектуры для обеспечения высокой графической производительности в реальных сценариях. От этого выигрывают пользователи по оба конца спектра графических решений – и бюджетные системы, на которых становится возможным беспрепятственно пользоваться Windows, и высокопроизводительные с многоядерными процессорами, которые смогут более эффективно работать с ресурсоемкими графическими приложениями.

Амит Читре (Ameet Chitre),

программный менеджер команды Desktop Graphics

Comments

• Anonymous
  May 05, 2009
  Добрый день! У меня вопрос по механизму оценки (или рейтингу производительности) именно графической подсистемы. Собственно: у меня видеокарта ATI Radeon HD 2400 XT. После оценки система поставила следующий рейтинг: Графика (Windows Aero) - 3.6 Графика для игр - 5.1 Отсюда вопрос - каким образом получается такая разница? Неужели для видеокарты аеро "тяжелее" чем игры? Как мне кажется, значения рейтинга должны быть одинаковыми или как минимум наоборот, т.е. с перевесом в другую сторону: в играх меньше рейтинг, а для аеро больше. Разве аеро может быть тяжелее современных игр? Спасибо. П.С.: похожая ситуация была и в Висте, только там оценка для игр была чуть меньше. А именно: Графика (Windows Aero) - 3.5 Графика для игр - 3.9

• Anonymous
  December 22, 2009
  Скажите, а почему лечение одних костылей другими называют улучшением? Я про то, что "От борьбы за владение глобальной блокировкой удалось избавиться путем внедрения нескольких более мелких блокировок"? Да, и еще вопрос по самой статье: действительно ли разумно изображение, содержащее только текст (http://blogs.msdn.com/blogfiles/e7ru/WindowsLiveWriter/EngineeringWindows7GraphicsPerformance_11B25/clip_image012_e1cdcdeb-b066-4df1-b986-6875434adec3.jpg) выкладывать в JPG, а то, в котором присутствуют градиенты (http://blogs.msdn.com/blogfiles/e7ru/WindowsLiveWriter/EngineeringWindows7GraphicsPerformance_11B25/clip_image014_e4988a83-1932-4b3e-9efa-c99d6279f82d.gif) -- в GIF?

• Anonymous
  December 22, 2009
  Походу тут ответов ждать не стоит -- предыдущий комментарий "Tuesday, May 05, 2009 11:33 AM by alexlab" так и остался без оного. Эй, ау! :)

• Anonymous
  June 21, 2010
  nesquikm, да похоже) и записей в блог уже оочень давно не было