Очень часто встречаются различные заблуждения по поводу этих двух API .
Я попытался изложить в этой статье основные факты, которые следует знать как разработчикам, так и конечным пользователям.
Так как тема очень холиварная, я старался придерживаться максимально нейтрального тона.
Взгляд с высоты птичьего полёта
Оба API предоставляют доступ к функциям аппаратного ускорения 3D-графики.Распространённые заблуждения
OpenGL отстаёт от Direct3D, и вообще, судя по таким вялым изменениям в спецификации, наверное уже совсем мёртв.Собственно, причина такого заблуждения - это незнание о расширениях. Вообще говоря, OpenGL может и часто опережает (!) Direct3D в плане инноваций, т.к. производитель может добавить расширение к OpenGL, не дожидаясь никого, в то время как в Direct3D изменения может внести только Microsoft.
OpenGL - это для программ профессиональной графики, а Direct3D - это для игр.
Это заблуждение имеет историческую причину. OpenGL исходно разрабатывался как библиотека 3D графики, которая МОЖЕТ, но НЕ ОБЯЗАНА ускоряться аппаратно. Это также объясняет наличие некоторых функций, например рендеринг стерео-изображений, которые не нужны играм. Direct3D же разрабатывался гораздо позже, сразу с расчётом на ускорение на GPU. В момент появления многих пакетов профессиональной работы с графикой Direct3D просто не было.
Microsoft поставляет вместе с Windows драйверы без поддержки OpenGL. OpenGL будет рендерить без ускорения, или эмулироваться через DirectX. Так что, если нужна поддержка OpenGL под Windows, нужно ставить драйвер с сайта производителя. Причины для такого неприятия OpenGL, скорее всего, опять чисто политические.
Так что же делать, как жить?
Примечание: А вот эта часть носит весьма субъективный характер.Если Вы - разработчик, и решаете, какое API использовать, то задумайтесь над следующим:
За OpenGL - массовая кроссплатформенность, в частности, доступность всех новых функций и на Windows XP, где Direct3D 10/11 нет, и никогда не будет.
Против OpenGL - драйвера в Windows из коробки не имеют поддержки OpenGL, так что ставить их нужно с сайта производителя.
Если Вы - новичок в разработке 3D-приложений, и желаете освоить эту область, то я бы рекомендовал сделать так: сначала разобраться с Direct3D (причина тому проста - Microsoft предоставляет очень качественный SDK), а затем разобраться с OpenGL (это будет очень просто после Direct3D). К сожалению, такой вещи, как SDK, для OpenGL нет. Поэтому осваивать с нуля будет сложнее.
Вот вроде и всё. Успехов в разработке!
Всем привет. В этой статье (сразу говорю, что статья не для новичков) будет проведено сравнение двух интерфейсов, используемых для разработки графики. Они часто находят применение в компьютерных играх. Это OpenGL и DirectX . Статья раскроет их особенности, архитектуру и производительность. Сначала приступим к обзору OpenGL.
Заметная особенность библиотеки OpenGL – простота ее работы. У данной библиотеки есть ядро, которое управляет обработкой неких треугольников (их называют примитивами).
Процедурная модель лежит в основе передачи данных, а в работе вызываются функции. OpenGL имеет состояние, связанное со значениями переменных, которые и указывают какие параметры обработки должны работать в каждый момент времени. Например, определяется, нужно ли сейчас рисовать текстуру или нет. И в соответствии с текущим состоянием совершается обработка переданных примитивов. В итоге получается простой код и достаточно эффективный механизм работы OpenGL. Также не случаются проблемы с объектно-ориентированными технологиями, несмотря на то, что ядро OpenGL является процедурным.
Пришло время рассмотреть принципы работы второго интерфейса - DirectX . В корне он сильно отличается от OpenGL и имеет основу на модели COM. Многим знакомым с этой структурой станет понятно. А если кто не знаком с принципами COM, то нужно отметить пару моментов. Модель COM предполагает не простые вызовы функций, а определенные действия, которые связаны непосредственно с архитектурой библиотеки DirectX.
Рассмотрим плюсы и минусы данной архитектуры. Вызовы DirectX используются внутри кода, который не отличается легким пониманием. И причем, для того, чтобы нарисовать обычный треугольник, используется очень большой объем кода. Для упрощения работы с таким кодом компания Microsoft разработала DirectX Common Files. Это отдельная библиотека, позволяющая, частично скрыть повторяющиеся куски кода.
OpenGL и DirectX сильно отличаются своей архитектурой и принципами работы. Позже в развитие этих двух разработок стали заметны некоторые сближения. Это связано с движением в сторону эффективного использования «железа» и уменьшением времени на преобразование пользовательских команд в аппаратные. Всегда в работе таких вещей как OpenGL и DirectX, одним из главных вопросов является вопрос производительности. Хотя этот вопрос немного запутан. Постоянно проходят споры о том, кто быстрее — OpenGL или DirectX. А в итоге получается, что скорость у этих библиотек одинакова. Так получается из-за того, что большинство функций и в DirectX и в OpenGL работают с помощью аппаратных ускорителей.
При тестировании аппаратного обеспечения степень оптимизации кода этих двух библиотек различная, вот здесь можно четче заметить разницу скоростей работы. Также производительность может находиться в зависимости от качества работы драйверов оборудования. Все эти моменты планируются заранее и у более качественный игровых движков есть версии и для OpenGL и для DirectX. В итоге разработка усложняется и стоимость игр увеличивается, а ошибок может быть больше. Игровой рынок работает именно так.
Теперь рассмотрим какие еще различия существуют между OpenGL и DirectX. Разница замечается прежде всего в удобстве работы интерфейса, гибкости его функций, области его использования. Часто можно услышать мнение, что OpenGL, в отличии от DirectX9 не поддерживает пиксельные шейдеры. Это не так, хотя в описании OpenGL не указано о шейдерах. Скорость обработки и качество картинки не зависит от используемой библиотеки.
Изначально OpenGL планировался как библиотека, которая будет актуальна еще очень долгий срок. Но комитет, разрабатывающий данную библиотеку, ARB работает медленно и новые возможности в OpenGL появляются редко. Но с помощью специальных расширений OpenGL может вырасти из базовых механизмов, реализуя новые возможности для определенное видеокарты. Как только выходит новая видеокарта, поддерживающая конкретную полезную функцию, обычно в драйвер к видеокарте включают расширенный OpenGL с этой функцией. Для этого программистам нужно специальное разрешение и поэтому имеют место расширение, прошедшие одобрение ARB, причем их применение может быть возможным на видеоадаптерах разных производителей. Эти расширение возможно позже будут включены в новые версии OpenGL. Эта модель не очень удобна. Например, в DirectX, определенная версия либо поддерживает какую-либо конкретную функциональность, либо нет. Но чаще разработчики успевают включать все новые функции, реализованные разработчиками видеокарт. В общих чертах, в разрезе поддержки аппаратных функций OpenGL и DirectX аналогичны, разница в их поставке.
DirectX любим программистами, придерживающимися объектно-ориентированного программирования и модели COM. С помощью COM вносятся изменения в данную библиотеку без редактирования базового кода. А в OpenGL такого подхода нет, но это не такой уж сильный минус. Для написания небольшой программы на DirectX используется код, размеров в 200-800 строк, для OpenGL же для аналогичного решения достаточно 50 строк.
OpenGL очень хорошо подходит для визуализации различных результатов исследований в научных областях.
Ну и конечно же большим плюсом OpenGL можно отметить открытость стандарта. Любая организация в праве приобрести лицензию у SGI и начать разрабатывать свою версию OpenGL. DirectX же закрыт, и его разработкой может заниматься только Microsoft. Поэтому путь DirectX определяется более узким кругом специалистов.
Подводя итоги, можно отметить некоторые достоинства. DirectX подходит для профессиональных игр и их разработки, а также для Windows. В последнее время OpenGL практически не применяется в играх, для разработки их движков. Эта библиотека может найти свое место на мощных компьютерах, используемых для научных исследований, в образовательных мероприятиях и других областях, имеющие необходимость в переносе различных программ на различные платформы.
На этом пожалуй все, спасибо за внимание 🙂
На минувшей неделе был представлен API Vulkan, о широкой поддержке которого заявили AMD и NVIDIA. Новый графический интерфейс разрабатывал Khronos Group, консорциум, основанный в 2000 году. Khronos Group отвечает за разработку и поддержку открытых стандартов в сфере мультимедийных приложений на разных платформах и устройствах. Консорциум поддерживают AMD и NVIDIA, а также многие другие компании.
На минувшей неделе была ратифицирована финальная версия 1.0 API Vulkan. AMD и NVIDIA представили соответствующие бета-драйверы. AMD заранее выпустила бета-версию Radeon Software еще 14 февраля. NVIDIA представила драйвер GeForce 356.39, который тоже ориентирован на поддержку API Vulkan.
Подход API Vulkan очень похож на API Mantle. Суть заключается в том, чтобы разработчики получили более глубокий доступ к «железу», чтобы выжать из него максимум. Такой подход позволяет максимально избежать существующих «узких мест». С другой стороны, разработчики должны точно знать, что они делают – например, при работе с памятью. Интерфейс OpenGL не так популярен, как DirectX, но позволяет выжать больше.
Интерфейс API Vulkan в версии 1.0 поддерживается под Windows 7, Windows 8.1, Windows 10, Android и Linux. Разработчики игр пока что не объявили о поддержки в конкретных играх, но здесь стоит дождаться Games Developer Conference, которая будет проводиться с 14 по 18 марта в Сан-Франциско. Из игровых движков пока есть информация о Source 2, который уже поддерживает API Vulkan. Процесс отладки облегчается поддержкой Valve, LunarG и Codeplay.
The Talos Principle
Хорошо, но какая игра или движок поддерживают API Vulkan? Игра The Talos Principle разрабатывалась компанией Croteam, которая и в прошлом была известна поддержкой многих графических API. И в последней итерации игра The Talos Principle не стала исключением – она поддерживает DirectX 9, DirectX 11, OpenGL и теперь Vulkan. Для студии разработчиков Vulkan является пробным шаром, хотя API Vulkan доступен в версии 1.0, поддержка пока находится в бета-стадии. На добавление поддержки разработчики Croteam затратили порядка трех месяцев. Но универсальный характер API позволяет вскоре представить вариант Linux.
API Vulkan теоретически совместим с несколькими платформами – но пока что тесты и сравнения можно провести только под Windows, причем здесь имеются свои ограничения. Реализация пока остается на очень раннем этапе. Путь рендеринга DirectX 11 совершенствовался многие годы, поэтому потенциала для оптимизации здесь уже нет. Здесь ситуация больше зависит от разработчиков драйверов, а именно AMD и NVIDIA. Игра The Talos Principle стала первой с поддержкой Vulkan. Поэтому пока нет возможности сделать сравнительный тест для оценки хорошей или плохой реализации поддержки.
Новые технологии первое время реализуются в примерах, подготовленных производителями. В случае DirectX 12 акцент был выставлен на Draw Calls, тот же тест 3DMark DirectX 12 опирается только на измерение производительности Draw Calls, игры DirectX 12, подобные Star Wars, тоже пытаются задействовать подобную нагрузку. Но The Talos Principle не так сильно зависит от высокой скорости Draw Call, чтобы низкоуровневый API дал большую разницу.
Поддержка API Vulkan версии 1.0 находится на ранней стадии, то же самое касается драйверов AMD и NVIDIA. Оба драйвера, по сути, относятся к бета-версиям, именно так их рассматривают производители GPU. Здесь обычно нет новых улучшений производительности или поддержки новых технологий, так что мы получаем шаг назад. Но как только определенный уровень разработки будет достигнут, драйверы обоих разработчиков GPU получат поддержку Vulkan в финальной версии. Когда это произойдет – не совсем понятно. Но пока ключевые приложения не используют Vulkan и игры с поддержкой API находятся в состоянии бета-версии, так что разработчики GPU могут спокойно дорабатывать свои драйверы.
Для тестов мы взяли нашу тестовую систему для видеокарт. Драйверы видеокарт AMD и NVIDIA мы уже описали выше. В настройках мы выставили максимальный уровень графики, но при этом протестировали и низкие разрешения вплоть до 1.280 x 720 пикселей, чтобы увеличить производительность Draw Call.
Тест The Talos Principle - 1.280 x 720 пикселей
Тест The Talos Principle - 2.560 x 1.440 пикселей
Тест The Talos Principle - 3.840 x 2.160 пикселей
Как можно видеть по результатам, API Vulkan дает существенный прирост по сравнению с OpenGL. Но до производительности DirectX 11 новый API не дотягивает. Тому есть несколько причин. С одной стороны, разработка под Vulkan находится в ранней стадии. Это касается и самого API, и драйвера, и игры The Talos Principle. По сравнению с OpenGL новый интерфейс позволяет освободить часть ресурсов и избежать «узких мест». Но DirectX много лет совершенствовался до текущего уровня. В любом случае, потенциал у API Vulkan очень хороший.
Если погрузиться в детали, то визуальных отличий между API Vulkan и DirectX 11 мы не обнаружили. Так что путь рендеринга очень хорошо адаптирован. У текущей реализации The Talos Principle видеокарты с 2 Гбайт памяти получают падение производительности, вероятно, из-за не самой эффективной работы с памятью. Как и Mantle и DirectX 12, API Vulkan может обращаться к ресурсам памяти на более глубоком уровне – сей факт можно рассматривать как преимущество, но он может стать и недостатком, если разработчики не смогут эффективно использовать память.
Несколько разочаровала ошибка в текущем драйвере NVIDIA, из-за которой после каждого теста приходилось перезагружать систему. Без перезагрузки игра «вылетала». Хотя с драйвером AMD мы не обнаруживали подобной ошибки.
Нынешняя реализация API Vulkan кажется обещающей. Пока что для игр на настольных ПК она будет не такой актуальной, поскольку рынок DirectX 11 и 12 очень велик, и по сравнению с тем же DirectX 12 затраты на реализацию могут быть слишком велики, а отдача слишком мала. Но если игры необходимо запускать на разных платформах с разными аппаратными требованиями, Vulkan может сыграть важную роль. В любом случае, следует дождаться реакции со стороны разработчиков игр, иначе мы получаем проблему курицы и яйца, из которой сложно выйти.
Учитывая сегодняшнее доминирование DirectX, мы невольно забываем, что 10 лет назад шла жёсткая война между Microsoft и Silicon Graphics в области 3D API. Две компании пытались завоевать доверие разработчиков, Microsoft использовала свою мощную финансовую подпитку, а SGI опиралась на опыт и репутацию в области 3D реального времени. В этой современной битве "Давид против Голиафа", малыш получил на свою сторону одного из самых известных игровых разработчиков - Джона Кармака (John Carmack). Частично это произошло из-за успеха движка Quake; надёжная поддержка OpenGL стала важным фактором, чтобы заставить производителей GPU выпускать полный комплект драйверов. Фактически, это дало 3dfx одно из ранних преимуществ и отбросило ATI в аутсайдеры, пока компания решала проблемы с поддержкой OpenGL.
Между тем Microsoft создавала свой API "с нуля", развитие было постепенным. Несколько лет возможности Direct3D были далеки до желаемого уровня, многие программисты находили API более запутанным и непонятным, чем OpenGL. Но никто не может обвинить Microsoft в том, что эта компания легко сдаётся. С каждой новой версией Direct3D, API постепенно догонял OpenGL. Инженеры в Редмонде работали, не покладая рук, чтобы обеспечить производительность до уровня конкурирующего API.
Поворотный момент настал с выпуском DirectX 8, который появился в 2001 году. Впервые Microsoft API предоставил больше возможностей, нежели просто копировал API SGI. Были введены собственные инновации, подобно поддержке вершинных и пиксельных шейдеров. SGI, чей главный источник прибыли заключается в продаже дорогих рабочих станций 3D, оказалась в неудачном положении, поскольку компания не смогла предсказать взрывной рост видеокарт для геймеров, который позволил ATI и nVidia проникнуть и на профессиональный рынок с настольно низкими ценами (из-за экономии масштаба), что SGI просто не могла конкурировать. Разработка OpenGL была также осложнена горячими спорами между сторонниками API. Поскольку ARB (группа, отвечающая за принятие новых версий API) включала много разных и часто конкурирующих компаний, было сложно прийти к соглашению по поводу функций, которые нужно добавить к API. Вместо этого каждая компания защищала собственные интересы. Напротив, Microsoft тесно работала с ATI и nVidia, используя их вес для принятия решений, если возникали какие-то противоречия.
С выпуском DirectX 9 Microsoft удалось одержать решающую победу и впечатлить разработчиков. Только Джон Кармак и те разработчики, которым была важна универсальность, остались привержены OpenGL. Но их авторитет пошатнулся. Впрочем, не будем забывать, что фортуна может и отворачиваться. Так, в конце концов, случилось с web-браузерами. Пусть даже компания преодолела трудный путь, заняв, фактически, монопольное положение, почивать на лаврах не стоит, поскольку конкуренты могут буквально возникнуть из ниоткуда. И когда группа Khronos взялась за разработку OpenGL два года назад, у многих затеплилась надежда, и к нынешней конференции SIGGRAPH был проявлен немалый интерес.
В августе Khronos анонсировала OpenGL 3, серьёзное обновление API, которое призвано догнать Microsoft, а программный гигант, в свою очередь, запланировал DirectX 11 API следующего поколения. Но всё получилось несколько иначе.
Чтобы полностью понять противоречия, окружающие объявление OpenGL 3, нам нужно вернуться на несколько лет назад, в 2002 год. Как мы уже сказали выше, примерно в то же время OpenGL стал терять почву под ногами. До того момента DirectX просто копировал возможности OpenGL. На этот же раз Microsoft удалось обогнать API SGI. С выпуском DirectX 9, Microsoft добавила поддержку высокоуровневого языка шейдеров HLSL, а у OpenGL не было ничего сравнимого. Следует напомнить, что корни OpenGL лежат в IRIS GL, API, которое было изначально создано SGI для поддержки всех функций "железа" компании. Долгое время ATI и nVidia просто следовали модели рендеринга SGI, то есть OpenGL очень даже хорошо подходил видеокартам производителей с самого их рождения. Но с появлением шейдеров новые GPU отклонились от традиционного конвейера рендеринга.
 |
В то время одна компания осознавала важность быстрого эволюционного развития OpenGL, если это API надеется работать на современных GPU: мы имеем в виду 3DLabs. Это неудивительно, поскольку 3DLabs забросила игровые карты после неудачи Permedia 2, сконцентрировавшись на профессиональном рынке, где OpenGL является стандартом. 3DLabs представила план из нескольких пунктов, который позволял OpenGL перейти в новую эру. Первый пункт: добавление высокоуровневого языка шейдеров GLSL. Затем планировался полный пересмотр API. Многие функции API уже потеряли смысл на современных 3D-видеокартах, но из-за обратной совместимости они требовали разработчиков GPU поддерживать их, по крайней мере, на программном уровне. Это не только приводило к тому, что писать драйверы становилось сложнее, а также повышало вероятность возникновения ошибок, но и наследственные функции делали API довольно запутанным для программистов-новичков.
Поэтому 3DLabs хотела предложить набор функций, который гарантирует эффективное выполнение на GPU, а также устранит устаревшие или избыточные опции. Этот набор функций был назван OpenGL 2.0 Pure и предназначался для разработчиков новых приложений. Для обратной совместимости к Open GL 2.0 был добавлен полный набор расширений OpenGL 1.x.
К сожалению, после бесконечных дискуссий в рамках ARB, этот план был отклонён. И когда OpenGL 2.0 стал, наконец, доступен, всё что в нём было сделано - всего лишь добавлена поддержка GLSL в API. Все другие предложения 3DLabs оказались в мусорной корзине, в результате OpenGL продолжал отставать от Microsoft API.
 |
Нужны перемены
Другой пример демонстрирует то, что ARB не способна принимать быстрые и эффективные решения. Долгое время OpenGL опирался для рендеринга текстур на технику под названием pbuffers. Все программисты соглашались, что эта техника была сложна в понимании, трудна в использовании и давала плохую производительность. Поэтому ATI предложила расширение для её замены - uber-buffers. Это расширение оказалось весьма амбициозным. Кроме рендеринга на текстуру, ATI сделала возможным рендеринг на массив вершин, не считая других расширенных возможностей. Возможно, расширение было даже слишком амбициозными, на его описание и определение ушло слишком много времени, программисты долго ждать не хотели, поэтому nVidia и 3DLabs, в конце концов, предложили свой вариант, который, по крайней мере, позволял выполнять эффективный рендеринг на текстуру, без глобального подхода у решения ATI. Ушло несколько лет, прежде чем стало возможно увидеть результат всех этих усилий - в виде расширения под названием framebuffer_object, которое обеспечивает базовые функции, появившиеся ещё в DirectX 9!
Так, в 2005 году, OpenGL смог догнать Microsoft API, выпущенный тремя годами раньше. Все основные игроки (ATI, nVidia, 3Dlabs и разработчики ПО) соглашались, что дальше так продолжаться не может, либо OpenGL будет постепенно сходить со сцены, и рано или поздно будет предан забвению. В данном контексте ARB передал бразды правления Khronos в 2006 году, и за будущее OpenGL стала отвечать эта группа. ATI и nVidia поклялись, что они станут выше собственных амбиций и конкуренции и будут эффективно сотрудничать, чтобы OpenGL стал, наконец, достоин XXI века. Разработчики тоже были полны энтузиазма, поскольку группа Khronos очень эффективно показала себя в работе над OpenGL ES, 3D API для мобильных устройств.
Очень быстро группа Khronos начала приоткрывать завесу тайны над будущим OpenGL. Опять же, план заключался в переработке API в два этапа. Первая версия, Longs Peak, должна обеспечить уровень функциональности R300/NV30 на равных с Shader Model 2, а также дать новую, более гибкую модель программирования. Получилось нечто подобное OpenGL 2.0 Pure, который 3DLabs предложила несколько лет раньше, поскольку группа Khronos планировала убрать устаревшие функции API и сфокусироваться на небольшом числе современных функций. Их набор был назван OpenGL Lean and Mean. Вторая версия, с кодовым названием Mount Evans, заключалась в обновлении API, попутно исправляя все ошибки, которые были выявлены, до уровня функций R600/G80 (Shader Model 4). План разработок был очень жёсткий, в нём говорилось о появлении Mount Evans меньше, чем через шесть месяцев после Longs Peak. Но участники группы Khronos были уверены в своих силах.
Со времён ARB произошло ещё одно изменение: группа Khronos решила работать более открыто. Вся новая информация публиковалась на сайте OpenGL, рассказывая разработчикам о новом API, чтобы они смогли заранее получить впечатления о его работе. Всё шло достаточно хорошо до конца 2007 года. Хотя финальная спецификация Longs Peak ожидалась в сентябре, группа Khronos объявила, что из-за проблем она будет отложена - без предоставления каких-либо деталей. О решении работать более открыто, принятом несколько месяцев назад, было забыто, и группа Khronos продолжила свою работу в информационном вакууме. Никаких новостей не было - фактически, о прогрессе в области нового API не появлялось никакой информации.
Разоблачение
 |
Про OpenGL 3 ничего не было слышно до августа 2008, когда проводилась конференция SIGGRAPH. Многие ожидали приятного сюрприза, однако новости Khronos оказались для приверженцев OpenGL разочарованием. API не только опоздал примерно на год, но и кроме всего прочего, большинство новых аспектов Longs Peak было полностью забыто. После фиаско OpenGL 2.0, который на самом деле стал OpenGL 1.6 с другим названием, версия OpenGL 3.0 начала выглядеть не больше, чем версия 2.2. Неприятный сюрприз, вместе с отсутствием новостей в течение нескольких месяцев, привели к весьма агрессивной реакции на действия группы Khronos повсюду на форумах. Поскольку реагировать было как-то надо, Khronos ответила на официальном форуме OpenGL через Бартольда Лихтенберта (Barthold Lichtenbelt) из nVidia. Его детальный ответ , по крайней мере, пролил некоторый свет на то, что происходило в группе. Мы узнали, например, что по некоторым пунктам реализации плана решение так и не было принято вовремя, и вместе с тем, многие считали, что нужно срочно добавить поддержку OpenGL для последних GPU. Поэтому план был изменён, чтобы расширить OpenGL 2 и добавить функции Direct3D 10.
Даже с учётом упомянутых аргументов, группу Khronos можно по-прежнему критиковать за то, что она не смогла вовремя оповестить о кризисной ситуации, предпочитая её замалчивать. Поскольку то же самое случилось шесть лет назад с OpenGL 2.0, то оптимизма на будущее это не внушает. После двух обещаний переписать API - оба из которых не были выполнены - как можно верить в будущее OpenGL? Наконец, комментарий Джона Кармака на последней QuakeCon не приносит облегчения. Когда Джона спросили о состоянии OpenGL 3, он ответил ещё менее политкорректно, чем Лихтенберт.
По словам Кармака, провал OpenGL 3, в отличие от распространённого мнения, связан с провалом некоторых разработчиков САПР/CAD, которые не очень хорошо отнеслись к Longs Peak. Они побоялись проблем с совместимостью и своими приложениями из-за исчезновения некоторых старых функций. Эта версия была тактично подтверждена Лихтенбертом: "Во время стадии дизайна Longs Peak, мы пришли к разногласиям по тем функциям, которые будут убраны из API... Разногласия возникли из-за разных потребностей рынков... Мы обнаружили, что не можем предложить один API для всех..."
Итак, в итоге OpenGL 3 стал не более чем очередным обновлением. API на самом деле не поменялось. Khronos просто назвала некоторые функции не рекомендуемыми, а также привела контекст, в рамках которого функции приведут к ошибкам. Это намного меньше того, что было обещано (разработчикам драйверов всё равно придётся поддерживать эти функции), но всё же является шагом вперёд, поскольку разработчики могут приготовиться к будущим версиям, которые могут, наконец, дать настоящий режим Lean and Mean. OpenGL 3 также вводит понятие профилей. На данный момент профиль только один, но по плану будут созданы профили для игр и для САПР, например, причём каждый профиль будет поддерживать разные массивы функций.
Не считая этого, набор функций, предлагаемый OpenGL 3, очень похож на предложение Direct3D 10, за исключением Geometry Shaders и Geometry Instancing, которые добавлены в API в качестве расширений. Но поддерживаются и некоторые функции Direct3D 10.1, подобно независимым режимам смешения (blending) для MRT.
С выпуском Direct3D 10 Microsoft удалось сделать наиболее развёрнутую версию своего API с момента создания. Конечно, все эти годы совместимости существенно ограничили возможности эволюции API, поэтому целью было и создание основы для будущих разработок. Конечно, новый API получил смешанные отзывы от геймеров и разработчиков.
Microsoft есть, за что порицать. После такой хвальбы своего API ещё за несколько лет до его появления, DirectX 10 привёл к разочарованиям, когда геймеры поняли, что на практике он ничего особо не меняет. Добавьте к этому и тот факт, что новый API был написан исключительно для Vista, поэтому вполне понятен негативный настрой к тому, что преподносилось как маленькая революция. Что касается разработчиков, всё оказалось сложнее. Связав Direct3D 10 и Vista, Microsoft существенно ограничила число парка компьютеров, который работает с новым API.
Более того - и это ни для кого не секрет - в последние годы ПК потерял свою роль в качестве игровой платформы, с выходом приставок нового поколения, на которые перешли несколько крупных разработчиков с ПК. id Software, Epic и Lionhead теперь работают на многоплатформенным проектами, если не разрабатывают игры исключительно для приставок. Поскольку обе HD-приставки на рынке используют GPU DirectX 9, у разработчиков есть все стимулы, чтобы придерживаться предыдущего API Microsoft.
Почему мы говорим о Direct3D 11 уже сейчас? Во-первых, потому что Microsoft, наконец, подняла завесу тайны над собственным API. Во-вторых, поскольку перед нами всё же событие, которое позволяет получить представление о том, чего ожидать от "железа" в следующем году. Более того, есть все шансы, что Direct3D 11 станет более важной страницей в истории этого API, чем версия 10. Если Direct3D 10 был полостью переработанной версией, со всеми связанными рисками, у Microsoft есть достаточный промежуток между версиями 10 и 11, чтобы исправить все проблемы, связанные с первой серьёзной переработкой API. Поэтому Direct3D 11 можно назвать серьёзным обновлением, хотя и нельзя назвать революционным. Новый API построен на тех же принципах, что и Direct3D 10, он совместим с предыдущими версиями и с "железом" предыдущего поколения. Наконец, API будет доступен не только на Windows 7, но и под Vista. Microsoft исправила самые крупные проблемы десятой версии, а среди разработчиков ходят неофициальные слухи, что они пропустят Direct3D 10 и перейдут сразу на версию 11 в будущих играх.
В этом есть смысл по нескольким причинам. Обычно стадия разработки игры занимает от двух до четырёх лет. Поэтому к тому времени, когда разрабатываемая сегодня игра выйдет, Direct3D 11 уже утвердится на парке ПК, поскольку API будет работать на всех компьютерах с Windows 7, а также и на подавляющем большинстве ПК под Vista. Кроме того, очень вероятно, что независимо от даты выхода, грядущие приставки будут использовать GPU, совместимые с Direct3D 11 (или что-то подобное, как Xenos в Xbox 360, который является надстройкой над DirectX 9). Следовательно, нацеливание на подобный набор функций позволит разработчиком захватить рынок приставок следующего поколения. Но мы здесь не для того, чтобы изучать рынок. Что даёт новый API с технической точки зрения?
Многопоточный рендеринг
Многопоточный рендеринг? Но разве мы уже не используем многоядерные CPU на протяжении нескольких лет, и разработчики не научились с ними работать? Что же может быть нового в многопоточных движках рендеринга Direct3D 11? Некоторые из вас будут удивлены, но современные движки по-прежнему используют только один поток для рендеринга. Другие потоки используются для звука, распаковки ресурсов, физики и т.д. Но рендеринг серьёзно нагружает CPU, так почему бы его не разнести на несколько потоков? На то есть несколько причин, некоторые из них связаны с тем, как работает GPU, а другие - с 3D API. Поэтому Microsoft решила устранить программные проблемы, а также помочь решить аппаратные.
 |
На первый взгляд, распараллеливание процесса рендеринга выглядит привлекательно, но если вы присмотритесь внимательнее, то поймёте, что GPU здесь только один (даже если несколько GPU соединяются через SLI или CrossFire, их целью является создание иллюзии, что работает один, виртуальный GPU), поэтому и буфер команд только один. Когда один ресурс используется несколькими потоками, технология взаимного исключения (mutual exclusion, mutex) предотвращает одновременную запись команд от нескольких потоков, чтобы они не мешали друг другу. Это означает, что все преимущества использования нескольких потоков устраняются одной критичной секцией, которая делает код последовательным. Никакой API не в силах решить эту проблему - она унаследована из способа связи CPU и GPU. Но Microsoft предлагает API, которое может попытаться её обойти. В Direct3D 11 появились вторичные буферы для команд, которые можно сохранить и использовать позднее.
 |
Нажмите на картинку для увеличения.
Поэтому у каждого потока есть отложенный контекст, где записаны команды в списке (Display List), который можно вставить в главный поток обработки. Вполне понятно, когда список запрашивается основным потоком (команда "Execute" на слайде "Multi-threaded Submission" ниже), нужно убедиться, что поток закончил его заполнять. Поэтому синхронизация по-прежнему есть, но модель исполнения, по крайней мере, позволяет сделать некоторую работу рендеринга параллельной, хотя, конечно, получающееся ускорение нельзя признать идеальным.
Ещё одна проблема предыдущих версий Direct3D связана с созданием ресурсов - например, текстур. В текущих версиях API (9 и 10), ресурсы приходилось создавать в потоке рендеринга. Разработчики обошли эту проблему, создав поток, который считывает и распаковывает текстуры с диска, после чего заполняет ресурс (объект Direct3D), который создан в основном потоке.
Но, как можно видеть, большая часть рабочей нагрузки по-прежнему остаётся в основном потоке, который и так перегружен. Это не даёт оптимального баланса, который нужен для быстрого выполнения. Поэтому Microsoft добавила новый интерфейс в Direct3D 11: программист может создавать один объект "Device" на поток, который можно использовать для загрузки ресурсов. Синхронизация функций объекта "Device" производится более тонко, чем в Direct3D 10, и намного более экономично по ресурсам CPU.
 |
Нажмите на картинку для увеличения.
Тесселяция
Основной новой функцией Direct3D 10 стало появление геометрических шейдеров, которые, наконец, позволили создавать или уничтожать вершины силами GPU. Но роль данного блока не всегда понимают правильно. Он не только обеспечивает массированную поддержку геометрии, но и лучше подходит для реализации более гибких точечных спрайтов (Point Sprites), Fur Shading, или для расчётов силуэта объекта для алгоритмов объёмных теней. Ничего нет лучше, чем специальный блок для выполнения тесселяции. Изначально он планировался для Direct3D 10 (что объясняет присутствие блока в линейке Radeon HD), но, похоже, Microsoft, ATI и nVidia не смогли достичь соглашения вовремя, поэтому блок исчез из спецификаций, вернувшись только с Direct3D 11. Поэтому тесселяция является новой крупной функцией Direct3D 11 - или, по крайней мере, той, которую проще продавать не специалистам.
 |
Нажмите на картинку для увеличения.
В отличие от других ступеней конвейера, эти ступени работают не с треугольниками в качестве примитивов, а с патчами. Hull Shader берёт контрольные точки для патча на входе, после чего определяет некоторые параметры Tesselator, такие, например, как TessFactor, который показывает уровень качестве тесселяцции. Tesselator - блок с фиксированными функциями, поэтому программист не может влиять на то, как производится расчёт тесселяции. Блок отсылает полученные точки в Domain Shader, который может применять к ним операции. Позвольте привести пример, который поможет всё лучше понять. Возьмём пример, который поднимался с каждым поколением со времён Matrox Parhelia - карты смещения (Displacement Mapping).
 |
Нажмите на картинку для увеличения.
В качестве входа для вершинного шейдера у нас есть контрольные точки патча. Программист может изменять их, как ему хочется, поскольку их не так и много. Чтобы упростить, мы взяли очень грубую версию финальной сетки. Трансформированные точки затем передаются в Hull Shader, который определяет, сколько раз требуется делить каждую плоскость патча (например, как функцию размера патча в пикселях дисплея). Tesselator выполняет тесселяцию. То есть создаёт геометрию, которая пересылается в Domain Shader. Блок перемещает точки, созданные для соответствующего пространства (точки, выходящие из Tesselator, находятся в пространстве патча), создавая классические вершины, которые он может смещать как функцию текстуры, то есть производить Displacement Mapping.
Потенциал огромен. Благодаря тесселяции, можно обойтись без карты нормалей и реализовывать уровень детализации напрямую на GPU, позволяя использовать очень детализованные модели (несколько миллионов полигонов вместо 10 000 или около этого числа в современных играх) - по крайней мере, в теории. На практике тесселяция приводит к появлению некоторых проблем, которые не позволяют этой технике развернуться в полную силу. Смогут ли Direct3D 11 и совместимые карты обойти "подводные камни" и представить функциональную версию? Пока ещё слишком рано что-то утверждать, но, в любом случае, убедить удалось не всех, та же id Software работает над решением той же проблемы геометрии через полностью иной подход, основанный на ray casting с вокселями.
Вычислительные шейдеры
Как мы упоминали в нашей статье о CUDA , Microsoft не желает упустить из рук рынок GPGPU, поэтому компания создала собственный язык, чтобы GPU работал над другими задачами, а не только отрисовывал красивые картинки. Отгадайте что? Выбранная Microsoft модель, подобно OpenCL, очень напоминает CUDA, подтверждая перспективность взгляда nVidia. Преимущество над решением nVidia лежит в универсальности - вычислительные шейдеры (Compute Shader) будут работать на GPU nVidia и ATI, на будущем Intel Larrabee, а также обладать лучшей интеграцией с Direct3D, пусть даже у CUDA уже образовалась определённая поддержка. Но мы не будем уделять этой теме много времени, пусть она этого и достойна. Вместо этого мы планируем через несколько месяцев представить отдельную статью, рассказывающую о OpenCL и Compute Shaders.
Улучшенное сжатие текстур
Впервые появившись в DirectX 6 десять лет назад, функция сжатия текстур DXTC быстро распространилась на рынке GPU, её очень активно используют разработчики. Конечно, технология, разработанная S3 Graphics, была эффективная, а накладные аппаратные расходы были скромными, что, без сомнения, объясняет успех. Но теперь нужды изменились. DXTC не разрабатывалась для сжатия карт нормалей и не учитывала HDR-рендеринг. Поэтому цель Direct3D была двойная: разрешить сжатие HDR-текстур и ограничить "блочность" традиционных режимов DXTC. Для этого Microsoft добавила два новых режима: BC6 для HDR-текстур и BC7 для улучшения качества сжатия изображений LDR.
Нажмите на картинку для увеличения.
Shader Model 5
С представлением Shader Model 5, Microsoft старается переложить несколько принципов объектно-ориентированного программирования на язык шейдеров HLSL. В отличие от предыдущих версий, которые представляли новые возможности (динамическое ветвление/Dynamic Branching, поддержка целых чисел и т.д.), в данном случае цель кроется в облегчении работы программистов, решая распространённую проблему в современных игровых движках: рост числа шейдеров из-за большого числа перестановок. Возьмём конкретный пример: представьте, что движок работает с двумя типами материалов, пластиком и металлом, а также двумя типами освещения: световое пятно (spot) и рассеянный свет (omni). Чтобы предусмотреть все случаи, программисту нужно написать четыре шейдера:
| renderPlasticSpot () : // rendering plastic using spot light: |
| renderPlasticOmni () : // rendering plastic using omni light: |
| renderMetalSpot() : //rendering metal using spot light ... |
| renderMetalOmni() : //rendering metal using omni light: |
Пример очень простой, поскольку здесь всего два материала и два типа освещения, но на практике их может быть несколько десятков. Если продолжать таким же образом, то ситуация может быстро выйти из-под контроля. Мы получаем огромное количество дублированного кода, и если обнаруживается какая-либо ошибка, её нужно исправлять во всех шейдерах. Чтобы решить эту проблему, программисты используют так называемый uber-shader, который соединяет вместе все комбинации.
Light и Material - это интерфейсы, а код содержится в производных классах OmniLight и SpotLight, PlasticMaterial и MetalMaterial. Поэтому код полностью размещён в одном месте, правки вносить проще. В то же время и удобство чтения не страдает благодаря организации кода, напоминающей принцип виртуальных функций в объектно-ориентированных языках. Эта функция наверняка будет с одобрением встречена программистами, хотя геймерам она вряд ли что-либо даст.
Прочее
Как вы понимаете, мы только вкратце рассмотрели новые функции Direct3D 11, да и Microsoft ещё не опубликовала всех деталей. Среди тем, о которых мы не упомянули, есть увеличение максимального размера текстуры с 4K x 4K до 16K x 16K, а также возможность ограничивать число mip-карт, загруженных в VRAM. Есть также возможность изменения значения глубины пикселя, не отключая такие функции, как раннюю проверку Z, поддержка переменных с плавающей запятой двойной точности, разброс записи в память (scatter memory write) и т.д.
Заключение
Мы многого ждали от OpenGL 3, и, как вы можете судить по статье, мы были разочарованы: как самим API (из которого исчезли обещанные функции), так и его разработкой (годовая задержка и отсутствие информации со стороны группы Khronos). С новой версией OpenGL едва смог догнать Direct3D 10, в то же время Microsoft опубликовала первые детали об 11 версии своего API.
Ничего революционного от Microsoft ожидать не стоит, но, в отличие от OpenGL, Direct3D уже пережил полную перестройку своей архитектуры два года назад. Конечно, далеко не всё было гладко, но сегодня Microsoft может пожинать плоды усилий по перестройке своего API на новую мощную основу.
Вне всяких сомнений, Редмонд смотрит в будущее, а насчёт OpenGL создаётся впечатление, что Khronos довольствуется поддержкой текущего поколения GPU. Будем надеяться, что мы ошибаемся, и эволюция OpenGL 3 пойдёт намного быстрее, поскольку это единственное API, доступное для мультиплатформенной разработки. Но слишком большое число накладок поколебали нашу веру в развитие этого API.
OpenGL (= Open Graphics Library) - это программный интерфейс для управления графическим процессором состоит примерно из 250 команд, зашитых в двух библиотеках oglcore и oglutilities . Разрабатывается с 1990 года компанией SGI (Silicon Graphics Inc.). Цель - создание мульти-платформенного графического интерфейса для разработчиков графических карт и программного обеспечения.
DirectX
- это общее название для коллекции из
10 Windows-библиотек (см. таблицу ниже) для низкоуровнего программирования "железа" от различных производителей. Разрабатывается компанией
Microsoft с 1994 (первое название "Games SDK") с постоянно меняющимся функционалом, разделенным на версии (текущая версия 11). Цель и главная задача - позиционировать Windows, как платформу для Multimedia. Почти для всех Graphiс-, Sound-, Radio-, Video-, TV- hardware разработаны DirectX-Драйвера.
До версии DirectX 9.0 (включительно) DirectX-библиотеки принципиально отличались от других Windows-APIs (Application Programming Interfaces). Они не гарантировали исполнение необходимых запросов
. Каждый программист должен самостоятельно контролировать - может ли, программируемое через DirectX, железо выполнить нужную операцию, и если да, то в каком объеме и форме. На практике, многие программисты доверяют
DirectX-Драйверам с надеждой на то, что Драйвер целевого железа настолько хорош, что не просто отклонит некорректные для данного железа запросы, а попытается с помощью аварийной системы их обработать корректно. (см. ниже описание HEL).
Со временем появилось несколько подходов к программированию DirectX:
1) C++ и
DirectX Software Development Kit = DXSDK
;
2)
Managed DirectX
для C# - примерно также быстр в исполнении, но проще в программировании, чем 1) и является частью DXSDK;
3)
XNA
для C# - это последователь 2) для новых Windows-PC, XBox, Windows-Phone;
4)
Windows Presentation Foundation = WPF
вместе с XAML и C# → DirectX11 упаковано в одну огромную библиотеку классов.
Managed DirectX
быстро стал популярным
, так как предлагал простой и элегантный доступ к DirectX с высокой скоростью исполнения, и в период с 2002 по 2007 стал самой популярной оболочкой для разработки PC-игр под WindowsXP.
В 2007году Microsoft объявил о развитии Managed DirectX разработав два новых DirectX-APIs:
1)
XNA
, который в отличии Managed DirectX значительно упрощал доступ к DirectX для разработок на PC- , XBox- и WindowsPhone- платформах;
2)
WPF
, с целью полной и цельной интеграции DirectX во все программные оболочки и интернет-страницы.
| Свойство | OpenGL | DirectX |
| Объектно-ориентирован | нет | да |
| Библиотеки классов | QT | Managed DX, XNA, WPF |
| Поддержка Audio/Video/Game Input Устройств | нет | да |
| Поддержка операционных систем | многие | только Windows (на PC, Xbox, Windows Phone) |
| Наличие качественных драйверов | Дорогие GPU | почти на все видео-карты |
| Качество драйверов | часто среднее или плохое | часто лучше, чем OpenGL-Драйвер |
| используется | Универы, Лабы, CAD | Игровая индустрия |
| Новые версии | каждые 5 лет (в промежутках только "Extensions") | каждые 15 месяцев |
| Собственность | Silicon Graphics Inc. | Microsoft |
OpenGL Libs и DirectX Namespaces
OpenGL состоит из двух библиотек (DLL), которые исключительно заточены на Графику.
Microsoft под именем DirectX собрал все, что в рамках операционной системы обращается напрямую к железу. В Managed DirectX эти библиотеки организованы в форме Namespaces. Только первые четыре из этих Namesspaces занимаются Графикой.
| OpenGL lib | DirectX |
| oglcore | Microsoft.DirectX, Microsoft.DirectX.DirectDraw, Microsoft.DirectX.Direct3D |
| oglutilities | Microsoft.DirectX.Direct3DX |
| .NET Namespace | API = Application Programming Interface |
| Microsoft.DirectX | общие базовые функции |
| Microsoft.DirectX.DirectDraw | подмножество из Direct3D-lib: basic 2D functions, bitmaps, window management |
| Microsoft.DirectX.Direct3D | API for 3D graphics: wireframes, textures, light, Vertex and Pixel Shaders |
| Microsoft.DirectX.Direct3DX | 3D utilities library, Mesh class and scene graph |
| Microsoft.DirectX.DirectPlay | network support for multiplayer games, host administration for DirectPlay sessions |
| Microsoft.DirectX.DirectSound | contains DirectMusic, API for real time multichannel mixer, 3D sound |
| Microsoft.DirectX.DirectInput | API for keyboard, mouse, joystick, trackball, touchpad, gamepad, wheel, force feedback |
| Microsoft.DirectX.AudioVideoPlayback | API for simple sound and video |
| Microsoft.DirectX.Diagnostics | system diagnostics API |
| Microsoft.DirectX.Security | system security API |
OpenGL & Direct3D Pipeline
Графический чип современной графической карты содержит множество графических процессоров в форме так называемых каскадных пайплайнов (Pipeline). Первая половина этих процессоров занята работой с векторной графикой, вторая с растровой графикой. Цепочки команд в OpenGL и Direct3D отражают принцип цепочек процессоров графического чипа. Следовательно набор команд OpenGL и Direct3D направлены примерно поровну на 3D-Векторную и Растровую графику. Таким образом, фундаментальное отличие между Векторной и Растровой Графикой нейтрализуется и скрывается, чтобы облегчить решение проблемы Векторно-Растрового перехода. Также скрывается проблема разделения работы между CPU и GPU, Что еще сложнее учитывая разнообразие возможных вариантов.
Таким образом, многие новички поначалу иллюзорно считают, что понимание работы "железа" не так уж необходимо.
Схема 3D-Pipeline
в OpenGL & Direct3D повторяет архитектуру GPU:
В DirectX есть возможность отключить всю Векторную часть через флаг CreateFlags.SoftwareVertexProcessing. Если в компьютере нет полноценного или вообще никакого GPU, то Pipeline будет симулироваться внутри OpenGL/DirectX, используя для всех расчётов CPU. В этом случае данные термины - Vertex Shader, T&L Engine, HSSL/Cg - не имеют никакого смысла и лучше говорить о CPU-Графике - HEL und HAL.
Vertex Shader
= каскад последовательно включенных микропроцессоров внутри GPU. Современные GPU содержат до 8 таких каскадов параллельно: программа, написанная на
HLSL
или
для Vertex Shader, также называется Vertex Shader.
Задача Vertex Shader
: преобразование 3D-треугольников (в мировых координатах) в 2D-треугольники (в экранных координатах).
Процессы в Vertex Shader
: Tesselation (триангуляция), координатная трансформация, 3D-Scroll+Zoom+Rotation, Clipping, Back Face Culling.
T&L Engine
- Transform & Light Engine - Fixed Vector Pipeline - наименование от одного до 8 параллельных Vertex Shader, которые программируются через заранее прошитые алгоритмы (Firmware), не дающиие большой свободы, но при этом значительно более быстрые. Управление этими Firmware осуществляется из вне, через:
a) флаги состояний, Пример:
device.Lights.Enabled = true;
и
b) 3x3-матрицы, Пример:
device.Transform.View = Matrix.LookAtLH(new Vector3(0f, 0f,-4f),
new Vector3(0f, 0f, 0f),
new Vector3(0f, 1f, 0f)); .
Clipping
= обрезка линий и конвексных Полигонов по границе экрана через алгоритм Коена-Сазерленда.
Back Face Culling
: примерно 50% треугольников обращены к наблюдателю тыльной стороной - если эти полигоны выбросить из рассчетов, то это ускорит растровые операции примерно в двое.
Pixel-Shader
= Rasterizer = включенный после Vertex-Shader специальный процессор графического чипа, специализирующийся на растровой графике = текстурирование и отрисовка (рендер) отдельного Пиксела, программируется через
HLSL
или , в графическом чипе содержится до 32-х параллельных Pixel-Shader.
Texture
= деформация растрового прямоугольника так, что он умещается в заданный Полигон.
BitBlitter
= сокращение от Bit Block Transfer = добавление растеризованных Шрифтов, линий, четырехугольников, эллипсов и т.д.
Z-Test
= Depth Test = Удаление скрытых Пикселей.
Alpha & Color Blending
= наложение масок прозрачности.
Fog
= добавление тумана в зависимости от расстояния между наблюдателем и объектом.
Dithering
= сглаживание цветов.
HEL и HAL
При установке Драйвера Графических карт, звуковых карт, джойстиков и т.д. определятся в операционной системе в форме Device Driver Interface DDI. С помощью определенного DDIs каждая DirectX-Библиотека при старте инициализирует один Hardware Emulation Layer HEL и один Hardware Abstraction Layer HAL. HEL содержит низкоуровневые вызовы базовых функций и кода CPU. HAL содержит внешние, автономные микро-программы для Графических, звуковых карт и т.д. HAL имеет более высокий приоритет исполнения, чем HEL, но приэтом все библиотечные вызовы выполняются, даже тогда, когда HAL мало что может. HEL-Графика, HEL-Анимация, HEL-Звук, HEL-Видео и пр., как правило медленны в исполнении, но они гарантированно исполнимы.
Производители CPU - Intel и AMD конкурируют с производителями Графических и Мультимедийных карт. Они постоянно улучшают графическую и звуковые компоненты и общую архитектуру CPU, для того чтобы усилить HEL против HAL. И делают это с большим успехом: в простых играх и мультимедиа трудно заметить разницу в производительности, и для офисных приложений достаточно обычного on-board-Videocontroller без отдельной видео-памяти (используется общая память).
| Пример: прорисовка через GDI+ или DirectDraw HEL/HAL
Существует три пути, чтобы что-то нарисовать: 1) обычный Windows-вызов без DirectX работает через GDI+ und DDI. Пример: graphics.DrawLine(mypen, 0, 0, 100, 100); 2) через DirectDraw, HEL и DDI 3) через DirectDraw и HAL Если вариант 3)
существует, то 2)
закрыт. |  |
Direct3D Device
это важнейший Direct3D-Класс, который непосредственно управляет Графической Картой. Его главная функция - Device.Present , переключать BackBuffer Графической Карты на FrontBuffer и таким образом отображать прорисованную функцию на мониторе.
Далее этот класс содержит Свойства/Функции как для Векторной Графики
(Viewport, Vertex Format, Transform) так и для Растровой Графики (Material, Texture, адресса и длины для Output-Buffer).
При старте любой программы, использующей Direct3D, создается данный класс и резервиуются ресурсы и права доступа к Графической Карте.
| Важные свойства | of Direct3D class "Device " |
| DeviceCaps | Возвращает структуру, представляющую возможности железа - используется для определения доступна ли та или иная фича для использования в текущем приложении |
| Viewport | Возвращает/Определяет прямоугольный регион для отрисовки на текущем устройстве |
| Material | Возвращает/Определяет материал для использования при прорисовке (рендере) |
| Lights | Возвращает коллекцию источников света, которые могут быть активированы при прорисовке (рендере) |
| RenderState | Возвращает колекцию состояний рендера, которые используются для контроля различных состояний Direct3D пайплайна. |
| VertexDeclaration | Возвращает/Определяет описание вертексных форматов используемых вертексным шейдером |
| VertexFormat | Возвращает/Определяет описание вертексных форматов, используемых в Fixed Vector Pipeline |
| VertexShader, PixelShader | Возвращает/Определяет the vertex/pixel shader to use for rendering |
| Важные методы | Direct3D class "Device " |
| BeginScene | Готовит устройство для прорисовки примитивов (простых форм) в кадре. BeginScene должна быть вызвана перед прорисовкой любых примитивов в кадре. |
| EndScene | Сигнал устройству, что все примитивы в кадре отрисованы. EndScene должна быть вызвана, когда все примитивы в кадре отрисованы. |
| DrawPrimitives | Прорисовывает примитивы. |
| Clear | Очищает окно перед прорисовкой следующего кадра. |
| Present | Отображает прорисованный буфер и готовит следующий для прорисовки. Present вызывается после EndScene и до следующей BeginScene (для следующего кадра). |
| GetTransform, SetTransform | Возвращает/Определяет мировые, экранныеи другие трансформации. Трансформации применяются для вертексных позиций и нормалей и/или текстурных координат. |
| GetTexture, SetTexture | Возвращает/Определяет текстуры связанные с данным текстурным состоянием. |
DirectX, Windows 7 / 8
| Начиная с W7 весь пользовательский интерфейс базируется на DirectX. Таким образом, DirectX уже не просто графическая библиотека, а основная часть операционной системы. Microsoft предписывает разработчикам графических чипов детальный план необходимой функциональности, которому должны соответствовать все драйвера, находящиеся между операционной системой и DirectX. Производители не имеют особых вариантов - они обязаны следовать предписаниям Microsoft, иначе они теряют рынок Windows-машин. см: Windows Display Driver Model WDDM W7 Display Driver Model Windows Driver Kit (WDK) | 
|
Плюсы
:
1)
Mожно положиться на то, что W7 использует Графическое железо по полной. Не существует ни DDI не HEL, а только HAL.
2)
Mожно быть уверенным, любой драйвер для W7 предлагает минимальный набор команд "Direct3D 10".
3)
Пользовательский интерфейс W7 предлагает быструю высококачественную графику, прозрачность, анимацию, 3D и видео.
4)
Интернет-Страницы могут использовать WPF для быстрой DirectX-Графики.
Минусы
:
1)
Старые Графические карты, принтера, сканеры, не имеющие DirectX10.1-драйвера не будут работать под W7.
2)
Старые DirectX-игры, как правило не работают под W7.
Windows Presentation Foundation WPF
Основными элементами W7-Графики являются:
a)
Desktop Window Manager
= DWM
b)
Windows W7 Display Driver Model
= WVDDM или короче WDDM, поддерживаемые W7-Графическими картами.
Работает так:
1.) Все окна и графические элементы (включая шрифты) в W7 - это Векторная Графика.
2.) Данные и команды Векторной Графики хранятся, управляются и позиционируются через DVM.
3.) DVM передает данные и команды WVDDM-драйверу.
4.) Драйвер преобразует все в формат данных и команд DirectX и загружает это все в свою Графическую карту.
5.) Графический пайплайн на карте отрисовывает картинку автономно (без участия CPU) с максимальной скоростью в Back-Buffer.
6.) как только Back-Buffer заполнен, Графическая карта переключает его как в состояние Front-Buffer для вывода на экран.
С помощью WPF можно создавать как отдельные приложения, так и интерфейсные части других приложений или браузерные приложения.
WPF содержит два API, которые дополняют друг друга и которые можно произвольно смешивать в одном приложении: можно писать часть на C# или XAML или смешано. WPF создан для замены Windows-Forms- и Active-Server-Page- систем.
Плюсы
:
1)
WPF генерирует только Векторную Графику (за исключением текстур и видео) как
2) WPF прорисовывается через DirectX. Соответственно: Анимация, прозрачность, Anti-Aliasing намного быстрее, чем на Flash.
3) WPF обладает богатым и хорошо организованным функционалом для Windows- и Web- GUI s.
4) WPF везде предлагает единообразный интерфейс для Windows, Web-страниц и мобильных устройств.
5) С помощью Expression Studio могут не образованные (не информатики) интерфейс приложения или Web-страницы собрать самостоятельно.
Минусы
:
1)
WPF работает только под Windows (Исключение -
2) Библиотека классов WPF глубоко структурирована и сложна в изучении.
3) Использование WPF приводит к бесполезным графическим наворотам различного рода.
Silverlight - это небольшое ответвление от WPF в форме Plugin-а, который доступен для всех основных браузеров. Страница созданная на Silverlight 4.0 и выше, сделана на XAML и C#. Используя Silverlight можно писать WPF-программы, которые будут работать на всех браузерах и всех платформах без установки и проблем с безопасностью.
