Секреты Android: инженерные коды и режим разработчика. Разработчик Google развеивает мифы о «полном аппаратном ускорении» в Ice Cream Sandwich

21.05.2019

Введение

Параллельно с выходом Windows 7 несколько месяцев назад производители видеокарт представили много моделей на новых GPU, после чего занялись совершенствованием драйверов для своих продуктов. Как нам кажется, сегодня прошло достаточно времени, чтобы они смогли разобраться с самыми острыми проблемами под свежей операционной системой (которые, честно говоря, были не такими критичными, как в случае появления Vista), а объективные тесты должны показать состояние новой технологии.

Конечно, мы понимаем, что сегодня основное внимание приковано к 3D-технологиям, но мы решили вернуться к компоненту графики, который сегодня воспринимается как должное – 2D-графике. Причём не думайте, что мы просто решили добавить пару тестов к нашему тестовому пакету, подняв проблемы, решённые ещё во времена, когда производительность RAMDAC давала существенную разницу. Но подробнее об этом мы поговорим чуть позже.

Хотя большинство пользователей будут интересоваться скоростью отображения графического интерфейса Windows (по которому Windows 7 получила немало похвал по сравнению с Vista), мы обнаружили, что предполагаемое "графическое обновление" Windows 7 не такое свежее, как кажется. По сравнению с Windows XP (и даже Vista) производители графических процессоров пока не провели полной оптимизации 2D-графики под Windows 7, по крайней мере, как показывают исследования новой реализации вызовов API GDI (Graphics Device Interface). Мы все знаем, что 2D-графика состоит не только из забавной палитры, оптических эффектов переходов и анимированных меню с тенями; разработчикам нужно ускорять отрисовку старых добрых пикселей, линий, кривых, прямоугольников, полигонов и всевозможных графических примитивов, как их часто называют.

Важное предварительное замечание

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

В данном отношении важно понимать, что сегодня может быть весьма сложно продуктивно работать с 2D-графикой под Windows 7. Например, когда мы использовали Radeon HD 5870 и последние драйверы, то с большими сложностями смогли вывести простую векторную графику, простые или сложные дизайны CAD или даже поиграть в 2D-игры с высоким качеством графики. Это не столько критика, сколько попытка определить пределы проблемы, которую мы попытались проанализировать, и понять проблему максимально глубоко.

Теория и практика

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

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

Windows: как всё начиналось

Давайте вернёмся в 1985 год. В этом году Михаил Горбачёв стал секретарём ЦК КПСС, "Амадей/Amadeus" получил "Оскара" за лучший фильм, а Рональд Рейган был выбран на второй срок 40-м президентом США. Мало кто заметил, но именно в 1985 году была выпущена операционная система Microsoft Windows 1.0.


Windows с небольшим количеством окон – даже без взаимного наложения разных областей. Нажмите на картинку для увеличения.

Идея наложить виртуальный графический интерфейс на операционную систему с текстовым режимом вряд ли была такой революционной, причём даже в 1985 году. Фактически, именно такой подход разные компании, включая Microsoft и Digital Research, использовали в то время, чтобы расширить своё присутствие на рынке и сделать технологию ПК более доступной для большей части потенциальных покупателей и пользователей. Идея заключалась в том, чтобы приложения были достаточно дружественны к пользователям, то есть чтобы даже непрофессионалы в сфере ИТ могли работать с ними без предварительного глубокого изучения компьютера. Что интересно, в отличие от даже Windows 1.0, многопользовательская ОС Digital Research GEM поддерживала наложение окон уже в то время.



Только с версии Version 2 система Windows стала соответствовать своему названию. Нажмите на картинку для увеличения.

Если бы в 1987 году не была представлена операционная система Windows 2.0, где уже была поддержка множества накладывающихся друг на друга окон, то вполне возможно, что про Microsoft Windows сегодня никто бы и не знал. Фактически, Windows обязана своим выживанием дольше первых двух лет после первоначального объявления тому, кто имеет и сегодня огромное влияние в Microsoft – а именно Стиву Балмеру (Steve Ballmer). Его рекламу Windows 1.0 сложно забыть и сегодня, поскольку он нескромно выставил цену за Windows 1.0 на впечатляющем уровне $99 (немалая сумма для 1985 года), несмотря на отсутствие поддержки реальных окон. Стив Балмер действительно мог увлечь зрителя – его можно назвать гением маркетинга. Посмотрите сами.

Стив Балмер продаёт Windows.

С выпуска версии 2.0 ОС Windows смогла давать (по крайней мере) эволюционные, пусть не революционные изменения в своих последующих релизах. Фактически, революционное изменение оказалось в проблемах, какие мы бы хотели поднять в Windows 7, наиболее свежем выпуске компании.

Последняя версия оказалась как раз той, которая поднимает глубокие вопросы, заставившие нас обратиться к самому началу Windows. Причины тому простые и наглядные. Благодаря нашему сравнению техники работы с окнами, мы узнали о существовании двух сторон графического интерфейса Windows: графический пользовательский интерфейс или GUI (мы не учитывали настройку со стороны пользователя, а сконцентрировали внимание на базовом рабочем столе и работе с ним), включая работу с окнами, а также простые графические функции , которые используются для создания настольного окружения. Фактически, отображение содержимого окон и работа с ними являются двумя раздельными, пусть и связанными, сферами ОС Windows. Вид и ощущения от работы с интерфейсом Windows продолжили меняться и эволюционировать, но лежащие под ним простые графические 2D-функции оставались удивительно неизменными со временем.

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

Ограничения 2D: одно пространство со многими окнами


Всё, что вам нужно – высота и ширина.

Если вы посмотрите на отображение в любом окне, то вам потребуются только две координаты: X и Y, то есть ширина и высота. Чего не хватает? Какой-либо информации о глубине.

В Windows графика 2D отображается через GDI (Graphics Device Interface). Данный интерфейс поддерживает все языки программирования высокого уровня и содержит все важные графические функции, которые необходимы для рендеринга графических объектов 2D. Более поздние улучшения, такие как GDI+ и Direct2D, не играют особой роли, поскольку GDI был (и остаётся) самым важным инструментом для графического вывода 2D в приложении. Критически важные функции вывода пикселей, линий, кривых, полигонов, прямоугольников, эллипсов и так далее – все они изначально просчитывались на CPU. Благодаря развитию видеокарт, последнее поколение "железа" обеспечивает более быстрые 2D-расчёты и рендеринг. Эта ранняя форма 2D-ускорения остаётся важной даже сегодня, но двумерное ускорение уже не является основной целью. Чтобы получить максимум от графической производительности, нам нужна третья координата.

Изначальный способ 2D-рендеринга, который скрывается под наложением окон на экране дисплея, прост и прямолинеен. Нам нужно знать два параметра: первый – это область на экране внутри каждого окна, которая будет меняться (поэтому её требуется перерисовывать). Второй – это порядок, в котором окна или объекты накладываются друг на друга (будет ли объект виден полностью или частично, либо он будет закрыт другим окном). Данный тип информации требует так называемого 2,5-мерного измерения или использования слоёв графики, когда третья координата принимает значение 0 (скрытая) или 1 (видимая), то есть выступает как своего рода вспомогательное измерение. Именно по этой причине многие эксперты в области Windows много говорят о графике 2,5D.


Величина Z показывает, как накладываются или организовываются окна.

После того, как с порядком или видимостью окон всё будет определено, содержимое видимых окон может выводиться с помощью чистых двумерных графических функций. В любом случае, необходимо не только просчитывать содержимое окон дисплея полностью, но также нужно управлять различными типами информации и контентом окон. Что случится, например, если окно будет перемещено? Когда другое окно содержит область, которая полностью или частично открывается в результате этого действия, то должна быть вызвана системная графическая функция WM_PAINT с точной информацией о том, какую прямоугольную область следует перерисовать. Оптимизированные реализации функции будут реконструировать или перерисовывать эту область. К сожалению, многие реализации вместо этого перерисовывают окно полностью, несмотря на возможность доступа к более точным инструкциям, независимо от того, требуется полностью или частично воспроизвести содержимое окна. Это, в свою очередь, оказывает влияние на графическую производительность. Другой недостаток хорошо известен – он заключается в размывании или дублировании, когда окно начинаешь быстро перетаскивать по всему экрану на системе, где отсутствует аппаратное ускорение 2D.

Но позвольте подвести итог тому, что мы рассмотрели на данный момент. На дисплее есть отдельные окна, чей двумерный контент должен отрисовываться на экране, чтобы его можно было видеть. Эти окна можно двигать как угодно, при этом они могут перекрываться и частично или полностью закрываться другими окнами. Необходимо управлять видимым содержанием всех этих окон, его требуется выводить на экран с минимальной задержкой. Мы также знаем, что сам по себе CPU, пусть даже это будет очень быстрый процессор, может слишком сильно нагрузиться при выполнении подобных сложных задач. Какие есть выходы, кроме того, чтобы переложить эту нагрузку на видеокарту? Что для этого требуется? И почему всё звучит проще в теории, чем реализуется на практике? Всё это мы рассмотрим чуть ниже.

2,5D: мифы аппаратного ускорения 2D

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

В данном разделе мы рассмотрим графическое ускорение 2D, связанное с "родным" рендерингом графики, от GDI до самой видеокарты. Сюда входят простые геометрические объекты, такие как пиксели, линии, кривые, полигоны, прямоугольники и эллипсы с одной стороны, а также их масштабирование, рендеринг или операции сглаживания шрифтов (таких как TrueType или OpenType) с другой стороны.

Давняя поддержка аппаратного ускорения так называемых "2D-примитивов" в видеокартах исчезла, она уже некоторое время отсутствует в продуктах потребительского уровня. Сегодня ускорение двумерных графических функций реализуется как аналог трёхмерного ускорения, но обрабатывается исключительно и полностью программным графическим драйвером, а не встроенным на плату "железом".

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


Отображение текста.


Прямоугольники.


Кривые.

Преобразование функций отрисовки - это только часть двумерного ускорения. Значительное и весьма позитивное ускорение осуществляется современными 3D-видеокартами, которые могут выполнять рендеринг, управление и отображение графической информации 2,5D аппаратными средствами.


Всё выводится немедленно.

Как всё это работает? Как и в случае 3D-графики, просчитываются видимые и скрытые области окон, которые хранятся полностью в виде виртуальных прямоугольных участков, в них выводится в реальном времени содержимое всех активных окон. Поэтому ничего не требуется пересчитывать при перемещении или изменении окна; только те области, которые были скрыты, а сейчас стали видны, необходимо перерисовать вместе со всем, что изменилось со времени последнего обновления. Видеокарта всегда знает размер и расположение виртуальных прямоугольников, известных как окна. Используя буфер глубины (z-буфер) видеокарта отслеживает порядок и приоритет вывода окон или объектов на экране (он также известен как Z-порядок). Поэтому видеокарта может сама определить, какие объекты видимые, то есть что требуется вывести непосредственно на сам экран.

Позвольте подвести краткий итог тому, что всё это означает.

Современное аппаратное ускорение 2D включает как реализацию ключевых функций отрисовки 2D, так и реализацию технологий наложения слоёв 2,5D для окон и пользовательского интерфейса.

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

Windows XP: "старая школа" 2D и пределы WM_PAINT

Вы можете говорить о Windows XP всё, что думаете, но аппаратное ускорение GDI работает безупречно и по сей день, при этом его хватает для большинства типов приложений. Впрочем, чего XP сделать не может, так это переложить технику работы со слоями 2,5D на современные 3D-видеокарты. Как мы уже описывали выше, рендеринг содержимого окон выполняется самими приложениями.



Типичное 2D-приложение, для которого вряд ли будут покупать дорогую видеокарту. Нажмите на картинку для увеличения.

Это ограничение вряд ли обеспокоит тех пользователей, кто концентрирует свои усилия на любом одном окне настольного приложения. Наиболее типичное применение подобной технологии можно видеть в окружениях SDI (single device interface, интерфейс одного устройства). Но всё становится более неудобным, когда на рабочем столе открыты и видны множество окон. Кто будет против того, чтобы воспользоваться улучшенной технологией слоёв, которая поддерживает меню, лучше работает на современном "железе", а также облегчает работу с несколькими окнами на нескольких мониторах? Кому не хотелось бы оставить размывание перемещаемых окон и следы за ними в прошлом, получив более высокую графическую 2D-производительность?



Окна как колода карт: эффект дублирования окон под XP при перетаскивании. Нажмите на картинку для увеличения.

Хотя чистая 2D-производительность в векторных графических программах, таких как Corel Draw или приложений САПР, достаточно высока, поскольку функции GDI в них поддерживаются должным образом, мы упёрлись в ограничения возможностей WM_PAINT. Когда графический интерфейс XP перегружен анимацией, мягкими тенями, прозрачными окнами и другими графическими элементами, он вплотную приближается к пределам 2D-графики.



Когда система находится под тяжёлой нагрузкой, то функция WM_Paint "повисает" или обновляется только время от времени. События перерисовки должны дождаться своей очереди, чтобы быть выполненными. Нажмите на картинку для увеличения.

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

Microsoft быстро заметила, что её графическое решение 2D, которое присутствовало во всех версиях Windows до этого, включая XP, требует замены. Да и растущая доступность всё более быстрых 3D-ускорителей вместе со снижающимися ценами на дискретные GPU явно указывали на то, что времена (и операционные системы) меняются.


Типичный пример 3D-видеокарты в 2005 году: Radeon X1800.

На данный момент важно отметить, что аппаратное ускорение в XP изначально не работало с интегрированным графическим ядром ATI 780G в "родных" разрешениях вообще. В результате окна отрисовывались медленно, что ухудшало даже базовую производительность web-браузера. Последующие обновления драйвера помогли решить эти проблемы. Но даже сегодня графическое ядро 780G не может работать оптимально, что сильно контрастирует с 740G. Но сегодня, когда XP уже остаётся в прошлом, это суждение, возможно, тоже должно разделить подобную судьбу...

Затем на рынок вышла Windows Vista, которая является, возможно, самой противоречивой ОС Microsoft (вместе с Windows ME). В любом случае, независимо от вашей любви или ненависти к Vista, компания уже не могла откладывать некоторые технические совершенствования.

Краткий итог по XP таков.

  • Аппаратное ускорение 2D работало безупречно для команд GDI.
  • Аппаратного ускорения для слоёв 2,5D не было предусмотрено, что приводило к замедлению пользовательского интерфейса.
  • Повторяющаяся перерисовка или изменение содержимого окна отнимала время, а также сказывалась на производительности.

Windows Vista: прогресс и отказ от старого

Когда мы впервые установили Windows Vista, то едва сдерживали себя. Интригующая, сложная и улучшенная, Vista обещала очень немало.



Много света и теней, но без аппаратного ускорения 2D. Нажмите на картинку для увеличения.

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

Аппаратная реализация слоёв 2,5D

Эта технология была впервые реализована в Windows Vista. На её выход потребовалось весьма долгое время, но в 2006 году технология, наконец, появилась. Впрочем, одно небольшое ограничение оставалось: она работала только в том случае, если был активирован интерфейс Aero. Кроме того, для поддержки слоёв 2,5D требовалась видеокарта с поддержкой 3D, причём даже если вы не планировали запускать 3D-приложения или игры. Если вы использовали тему Vista Basic, то приходилось смириться с теми же эффектами размытия и раздвоения при перемещении окон, которые были знакомы пользователям XP, поскольку поддержка слоёв 2,5D автоматически выключалась – даже если в системе была установлена 3D-видеокарта. Обидно.

Переход на поддержку слоёв 2,5D также заставил Microsoft решать несколько проблем. Vista считалась медленной операционной системой, но, по большей части, стабильной. Но что же случилось? Мы уже упоминали, что GDI был ключевым интерфейсом для программирования графики. После введения (к сожалению), очень медленного расширения GDI+ на основе C++, которое так и не обусловило технологического прорыва из-за своей производительности, мы уже не могли отрицать существование своего рода "хаоса интерфейсов". Фактически, было очень и очень непохоже, что GDI, GDI+, DirectDraw и Direct3D могут быть вообще одновременно ускорены аппаратно.

Помимо новой модели драйверов устройств, Windows представила модель DWM для управления устройствами вывода на экран. Общая концепция оказалась не такой простой, она добавила программный уровень (и соответствующее увеличение сложности) между окнами и командами отрисовки с одной стороны, а также между драйверами и устройствами с другой стороны. Прямое взаимодействие было прекращено по причине появления DWM. Пытаясь получить контроль над всем, модель DWM обеспечивала координацию всех отдельных графических интерфейсов. Этот переход оставил в стороне довольно серьёзную графическую особенность, о которой мы уже упоминали – а именно аппаратное ускорение функций отображения GDI. Понять сложно, но так именно и произошло.

Большую часть дополнительной памяти, которую потребляет Vista, обычно относят к технологии SuperFetch. К сожалению, это лишь частично описывает ситуацию в реальности. Отсутствие аппаратного 2D-ускорения привело к тому, что вся тяжесть вызовов GDI по выводу содержимого окон ложится на CPU. Всё это приводит к огромному буферу внутри DWM. Полные отображения окон должны затем передаваться на видеокарту. Но это быстро привело к появлению серьёзного "узкого места", поскольку только одно окно в один момент времени может отсылать команды GDI на DWM. Асинхронные задачи не разрешаются, что приводит к длительной очереди ожидающих запросов на обслуживание. Всё это не только требует существенного процессорного времени на выполнение, но и потребляет немалый объём памяти, поскольку все активные окна находятся внутри буфера DWM. Отдельные окна могут занимать 100 Мбайт, так что вполне понятно, что потребление памяти будет увеличиваться. В самых экстремальных случаях Vista может попросту "зависнуть" – например, когда вредоносная программа будет открывать одно окно за другим в бесконечном цикле. Конечно, такой цикл не может продолжаться бесконечно, поэтому вам придётся выполнить принудительное выключение компьютера, чтобы восстановить контроль над системой.



Удвоение потребления памяти не удваивает наслаждение от работы (источник: Microsoft). Нажмите на картинку для увеличения.

Подведём краткий итог по Vista.

  • Vista впервые использует аппаратное ускорение для модели слоёв 2,5D.
  • С активной технологией Aero медленная перерисовка окон Windows остаётся в прошлом.
  • Microsoft отказывается от аппаратного ускорения функций 2D-отрисовки GDI.
  • DWM не может работать с окнами в асинхронном режиме, что негативно сказывается на графической производительности.
  • Очередь ожидания команд GDI внутри DWM может отнять большой объём памяти.

Windows 7: возвращение "блудного сына"


Логотип Windows 7, которая заинтересовала многих пользователей.

Многие пользователи считали Vista неудачной ОС - она воспринималась как монстр, буквально "сжирающий" память. В любом случае, на эту операционную систему нужно было взглянуть ещё раз, в свете выпуска Windows 7. Вместе с фундаментальными изменениями самой системы, графика Windows 7 дала то, что забрала Vista – неограниченное ускорение 2D-графики во всех областях, включая функции отрисовки GDI.

Благодаря переходу на WDDM 1.1, Windows 7 предотвратила удвоенное использование памяти (первый раз для буферов отдельных, второй раз для каждого активного окна в DWM). Это позволило сделать систему более простой, с более скромными требованиями к ресурсам. В Windows Vista удвоенное потребление памяти для окон может объяснить, почему память у системы "съедалась" столь нещадно.


В случае Vista ОС "съедает" всю память, которую может получить... (источник: Microsoft).



…но в случае Windows 7 требования более скромные (источник: Microsoft).

Для дополнения GDI под Windows 7 был объявлен и Direct2D. Данный интерфейс использует преобразование команд, аналогичное Direct3D, чтобы и реализовать аппаратное ускорение, и поддержать более сложный набор графических функций. Direct2D даёт преимущество по скорости GDI вместе с расширенными возможностями GDI+, судьба которого не сложилась. Впрочем, нам ещё предстоит увидеть, сможет ли Direct2D получить поддержку со стороны разработчиков.

Даже сегодня подавляющее большинство программ по-прежнему используют GDI API для рендеринга и работы с графическими элементами 2D. Нам понравилось, что Windows 7 вернула аппаратное ускорение этих команд, от которого отказалась Vista.



Асинхронный GDI под Windows 7 (источник: Microsoft). Нажмите на картинку для увеличения.


Почти идеальное масштабирование при одновременной работе с несколькими окнами (источник: Microsoft)

Подведём краткий итог по Windows 7.

  • Прямое перенаправление команд отрисовки GDI к графическому драйверу через DWM.
  • Асинхронная и одновременная обработка команд GDI для нескольких окон.
  • Стратегии, избегающие чрезмерного использования памяти для создания очереди графических запросов.
  • Новые и улучшенные драйверы WDDM 1.1.

Требования производителей графических процессоров

Возвращение аппаратного ускорения 2D-графики вернуло в игру производителей графических процессоров. Драйверы под Windows 7 должны быть специально собраны, чтобы они могли дать аппаратное ускорение для двумерных команд ускорения GDI, а также поддерживать работу в слоях 2,5D отдельных окон.

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

Windows 7: у линейки видеокарт Radeon HD 5000 отсутствует 2D-ускорение

AMD приложила массу усилий к разработке видеокарт DirectX 11 последнего поколения; вполне естественно, что для доработки программной стороны потребовалось некоторое время (вряд ли для кого является секретом, что последующие выпуски драйверов улучшают производительность и стабильность многими разными способами). Мы не можем обойти в данном вопросе и nVidia, поскольку мы обнаружили схожие проблемы у драйвера GeForce компании при использовании 2D-графики на мобильных процессорах компании. Для нашей статьи мы использовали наиболее свежую версию драйвера Catalyst на момент тестов - 9.12.



Catalyst и Windows 7 плавают в неспокойных морях. Нажмите на картинку для увеличения.

Проблема 1: ATIKMDAG прекращал отвечать, затем восстанавливался

Если вы сталкивались с подобным сообщением об ошибке, то наверняка это происходило после перехода обратно в 2D-режим после выхода из 3D-приложения. Нам ничего не оставалась, кроме как предположить, что это результат какой-либо ошибки в драйвере.

Позвольте напомнить: когда интерфейс Aero выключен, то DWM отключается, поэтому 2D-ускорения больше не происходит (то есть мы получаем то же самое под Windows 7, что и под Vista). Поскольку мы сталкивались с этой ошибкой снова и снова на системах с установленными видеокартами Radeon HD 5750 и Radeon HD 5870 (в двух разных тестовых конфигурациях), то нам пришлось намеренно отключить интерфейс Aero в обоих случаях. После подобного манёвра ошибки уже не появлялись. Что интересно, точно такую же ситуацию (и её решение) мы обнаружили на ноутбуках с видеокартами GeForce. Конечно, только время покажет, является ли это просто совпадением или указывает на конфликт между DWM, драйверами и аппаратным ускорением 2D-графики.

Нашим следующим главным подозреваемым оказались относительно низкие частоты видеокарт AMD по умолчанию в 2D-режиме, а также некоторые проблемы в ранних BIOS видеокарт. Впрочем, чтобы подтвердить или опровергнуть их влияние, нам потребуются долгосрочные наблюдения – либо после выхода новой версии драйвера должно измениться поведение.

Мы упёрлись в эту проблему, поскольку у нас сразу же возникли трудности с тем, чтобы заставить Radeon HD 5870 поддерживать 2D-графику. Многие могут, конечно, добавить в этом отношении, что 3D-карты создаются для игр, а не для 2D-приложений. Но если вы читали предыдущие разделы статьи, то должны признать, что эта проблема стала серьёзной только с выходом Windows 7 (а не Windows Vista). Если быть более конкретным, то большинство 3D-видеокарт без проблем способны справиться с 2D-графикой в наши дни. Но прямое сравнение поддержки 2D-ускорения между GeForce GTX 285 и Radeon HD 5870 привело к тому, что видеокарта AMD оказалась в аутсайдерах. Фактически, при сравнении с интегрированным графическим решением nVidia GeForce 7050 (nForce 610i), которое не имеет собственной памяти, новые Radeon встают лишь на второе место.

Всё становится более интересным, когда DWM выключен. Даже если в данном случае 2D-ускорение уже невозможно, видеокарты AMD дают прирост по производительности. По сравнению с Nvidia GeForce, запуск видеокарты AMD с отключённым DWM даёт ей прирост производительности. Даже CorelDraw и AutoCAD работают на Radeon HD 5870 заметно быстрее при выключенном DWM. Это выставляет nVidia в выгодном свете и противоречит как логике, так и предыдущему опыту тестирования данных GPU.


Аппаратное ускорение 2D с интерфейсом Aero и включённым DWM даёт преимущество видеокартам GeForce.


Без Aero и аппаратного ускорения 2D видеокарты AMD работают вплоть до пяти раз быстрее. Шокирует!

Именно по этой причине мы несколько раз повторили тесты PassMark на этих видеокартах.


Интерфейс Aero и DWM выключены – видеокарты AMD заметно ускоряются. Нажмите на картинку для увеличения.

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

Tom2D Benchmark: Radeon HD 5870 против GeForce GTX 285 под Windows 7

С помощью нашего нового теста мы надеемся глубже разобраться в истинных причинах подобного падения производительности 2D, которые мы недавно обнаружили с видеокартами Radeon HD 5870, 5850 и 5750 в нашем распоряжении. Начнём с того, что 2D-ускорение функций GDI под Windows 7 явно не работало ни на одной из моделей линейки Radeon HD 5000, то есть перед нами не просто серьёзное замедление. В чём проблема: в драйвере или в "железе"? В случае с nVidia тоже не всё оказалось благополучно: на видеокартах этой компании ускорялись не все возможные функции.

Тестовая конфигурация
Процессор Intel Core 2 Quad Q6600, 2,4 ГГц @ 3,2 ГГц, степпинг G0, кэш L2 8 Мбайт, LGA 775
Память 4 Гбайт DDR2-1066 CL5
Материнская плата A-Data Vitesta Extreme
Операционная система Windows 7 Ultimate x64
Видеокарты Radeon HD 5870, GeForce GTX 285
Графический драйвер Catalyst 9.12, GeForce 195.62
Видеокарты Тактовая частота при включённых Aero/DWM Тактовая частота без ускорения
ATI Radeon HD 5870 850 МГц 157 МГц
Nvidia GeForce GTX 285 648 МГц 300 МГц

Чтобы заложить более прочную основу для сравнения включённого/выключенного 2D-ускорения, мы также провели все наши тесты на старом чипсете nForce 610i с интегрированным графическим ядром GeForce 7050 (без выделенной памяти). Мы установили тот же самый процессор и 4 Гбайт памяти, после чего использовали ту же самую операционную систему Windows 7. Мы также проверили производительность предшественницы Radeon HD5870, видеокарты ATI Radeon HD 4870, в нашей тестовой платформе.


В данном тесте все тестовые видеокарты находятся в узком диапазоне производительности.

Интересно было бы услышать от nVidia комментарии по поводу того, почему интегрированный графический процессор отображает 2D-графику быстрее, чем GeForce GTX 285, пусть даже разница весьма скромная.

Видеокарта Radeon HD 4870, взятая нами для сравнения, расположилась третьей снизу, хотя никаких особых недостатков она не демонстрирует.


Удивительно, но видеокарта Radeon HD 5870 просто не способна выводить линии с аппаратным ускорением с приемлемой производительностью.

Если обе тестовые видеокарты nVidia и AMD дали выдали приемлемые и относительно близкие результаты с выключенным 2D-ускорением, когда всю работу выполнял CPU, между двумя видеокартами открывается существенный разрыв после включения Aero. GeForce GTX 285 работает в 11 раз быстрее ATI Radeon HD 5870. Что ещё хуже, интегрированный графический процессор с материнской платы за $50 двухлетней давности на порядок обходит видеокарту за $400.

Полученные нами данные для Radeon HD 4870 показывают небольшую разницу между активным режимом Aero и простым режимом (без ускорения графики) под Windows 7, что заставляет предположить об отсутствии ускорения по отрисовке линий под Windows 7. Данная видеокарта отказалась заметно медленнее GeForce GTX 285 и интегрированного графического решения, однако она всё же обходит Radeon HD 5870 с включённым и выключенным ускорением.


Данный тест даёт примерно такую же картину, что и тест отрисовки линий. Видеокарта Radeon HD 5870 находится в конце, подтверждая наше предположение о том, что она не способна правильно работать с 2D-приложениями. Это вряд ли можно назвать терпимым даже для потребительского рынка.

С включённым интерфейсом Aero и активным DWM, видеокарта GeForce GTX 285 даёт в девять раз более высокую производительность. Точно также даже старое интегрированное ядро чипсета значительно обходит новую видеокарту AMD. Кстати, производительность Radeon HD 4870 оказалась весьма любопытной: видеокарта способна аппаратно ускорять вывод кривых, пусть даже производительность снижается по сравнению с обоими решениями nVidia.


Поскольку у нашей Radeon HD 5870 наблюдались явные проблемы с рендерингом линий (особенно при насыщенных штрихах), мы видим, что половина результатов нашего теста прямоугольников соответствует предыдущим находкам, и это не удивляет.

В любом случае, весьма интересно видеть, как производительность Radeon HD 5870 удваивается после включения аппаратного ускорения (по сравнению с выключенным ускорением), пусть даже производительность оказывается чуть хуже GPU GeForce 7050.

Тест прямоугольников оказался единственным, где мы обнаружили заметный эффект включения аппаратного ускорения на видеокартах ATI, и где аппаратное ускорение достойно своего названия. Видеокарта Radeon HD 4870 выиграла от этого эффекта сильнее, чем 5870, пусть даже она отстала от остальных видеокарт в данном тесте без ускорения.


В данном случае победа присуждается старому интегрированному графическому ядру. Nvidia nForce 610i обходит все другие дискретные видеокарты с удивительно большим отрывом, причём неважно, с активным 2D-ускорением мы их берём или с неактивным. Интересно отметить, что для обеих топовых 3D-видеокарт ускорение вывода полигонов не работает вообще.

Интегрированное графическое ядро с включённым Aero работает в 10 раз быстрее, чем Radeon HD 5870. Без ускорения Radeon HD 4870 работает чуть медленнее, чем 5870. Но после включения Aero производительность 4870 более чем в два раза превышает 5870.


Результаты похожи на те, что мы видели выше. Обе high-end видеокарты не обеспечивают 2D-ускорения, в отличие от интегрированного чипсета. Видеокарта Radeon HD 5870 становится аутсайдером, а старая Radeon HD 4870 располагается где-то посередине.

Дополнение

Мы получили схожие результаты, когда мы использовали Radeon HD 5750, где сглажены некоторые дефекты, касающиеся 5870. Мы также сравнивали драйверы Catalyst 9.11 и 9.12 и обнаружили заметный прирост производительности при переходе со старой версии на новую, независимо от того, было включено аппаратное ускорение или нет. Нашим следующим сравнением будет измерение производительности Windows 7 и Vista, но мы оставим его до второй части статьи. Достаточно сказать, что даже здесь мы обнаружили немало сюрпризов во время проведения тестов.

Заключение

Если судить по нашему анализу текущей ситуации, то у новых видеокарт линейки ATI Radeon HD 5000 наблюдаются проблемы с 2D-графикой. Также нас весьма беспокоит и то, что старый интегрированный чипсет оказался быстрее в некоторых областях (против обеих дискретных видеокарт AMD и nVidia). Кроме того, мы не смогли найти какого-либо приемлемого решения для работы с программами, использующими векторную графику. Причём это касается не только нашего тестирования; это касается всех, кто регулярно работает с 2D-графикой. Честно говоря, довольно сложно представить, как старая видеокарта Radeon HD 4870 смогла вплотную подойти или даже победить новые видеокарты в столь большом количестве тестов.

Хотя 2D-ускорение (включая слои 2,5D) работает хорошо, AMD пока не реализовала некоторые базовые функции GDI в линейке видеокарт Radeon HD 5000. После первоначального появления Windows 7 прошло уже несколько выпусков драйверов, поэтому ситуацию будет сложно понять тем, кто потратил несколько сотен долларов на новенькую видеокарту, но при этом получил "тормоза" в 2D-приложениях. Мы также вынуждены напомнить, что всё это касается не только нашего синтетического 2D-теста, но и различных реальных приложений, которые мы используем в наших тестах, включая AutoCAD, Corel Draw, Adobe Illustrator, Photoshop CS3/CS4, Microsoft Publisher, PowerPoint и так далее. Это требует срочной и серьёзной доработки драйверов со стороны AMD, особенно в связи с тем, что наши результаты под Vista демонстрируют намного более высокую производительность, чем под Windows 7 (во второй части статьи мы как раз об этом и поговорим).

Во время подготовки статьи и проведения тестов мы несколько раз звонили Анталю Танглеру (Antal Tungler), техническому PR-менеджеру AMD, обсуждая с ним 2D-производительность линейки Radeon HD 5000 под Windows 7. Когда мы доказали себе, что данные проблемы производительности связаны конкретно с проблемами GDI, которые испытывает почти любая программа, работающая с окнами на рабочем столе, подобная ситуация уже не показалась нам терпимой, особенно для домашних и офисных пользователей. Тем более что интегрированный графический GPU у конкурента справлялся с 2D-графикой более эффективно.

Мы можем только предполагать (и надеяться), что причина и возможное решение кроются в драйверах Catalyst. Если это так, что AMD сможет исправить проблемы довольно легко. Учитывая недавний выход недорогих видеокарт , можно предположить, что проблемы касаются всей линейки. Но что нас беспокоит больше, учитывая результаты тестов - прямоугольники получают заметное ускорение, а все другие графические примитивы (особенно линии и кривые) - нет. Мы наблюдаем серьёзное падение производительности при активации аппаратного ускорения GPU - а это говорит о том, что ничего хорошего здесь не происходит. Дискретная видеокарта nVidia также отстаёт при рендеринге эллипсов и полигонов, и нам очень интересно узнать, почему это происходит.

Пока что мы рекомендуем пользователям видеокарт линейки Radeon HD 5000 отключать интерфейс Aero при работе с программами, интенсивно использующими 2D-графику. В таком случае прирост производительности может составить до 300%, что легко компенсирует отсутствие красивых и прозрачных оконных рамок. Кроме того, вы можете отключить Aero только для запускаемых программ, чтобы не отказываться от интерфейса Aero вообще.

Нажмите правой клавишей на иконку программы, затем выберите пункт "Свойства/Properties" из появившегося меню. Выберите закладку "Совместимость/Compatibility" в окне свойств, после чего отметьте галочкой пункт "Отключить композицию рабочего стола".


При выборе пункта "Отключить композицию рабочего стола" поддержка DWM деактивируется.

Во второй части мы вновь протестируем возможности видеокарт AMD и сравним их с прямыми и непрямыми конкурентами от nVidia. Между тем мы пообщаемся с представителями AMD и nVidia и обсудим результаты нашего первоначального теста. Нам очень интересно узнать, что они ответят.

После интенсивного обсуждения этой темы с нашими коллегами мы решили, что проведём более глубокие тесты на разном "железе" под XP, Vista и Windows 7. Нашей целью будет найти более глубокое понимание графических возможностей 2D всех этих операционных систем. Мы планируем взглянуть на старые видеокарты S3, Voodoo, многочисленные старые модели GeForce и полную линейку видеокарт AMD/ATI. В общем, мы хотим ничего не оставить в стороне, включив в тесты даже интегрированные графические ядра из нашего большого набора материнских плат.

Мы уже знаем, что во время этого процесса мы обнаружим несколько интересных моментов, а также и ряд разочарований. Во второй части статьи мы также приведём более точное описание тестов, рейтингов тестовых результатов, а также дадим возможность скачать Tom2D Benchmark самостоятельно. Мы уверены, что вы найдёте этот материал весьма интересным, особенно когда мы обнаружим, какие видеокарты потребительского уровня дадут более высокую графическую производительность 2D под конкретные версии Windows. Вас ждут сюрпризы, так что оставайтесь с нами!

Обновление . Взглянув на наши предварительные результаты 2D-производительности, представители AMD выдвинули следующие предположения.

  • Специалисты Tom’s Hardware для измерения взяли область (2D-линии и т.д.), которая ещё не была оптимизирована.
  • До этого нового теста мы не наблюдали любых других приложений, которые бы упирались в "узкое место" таким же образом, поэтому и не фокусировали на этом внимание раньше.
  • Наш первоначальный анализ показывает, что в данной сфере нет аппаратных ограничений.
  • Мы попросим нашу команду разработчиков драйверов оптимизировать их и под эту область, и постараемся представить новый драйвер для решения проблемы как можно быстрее.
  • Мы уже нашли простой способ серьёзно увеличить нашу производительность, и мы попытаемся реализовать его в будущих версиях драйвера Catalyst (нам нужно написать код, валидировать его, убедиться, что он не испортит ничего другого и т.д.).

Я знаю приличное количество С++, и теперь я хотел исследовать создание игры. Мне было интересно, какой лучший подход будет в плане написания аппаратной ускоренной игры, которая по-прежнему кросс-платформенная (Windows/OSX/Linux). Это будет игра 2d, но достаточно интенсивная, чтобы рендеринг CPU, вероятно, не сократил бы ее.

Наконец, я видел такие библиотеки, как http://www.sfml-dev.org/ , которые, возможно, упростили, следует ли мне спуститься по этому маршруту?

Еще раз спасибо.

6 ответов

Это нонсенс ребята

OpenGL IS кросс-платформенный. Нет необходимости в Qt или такой. Необходимо адаптировать только несколько частей: API окон и API ввода, которые являются единственными функциями, зависящими от подпрограмм, специфичных для ОС.

У вас есть несколько возможностей:

Перекрестная платформа с аппаратным ускорением 2d С++ app?

Я знаю, что OpenGL, но я не могу найти каких-либо учебников о том, как использовать его в кросс-платформенной манере, все они сосредоточены на одной платформе.

SDL_Init(SDL_INIT_VIDEO); SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8); SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8); SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8); SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 16); SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1); SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 0);//disable vsync if (SDL_SetVideoMode(scrWidth, scrHeight, 32, SDL_OPENGL) == 0){ fprintf(stderr, "couldn"t set mode %dx%d!\n", 640, 480); SDL_Quit(); return -1; } glewInit();//if you use glew, shaders, extensions. while(gameIsRunning()){//game loop glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT); //OpenGL rendering here glFlush(); SDL_GL_SwapBuffers(); } SDL_Quit();

Подробнее см. в документации по sdl.

Использование SDL также возможно, но я боюсь, что игра может не работать, если я ее использую. Это обязательно верно?

Если vsync отключен, вы можете получить от нескольких сотен до тысячи кадров в секунду. Точная производительность зависит от сложности вашего оборудования и сложности сцены. У меня было 300 кадров в секунду для простого 3D-искателя подземелий, в котором использовался "RAW" opengl без отображения списков/объектов буфера вершин. Кроме того, если вы используете механизм с фиксированной частотой кадров или таймером, вы не будете получать больше кадров в секунду, чем вы просили.

SDL использовался для переноса Unreal 2004 на Linux. Он также использовался в порту Linux Doom 3/Quake 4. Поэтому он тщательно протестирован и хорошо известен.

Для меня вопрос не в том, следует ли вам использовать библиотеки или нет. Это библиотека, которую вы должны использовать. Если вы хотите написать игру, найдите библиотеки, которые будут решать большинство проблем с переносимостью для вас. Это позволит вам сосредоточиться на том, что важно больше всего: самой игре. Другие дали больше предложений библиотеки, которые я мог бы вам дать.

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

// separate files class LowLevelGraphicStuff { // abstract }; class LowLevelGraphicStuff_SFML: public LowLevelGraphicsStuff { // actual SFML implementation }; class LowLevelGraphicsStuff_OGL: public LowLevelGraphicsStuff { // actual OpenGL implementation }; // main // Run the game with the SFML implementation. gameLoop(new LowLevelGraphicsStuff_SFML()); // Run the game with the OpenGL implementation. gameLoop(new LowLevelGraphicsStuff_OGL());

В Android, как и в других популярных операционных системах, есть свои секреты. Некоторые из них полезны, но используются редко. Мы расскажем о малоизвестных и интересных секретах Андроида.

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

Инженерные коды

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

*#*#4636#*#* - информация и настройка;

*#*#8351#*#* - включить запись телефонных разговоров;

*#*#4636#*#* - предоставит полезные данные об устройстве:

  • о телефоне;
  • о батарее;
  • статистика и использование телефона и батареи.

*#*#7780#*#* - отформатирует смартфон или планшет, но оставит все приложения, будь то системные или загруженные. Также останутся все файлы на внешней SD-карте.

*2767*3855# - полностью отформатирует девайс.

*#*#34971539#*#* - позволяет управлять прошивкой камеры, а также получить о ней информацию. После введения кода вы можете выбрать:

  • обновление прошивки камеры в образ (ни в коем случае не делать!);
  • обновление прошивки камеры;
  • данные о прошивке камеры;
  • количество выполняемых ранее прошивок камеры.

*#*#7594#*#* - позволит изменить функцию при длительном зажатии кнопки питания. Другими словами, вы можете назначить для нее выключение или перезагрузку гаджета, включение/выключение мобильных данных и так далее;

*#*#273283*255*663 282*#*#* - позволяет сделать резервное копирование любых файлов на устройстве;

*#*#197328640#*#* - открывает меню обслуживания. Вы можете протестировать ваш гаджет, а также сменить настройки WLAN, Bluetooth и GPS;

*#*#232339#*#* или *#*#526#*#* или *#*#528#*#* - настройки WLAN;

*#*#232338#*#* - поможет узнать МАС-адрес Wi-FI;

*#*#1472365#*#* - тест GPS системы;

*#*#1575#*#* - GPS;

*#*#232331#*#* - Bluetooth;

*#*#232337#*# - поможет узнать адрес Bluetooth.

Коды для тестирования

Они запускают различные тесты устройства.

*#*#0283#*#* - тестирование передающей инфраструктуры;

*#*#0*#*#* - экрана (LCD);

*#*#0673#*#* или *#*#0289#*#* - звука;

*#*#0842#*#* - девайса (подсветки и вибрации);

*#*#2663#*#* - сенсора;

*#*#2664#*#* - еще один тест сенсора;

*#*#0588#*#* - датчика движения;

*#*#3264#*#* - RAM.

Режим разработчика

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

Для начала необходимо включить режим разработчика. Заходим в настройки и листаем в самый низ. Находим пункт «Об устройстве», и нажимаем на него несколько раз подряд. Гаджет потребует подтверждения разблокировки режима разработчика – нажмите ОК.


Теперь нам доступен ряд возможностей, пользоваться которыми нужно аккуратно! Они могут привести к системным ошибкам, о чем предупредит сам смартфон. Ниже представлены и описаны все функции данного режима.

  • Пароль резервного копирования. Если не хотите, чтобы чужие руки делали резервное копирование всех файлов вашего телефона (например, после этого загрузив все данные на свое устройство), поставьте пароль на использование.
  • Активный режим. Если ваш смартфон заряжается, то он не будет гаснуть (конечно, если вы сами его не выключите).
  • Защитить карту памяти SD. Все программы будут спрашивать разрешение на использование данных с карты памяти. Так, например, вы можете предотвратить работу вируса.
  • Отладка USB нужна для выполнения взаимодействия гаджета с ПК.
  • Эмуляция расположения эмулирует расположение.
  • Выберите отлаживаемое приложение.
  • Подождать отладчик. Когда отладчик подключится, откроется заданное выше приложение.
  • Показывать прикосновения. Довольно интересная функция, которая показывает, в каком месте вы прикоснулись к экрану. Очень полезная штука, ведь с помощью нее можно обозначать касания на экран и делать скриншоты к инструкциям, как мы сделали в статье про .
  • Показывать место указателя. Выводит подробную информацию о прикосновении и слайде по экрану (Местоположение по Х и Y и др).


  • Показывать ограничения макета. Интересная функция, с помощью которой можно увидеть размер каждого элемента на экране.

  • Показывать обновления представлений GPU. Окна, представленные посредством GPU, будут мигать.
  • Показывать обновления экрана. Обновляемая область экрана будет мерцать ярко-желтым цветом.
  • Настройка анимации. Включает масштаб анимации окна, масштаб анимации перехода и шкалу длительности аппарата. Их отключение очень помогает .
  • Отключить аппаратное наложение – постоянное использование GPU для композиции экрана.
  • Принудительная обработка GPU. Использовать аппаратное ускорение 2D в приложениях.
  • Строгий режим. Если процесс будет выполнять длительные операции в главном потоке, то экран будет мигать.
  • Выводить использование ЦП – информация об использовании центрального процессора в правом верхнем углу.

  • Профиль обработки GPU – измерение времени обработки в ASDG.
  • Включить трассировку. Включает различные трассировки, например, graphics, Input, View и другие.
  • Не сохранять операции. Удалять операции после их завершения пользователем.
  • Фоновые процессы. Позволяет ограничить количество фоновых процессов от одного до четырех.
  • Показать все ANR. Выводить окно «Приложение не отвечает» для фоновых процессов.

2 D - a кс e л e р a т op - графический ускоритель для обработки двухмерных графических данных (2D), реализует аппаратное ускорение таких функций, как прорисовка графических примитивов, перенос блоков изображения, масштабирование, работа с окнами, мышью, преобразование цветового пространства. Первона­чально видеоадаптеры с аппаратным ускорением графических функций делились на две группы: видеоадаптеры с графическим ускорителем (акселератором) и видеоадаптеры с графическим сопроцессором.

Графический акселератор - устройство, выполняю­щее заданные логические или арифметические операции по жест­кому алгоритму, который не может быть изменен.

Графический сопроцессор - более универсальное устройство и работает параллельно с центральным процессором. Основное отличие графического сопроцессора от графического акселератора в том, что сопроцессор можно запрограммировать на выполнение различных задач, поскольку он является актив­ным устройством: имеет возможность, как и центральный про­цессор, обращаться к системной оперативной памяти и управлять шиной ввода/вывода.

В современных видеоадаптерах объем и сложность графических функций, выполняемых графическим сопроцессором, стали со­измеримы с объемом задач, решаемых центральным процессором ПК. В связи с этим Chipset, составляющий основу современного видеоадаптера с аппаратной поддержкой графических функций, называют графическим процессором.

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

Совокупность приложений и задач, в рамках которых реализу­ется эта схема построения трехмерного изображения на экране монитора PC, называется трехмерной графикой, или 3D (З- Dimentional - трехмерный).

Синтез трехмерного изображения. Зd-конвёйер

Синтез ЗD-изображения выполняется путем аналитического расчета различных параметров изображения для создания визу­альных эффектов, обеспечивающих ощущение его объемности и реальности. В частности, в процессе синтеза ЗD-изображения вы­полняются:

    оценка расстояния до предмета путем анализа информации о его размерах (чем меньше объект - тем он дальше);

    оценка последовательности наложения предметов один на другой (кто выше - тот ближе);

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

    анализ световых эффектов на предмете (теней, бликов и т. п.).

Для получения этих эффектов процесс синтеза трехмерного изоб­ражения объекта в виде его двухмерной проекции на экране мони­тора строится по модели, называемой З D -конвейером. Выделяют сле­дующие основные этапы ЗD-конвейера.

1.Построение геометрической модели поверхности объекта путем задания трехмерных координат его опорных точек и уравнений соеди­няющих их линий. Полученная геометричес-кая модель представляет собой так называемую каркасную мо­дель объекта (Wireframe). На рис. 4.14 изображена каркасная модель тора, заданного координатами центра 0 (х, у, z), внут-ренним радиусом R1 и радиусом сечения R2.

2.Разбиение поверхности получен­ного объекта на элементарные плос­кие элементы (прямоугольники или треугольники) - тесселяция (Tesselation), или триангуляция. Это приводит к тому, что поверхность объекта представляет собой совокуп­ность плоских граней - многоугольников, в частности треугольников, как показано на рис. 4.15. Поверхность объекта воспроиз­водится точнее при увеличении числа и уменьшении размеров многоугольников (ср. рис. 4.15, а, б).

3.Моделирование движения объекта: его перемещение, вращение и изменение размеров (формы) - трансформация (transormation) - сводится к стандартному преобразованию ко-ординат вершин отдельных граней в виде многоугольников и реализуется путем выполнения множества различных алгебраических опера-ший с использованием тригонометрических функций. На рис. 4.16 показана трансформация формы объекта путем изгиба и скручи­вания.

4.Расчет освещенности (Lighting) и затенения (Shading) объекта производится в два этапа. Сначала выполняется расчет освещенности каждого элементарного многоугольника с учетом его удаленности от источника света и угла падения светового луча. Чтобы поверх-ность объекта не выглядела со­стоящей из множества отдельных плоских граней, как это показано на рис. 4.17, а, применяют методы затенения, т.е. дополнительно про­изводят интер-поляцию значений ос­вещенности, позволяющую плавно изменять освещенность каждой гра­ни и скрыть резкие переходы меж­ду ними (рис. 4.17, б).

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

Обработка данных о вершинах элементарных многоугольников, полученных на предыдущих этапах (Triangle Setup), заключающая­ся в преобразовании формы представле-ния координат вершин: из чисел с плавающей точкой (вещественных чисел) в целые числа, а также в сортировке вершин и других действиях.

Удаление скрытых поверхностей - HSR (Hidden Surface Removal), т.е. исключение из проецирования тех элементов поверх­ности объекта, которые оказываются невидимыми с точки на­блюдения.

Закраска элементарных треугольников, или текстурирование, выполняется наложением текстур (Texture Mapping). Текстура (Texture) - это элемент обшивки объекта, т.е. изобра-жение участка его поверхности, которое хранится в виде квадратной растровой картинки, состоящей из текселов (Texel - Texture Element - элемент текстуры). После наложения текстуры (рис. 4.18, а) кар­касная модель как бы покрывается своеобразным покрытием - текстурой и становится похожей на реальный объект (рис. 4.18, б). В процессе текстурирования каждый многоугольник, составлявший каркасную модель, заменяется на элемент текстуры, а зна­чение каждого пиксела двухмерного изображения вычисляется по значению соответствующего тексела текстуры.

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

MIP -текстурирование, или мипмэппинг (MIP - Multum In Parvo - много в одном), применяется для устранения пикселизации при приближении к ЗD-объекту. MIP-текстурирование заключается в том, что в памяти акселератора хранятся несколько копий одной и той же текстуры, но с различным разрешением LOD (Level Of Detalization - уровень детализации). Каждая последующая копия текстуры содержит в четыре раза больше пикселов, чем предыду­щая. Совокупность всех копий одной и той же текстуры называют MIP-каскадом, пример которого дан на рис. 4.19. В процессе «прорисовки» ближних к наблюдателю поверхностей используют­ся более крупные текстуры, а при прорисовке дальних - более мелкие. Применение мипмэппинга требует значительных объемов памяти акселератора. Для хранения текстуры не в локальной па­мяти ЗD-акселератора, а в RAM PC и при необходимости быстро их подгружать используется локальная шина AGP с высокой про­пускной способностью.

9. Моделирование эффектов прозрачности и полупрозрачности заключается в том, что на основе информации о взаимной прозрачности объектов и среды выполняется коррек-ция цвета пикселов - так называемое альфа-смешение (Alpha - blending ) и затума-нивание (Fogging ).

10. Коррекция дефектов изображения путем сглаживания - ан тиалиасинг (Anti - aliasing ). Антиалиасинг применяется для устранения дефектов изображения типа «лестничного» эффекта на наклонных линиях, муара. Различают краевой (Edge Anti-aliasing) и пол-ный (Full-screen Anti-aliasing - FSAA) антиалиасинг. В первых моделях игровых уско-рителей использовался только краевой антиалиасинг, для современных ЗD-акселераторов обязательным является полный антиалиасинг.

Краевой антиалиасинг заключается в усреднении цвета пикселов на краях (реб-рах) грани на основе взвешенного сумми­рования цветов прилегающих граней. Техника взвешенного сум­мирования заключается в определении весовых коэффициентов, с которыми суммируются цвета при определении цвета краевого пиксела. При этом пола-гают, что каждая точка (линия) на краю грани имеет фиксированную, ненулевую пло-щадь, а значения весовых коэффициентов зависят от того, какую часть этой пло­щади перекрывают прилегающие грани. На рис. 4.20 дана иллюст­рация техники взвешенного суммирования.

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

Интерполяция недостающих цве тов - (Dithering ) используется в том случае, когда в текущем видеорежиме 3D-акселератора для кодирования цвета пиксела используется менее 24 бит (напри­ мер, в режиме High Color при 16-битном цвете).


Окончательное формирование кадро вого буфера (Frame Buffer ) - области памяти ЗD-акселератора, в которую помещается спроецированное двухмерное изображение. Кадровый буфер используется для формирования выходного, аналогового видеосигнала ЗD-ускорителя.

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

13. Постобработка (Post-processing) применяется в том случае, когда требуется реализовать какие-либо двухмерные эффекты над подготовленным кадром как единым целым.

Этапы 1-6 ЗD-конвейера образуют его геометрическую ста­дию, на которой выполняются интенсивные тригонометрические вычисления с помощью CPU. Однако существует тенденция обес­печения современных игровых ЗD-акселераторов специальным про­цессором, обеспечивающим аппаратное ускорение выполнения геометрической стадии ЗD-конвейера.

Этапы 7-13 ЗD-конвейера образуют стадию прорисовки объек­та, или стадию рендеринга (Rendering-изображение, рисова­ние, визуализация). На этой стадии все действия выполняются уже с растровыми объектами, состоящими из отдельных, дис­кретных элементов - пикселов и текселов. Выполняемые на ста­дии рендеринга операции не характерны для центрального про­цессора (как на геометрической стадии), поэтому именно на этом этапе конвейера необходимо аппаратное ускорение. Большин­ство современных ЗD-ускорителей предназначено для рендеринга на аппаратном уровне и различается лишь числом реализуемых функций.

Программным интерфейсом для ЗD-акселераторов служит так называемый интерфейс прикладного программирования (Application Program Interface - API). API занимает промежуточное положение между высокоуровневыми прикладными программами и низко­уровневыми командами различных ЗD-акселераторов и обеспечивает эффективное преобразование запросов прикладной програм­мы в оптимизированную последовательность низкоуровневых ко­манд. Благодаря API, разработчики прикладных программ избав­лены от необходимости работать с низкоуровневыми командами акселератора.

В настоящее время существуют несколько платформ API, отли­чающихся областями применения.

DirectX разработана фирмой Microsoft, используется в игровых приложениях, работающих под управлением операционной сис­темы Windows 95/98, и включает в себя несколько узконаправ­ленных API:

DirectDraw обеспечивает использование аппаратных средств ус­корения обычной, двухмерной графики;

Direct3D отвечает за работу графической системы в режиме со­здания трехмерных изображений;

DirectInput обеспечивает аппаратно независимый ввод инфор­мации в ПК через клавиатуру, мышь и джойстик;

DirectPlay используется при совместной игре на нескольких ком­пьютерах, объединенных в сеть или соединенных непосредствен­но, через параллельный или последовательный порты;

DirectSound управляет использованием ресурсов звуковой сис­темы ПК.

В архитектуре Direct3D заложен принцип проверки функцио­нальных возможностей установленного аппаратного обеспечения. В соответствии с этим принципом прикладная программа сначала запрашивает Direct3D-coвместимый драйвер об аппаратно под­держиваемых данным акселератором ЗD-функциях, а затем в за­висимости от ответа активизирует поддерживаемые функции. Это избавляет от необходимости производить ручную настройку.

DirectX является жестко регламентированным, закрытым стан­дартом, который не допускает изменений до выхода в свет своей новой версии.

OpenGL используется в основном в профессиональных прило­жениях (CAD, системы трехмерного моделирования, симуляторы и т.п.), работающих под управлением операционной системы Windows NT. Вместе с тем существуют и игры, ориентированные на OpenGL, например Quake.

API OpenGL построен на основе концепции открытого стан­дарта, имеющего небольшой базовый набор функций и множе­ство расширений, реализующих более сложные функции. Произ­водитель Chipset карты ЗD-акселератора обязан создать BIOS и драйверы, выполняющие базовые функции OpenGL, но не обя­зан обеспечивать поддержку всех расширений. В результате возни­кают проблемы, связанные с написанием производителями драй­веров для своих изделий, которые поставляются как в полном, так и в усеченном виде. К числу OpenGL-совместимых драйверов относятся следую­щие:

ICD (Installable Client Driver - драйвер приложения-клиента) обеспечивает максимальное быстродействие, поскольку содержит низкоуровневые коды, обеспечивающие поддержку не только ба­зового набора функций, но и его расширений.

MCD (Mini Client Driver) содержит оптимизированный код лишь для некоторых этапов ЗD-конвейера, поэтому акселератор под его управлением работает медленнее.

Мини-порт - группа специализированных OpenGL-совмеcтимых драйверов, каждый из которых специально разработан для работы с какой-либо одной программой или игрой. Такой мини-порт применяется, когда, например, возникает необходимость поиграть в QuakeGL или Quake II на ПК с Windows 95 и 3D-акселератором, не рассчитанным на использование OpenGL.

Раппер (Wrapper - устройство для оборачивания, завертыва­ния, окутывания) - мини-порт, который может работать как ICD за счет перевода инструкций OpenGL в инструкции Direct3D, эбеспечивая при этом самую низкую скорость работы по сравне­нию с драйверами других типов.

Game Engine - «игровой движок» - драйвер, разработанный Идя конкретной ЗD-платы и обеспечивающий максимальную про­изводительность за счет непосредственного использования низ­коуровневых команд акселератора, без использования API.

Принципиальным отличием API OpenGL от DirectX является Го, что OpenGL ориентирован на корректность создаваемых изоб­ражений, тогда как для DirectX важны скорость прорисовки и естественность изображения.

Кроме того существуют Native API, создаваемые производите­лями ЗD-акселераторов исключительно для своих Chipset с целью наиболее эффективного использования их возможностей.

Для настройки видеосистемы с целью обеспечения максималь­ной производительности при работе с трехмерной графикой пользователь ПК должен:

*при выборе ЗD-платы четко представить область ее будущего применения: игры или решение профессиональных задач;

*установить в систему требуемый API;

*проконтролировать настройку параметров драйвера и/или при­кладной программы, задействовав необходимые функции 3D-aK-:елерации;

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

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

Устройство и характеристики видеоадаптера

Первые ЗD-акселераторы выполнялись в виде самостоятельного устройства только для работы с трехмерной графикой, устанав­ливаемого в слот шины ввода/вывода и соединяемого с видео­адаптером специальным кабелем.

Современные видеоадаптеры содержат один мощный графи­ческий процессор, в состав которого входит ЗD-акселератор. В связи с этим понятие «ЗD-акселератор» означает не специализирован­ную плату, а универсальный видеоадаптер, в состав которого вхо­дит ускоритель трехмерной графики.

Современный видеоадаптер (видеокарта) включает следующие основные элементы :

Графический процессор;

Модули оперативной памяти;

RAMDAC - цифроаналоговый преобразователь, выполняю­щий преобразование цифровых сигналов ПК в сигналы, форми­рующие изображение на мониторе.

Интегральным показателем качества видеоадаптеров, сфера при­менения которых - в основном трехмерные игры, является час­тота смены кадров (frame per second - fps). В каждой трехмерной игре этот показатель будет различным.

Качество современного видеоадаптера можно считать удовлет­ворительным, если в игре Quake при разрешении 1600x1200 он обеспечивает 60 - 70 fps.

Другим показателем качества видеоадаптера является макси­мальное число обрабатываемых элементарных простых объектов (многоугольников, треугольников) в секунду. Эти значения для отдельных видеоадаптеров составляют 800-1200 млн/с.

Объем оперативной памяти видеоадаптеров достигает 128 Мбайт. Типы памяти, используемой в видеоадаптерах, аналогичны мо­дификациям обычной оперативной памяти. В недорогих моделях используется память SDRAM или ее более быстрая графическая модификация SGRAM со временем доступа 7 -8 не. Более совер­шенные модели оснащены памятью DDR SDRAM со временем доступа 5 -6 не.

Частота работы графического чипа и памяти видеоадаптера может быть одинаковой или разной. Например, базовая частота чипа самых популярных видеокарт 2004 г. составляла свыше 500 МГц, а частота памяти - более 1000 МГц.

Частота RAMDAC определяет качество видеоадаптера. Боль­шинство современных видеокарт имеют частоту RAMDAC в диа­пазоне 250 - 400 МГц.

Тип интерфейса с шиной ввода/вывода оказывает существенное влияние на быстродействие всей видеосистемы. Для эффективной работы с трехмерной графикой современные видеоадаптеры ком плектуются интерфейсом AGP. AGP4x - суперскоростной режим, обеспечивающий скорость обмена 1,06 Гбайт/с. На компьютерном рынке наиболее популярны видеокарты на чипсете собственной оригинальной разработки, предлагаемые фирмами ATI, Matrox и 3dfx, в то время как чипсеты фирмы Nvidia используются в составе видеокарт других производителей. Видео­карты ATI предпочтительнее в мультимедийных комплексах, про­изводства 3dfe - в игровых приложениях, а фирма Matrox специ­ализируется на двухмерной графике.

Для поддержки спецэффектов в игровых приложениях (анти-алиасинга, имитации тумана, пламени, ряби на водной глади) в процессор видеоадаптера все чаще встраивают специальный блок «трансформации и освещения» (Т&Т), который позволяет полу­чить высокое качество игрового изображения.

Для приема телевизионных сигналов и вывод их на монитор в плату видеоадаптера встраивают TV-тюнер. Встроенные TV-тюнеры не отличаются высоким качеством изображения, которое мо­жет воспроизводиться в небольшом окне Windows. TV-тюнеры, устанавливаемые в отдельный слот компьютера, обеспечивают пол­ноэкранный режим и высокое качество изображения, обеспечи­вая при этом выполнение дополнительных сервисных функций: телефонные переговоры через Internet, прослушивание радио, прием спутникового телевидения при наличии спутниковой ан­тенны.

Внешние TV-тюнеры, подключаемые через порт USB, обеспечивают воспроизведение телепередач в «оконном» режиме на экране монитора.