Microsoft DirectX – это очень просто! - Службы и процессы - Windows - Каталог статей - fest.ucoz.ru - компьютерная помощь

qark.ru

Главная » Статьи » Windows » Службы и процессы

Microsoft DirectX – это очень просто!
О чем пойдет речь в статье:
    Что такое DirectX?
    Для чего нужен DirectX?
    Что входит в DirectX?
    Что такое шейдер?
    Зачем нужны шейдеры? Конвейер и шейдерная модель
    Что дает пользователю компьютера очередная версия DirectX?
    DirectX 10. Эволюционное обобщение пройденного
    DirectX 10.1 Как же теперь жить? И пара слов об OGL

   Когда говорят о "Microsoft DirectX”, то разные категории людей могут вкладывать в это различные понятия. Давайте разберемся, что может иметься в виду и что это такое на самом деле, для чего он нужен и чем же отличаются последние версии DirectX друг от друга.

   Что такое DirectX?

   Обратимся к первоисточнику – самой Microsoft:

   http://msdn2.microsoft.com/en-us/library/bb219737.aspx
"DirectX is a set of low-level APIs for creating games and other high-performance multimedia applications. It includes support for high-performance 2D and 3D graphics, sound, and input”.

   Учитывая, что API (Application Programming Interface) – это интерфейс разработки программ, буквальный перевод звучит так: "DirectX – это набор низкоуровневых программных интерфейсов для создания игр и других высокопроизводительных приложений. Он включает в себя поддержку высокопроизводительной 2D и 3D графики, звука и устройств ввода”.

   Применим эти знания на практике. Если моя карта поддерживает DirectX, это значит, что она ... поддерживает набор низкоуровневых.... ну и далее по вышеприведенному тексту. Не срастается! Что-то здесь не так. Что же на самом деле поддерживает видеокарта? Попробуем разобраться.

   В действительности, Microsoft предоставляет это определение для разработчиков программного обеспечения, следовательно, само собой под DirectX подразумевается APIs DirectX. А с точки зрения пользователя все выглядит несколько иначе. Поэтому дадим более общее определение, хотя оно при этом будет подлиннее.

   DirectX – это технология Microsoft для операционных систем семейства Windows, предоставляющая разработчику программного обеспечения интерфейсы (то есть, комфортную среду интерактивного взаимодействия) для создания программ, эффективно использующих графические, мультимедийные устройства и устройства ввода, и обеспечивающая низкоуровневые утилиты (то есть эффективные высокооптимизированные программы) для взаимодействия этих устройств с прикладной программой и операционной системой через соответствующие драйверы.

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

   Для поддержки разработчиков программного обеспечения Microsoft предоставляет DirectX SDK (Software Developing Kit) – набор программ и утилит разработчика программного обеспечения под технологию DirectX, а для системных программистов и разработчиков компьютерного оборудования есть WDK (Windows Driver Kit )– набор программ и утилит для разработки драйверов. Оба этих программных продукта распространяются свободно и доступны для скачивания с сайта Microsoft. К слову сказать, по прилагаемой к DirectX SDK лицензии, все графические и мультимедийные файлы и компьютерные модели разрешается использовать в своих программах для демонстрационных некоммерческих целей.

   Теперь можно смело утверждать, что если моя видеокарта поддерживает DirectX, то это означает, что она способна выполнять программы, созданные с использованием API DirectX, при условии наличия соответствующего драйвера и поддержки со сороны операционной системы.

   Сегодня уже трудно найти видеоадаптер, не поддерживающий хотя бы DirectX 7, поэтому для нормальной работы приложения, разработанного в соответствии с конкретной спецификацией DirectX, нужно, во-первых, чтобы операционная система поддерживала эту версию (плюс к тому были установлены соответствующие или более новые библиотеки DirectX в виде dll – файлов, которые обычно автоматически устанавливаются при инсталляции программы, если на компьютере установлены более старые версии библиотек), во-вторых, чтобы видеокарта была с поддержкой соответствующего DirectX и, в третьих, чтобы был установлен подходящий драйвер видеокарты. Несоблюдение первых двух условий не позволит приложению запуститься, а в случае с драйвером может оказаться так, что самый последний доступный драйвер не является лучшим для конкретного приложения (вплоть до полной неработоспособности программы), хотя, в целом, действует правило, что лучше использовать самые свежие версии драйверов и рекомендуется этого правила придерживаться.

   Часто можно услышать фразу "графический стандарт DirectX”. Это верно лишь c большой натяжкой, особенно до DirectX 10, поскольку ничто не мешало производителям видеокарт легко утверждать о соответствии DirectX даже при несоответствии этой спецификации (хотя она и делится на обязательную и опциональную часть), вводя покупателя и пользователя в заблуждение. Этому способствовало и порождение компанией Microsoft нескольких вариантов DirectX одной версии и, в особенности, множества модификаций шейдерных моделей (SM - Shader Model), чем особенно отличилась версия DirectX 9. Впрочем, этому есть и свое логичное объяснение. Так сложилось исторически, что, хоть программируемый конвейер и возможность исполнения шейдеров впервые появились в версии DirectX 8, настоящая их обкатка происходила уже в DirectX 9.
Но к конвейеру и шейдерам мы вернемся чуть позже.

   Для чего нужен DirectX?

   Несколько слов о том, что явилось катализатором появления DirectX. Безусловно, в первую очередь, это компьютерные игры. Персональные компьютеры и сейчас далеки от вычислительной мощности, позволяющей кинематографически реалистично воспроизводить на экране монитора с высоким разрешением полноценное интерактивное 3D действие в реальном режиме времени, тем более это им было не под силу двадцать лет назад. Поэтому программисты всегда боролись за каждый байт и мегагерц компьютерных ресурсов (а основные ресурсы – это процессорное время и оперативная память), выжимая все из топовых аппаратных решений, доступных на рынке. И в эпоху, когда основной ОС домашних компьютеров была DOS, очень много игр писалось на языке Ассемблер, что было достаточно трудоемко, но в умелых руках позволяло использовать 100% возможностей техники, так как позволяло напрямую программирвать видеокарту, модель распределения памяти и управлять системными ресурсами. Для тех, кто не застал это время, поясню, что, в отличие от Windows, MS-DOS (наиболее распространенная ОС того времени) – это однозадачная ОС, то есть запускаемая программа забирала все компьютерные ресурсы себе. Чтобы запустить другую программу, первую нужно было обязательно завершить, что часто делалось простой перезагрузкой компьютера.

   Производители видеокарт тоже включились в эту гонку, выпуская новые и новые видеокарты, которые частенько и опережали свое время, и оказывались впоследствии тупиковым направлением развития. Но это уже совсем другая история.

   Появление новой ОС – Windows 3.х привело к противоречию между конкретной программой, требующей в свое распоряжение максимальное количество ресурсов, и многозадачной ОС, делящей эти ресурсы по "справедливости” между приложениями. Кроме того, драйверы устройств перестали быть доступны программе напрямую – появилась прослойка в виде виртуальных драйверов. Несмотря на имеющуюся иерархию приоритетов у выполняемых в ОС программ, в первых версиях Windows быстродействие игр оказывалось неудовлетворительным. Поэтому долгое время DOS, которой разработчики игр отдавали предпочтение, сосуществовала параллельно с Windows. Но такое положение вещей не вписывалось в стратегию развития Microsoft и привело к интенсификации усилий по решению имеющихся проблем с быстродействием. Так появилcя Game SDK, впоследствии сменивший название на DirectX, призванный сделать программную прослойку от выполняемой программы до мультимедийного и графического оборудования универсальной, не требующей детального знания оборудования (это – дело производителя, задача которого – написать функциональный драйвер), легко создаваемой и сопровождаемой, минимальной по длине и максимальной по быстродействию.

   Что входит в DirectX?

   Мы выяснили, что означает, фраза "моя карта поддерживает DirectX”. Впрочем, тут есть один нюанс. DirectX – это собирательное понятие набора программных компонент, и, хоть графическая часть и есть его наиболее существенная, сложная и объемная составляющая, там присутствует и поддержка оборудования, отличного от видеокарт. К примеру, видеокарта вряд ли поддерживает DirectInput (хотя технически ничто не мешает, например, установить на ней пару USB-разъемов для подключения джойстика или геймпада). Поэтому, правильно говорить о поддержке видеокартой компоненты DirectGraphics (которая, на самом деле, только "прикрывает” настоящие компоненты – Direct3D и Direct3DХ), составной части DirectX, но маркетинг – он и в Африке маркетинг – поэтому не только короче, но и гораздо солиднее звучит именно вариант поддержки DirectX целиком! И никаких гвоздей! Поэтому от этого стереотипа уже практически не избавиться. Мы ведь живем, по большей части, в демократических государствах, и, раз большинство считает, что поддерживает, то несколько голосов за правду утонут в общем хоре негодования. Чтобы не прослыть белой вороной, заявляем – наши видеокарты поддерживают DirectX! Однозначно и в полном объеме!

   То, что в этом случае видеокарты также должны поддерживать DirectInput, призванный обеспечить работу устройств ввода, таких как клавиатура, мышь, джойстики и другие манипуляторы, уже упомянуто. Все же, для полноты картины, перечислим все компоненты, которые входят в современную версию DirectX:
    DirectGraphics
    DirectSound
    DirectInput

Коротко, логично и понятно. В свое время в разные версии DirectX в разное время включались, убирались и восстанавливались вновь и другие компоненты – DirectDraw, DirectMusic, DirectPlay, DirectShow и еще несколько, но они или уже существуют только для обратной совместимости либо перенесены в другие SDK, и их использование не рекомендуется либо уже попросту невозможно.

   Так классифицирует DirectX сама Microsoft. Но я бы добавил сюда и DirectX Graphics Infrastructure (DXGI) – компоненту инфраструктуры DirectX 10, которая вполне этого заслуживает. Более того, сама Microsoft в других местах ее так и позиционирует. К примеру, при описании отличий DirectX 10 от предыдущих версий читаем, среди прочего:
"Common 2D, focus and adapter-management functionality refactored into a new component: DXGI”,
что в переводе звучит так:
"В новую компоненту DXGI выделены все общие операции в режиме 2D и функциональность, связанная с поддержанием фокуса и управления видеоадаптером”.

   Главная цель создания DXGI – управление низкоуровневыми задачами, которые не требуют включения в библиотеку исполнения DirectX – речь идет о более рациональном разделении установочных и исполняемых процедур.

   Последняя версия DirectX SDK на момент написания статьи (Август 2007) добавляет еще одну компоненту,

   The Windows Vista Game Explorer,

   обеспечивающую соответствие новым правилам Microsoft по разработке игр для платформы Windows - Games for Windows: Technical Requirements, Microsoft Corporation, Version 1.2.0007, August, 2007. В этих правилах, кстати, впервые прозвучало требование обязательной поддержки разрешения 1680х1050 (поддержка более низких разрешений 16:10 требовалась и раньше), а до сих пор это в драйверах Nvidia было лишь опциональным. С текстом этого документа можно ознакомиться на сайте разработчика, есть он и в составе DirectX SDK, начиная с августовской версии 2007 года.

   The Windows Vista Game Explorer обеспечивает легкий, настраиваемый способ представить в ОС Windows Vista компьютерную игру. Эта компонента обеспечивает управление доступом, особенностями запуска, локализацию информации об игре и визуализацию ее представления (все игры теперь должны попадать в специальную папку Games, которую наверняка видели все пользователи этой ОС).

Несколько слов о компонентах DirectSound, DirectMusic и DirectInput.
DirectSound и DirectMusic находятся в подвешенном состоянии – обе компоненты получили от Microsoft "черную метку”. Это значит, что они более не развиваются (правда, в интерфейс DirectSound пока еще вносятся незначительные изменения) и при первом удобном случае будут заменены. На что? Это давно уже не секрет. Microsoft в последние годы сильно озаботилась мультиплатформенностью, правда часто вкладывая в это понятие свой смысл, но, тем не менее, такой шаг можно только приветствовать. И на знаменах (логотипах, заставках) DirectX, и в SDK уже давно присутствуют названия, начинающиеся с буквы "Х” - XNA, XACT, X3DAudio, XAudio2, XInput.
Говоря об использовании DirectXInput vs XInput, Microsoft прозрачно намекает (вернее, говорит открытым текстом), чем использование XInput предпочтительнее DirectXInput. Если посмотреть документацию, то выходит, что Xinput легче использовать, инициировать, он имеет единый кроссплатформенный интерфейс под Windows и Xbox 360, контроллеры от Xbox 360 будут вибрировать только через этот API, а иначе – не будут!, и будущие контроллеры под Xbox 360 (например, рули) смогут работать даже под Windows!
Надеюсь, намек все поняли.

В связи с этим удивляет положение Managed DirectX и анонс о прекращении упоминания о нем в следующей, ноябрьской версии DirectX SDK. Похоже, Microsoft хочет добиться, чтобы и наши правнуки играли на приставках Xbox 360, говоря о том, какой это удачный и современный продукт. Я понимаю, что департамент по развитию Xbox360 нанес удар по своей репутации (ведь правда, какая мелочь потерять несколько сотен миллионов для такого гиганта, как Microsoft) и должен как-то реабилитироваться. Ни в коей мере не умаляю достоинств этой приставки (скорее, наоборот, по совокупности потребительских качеств и учитывая возможности разработчика, считаю ее лучшей приставкой), мне просто не нравятся некоторые шаги Microsoft, которая частенько похожа на того медведя в лесу, который, чтобы сорвать всего лишь одну маленькую ягодку, мимоходом задевает и разрушает своей косматой лапой муравейник, вырывает малинник с корнями, даже не интересуясь, почему маленькие обитатели леса (те, кому удалось выжить) так его не любят. Он их даже не замечает. Только этот медведь, сидя на той же опушке через год, удивленно будет чесать свой затылок лапой - почему же там больше не выросло ни одной ягодки?

   А на досуге предлагаю наиболее продвинутым пользователям компьютера решить задачу - поддерживает ли их видеокарта DirectSound, если она обеспечивает передачу звука по HDMI.

   Что такое шейдер?

   Слово "шейдер" очень часто употребляют неправильно, не понимая что это такое и отождествляя его с частью компьютерного оборудования. Но это понятие не относится к категории "hardware".
Что же такое "шейдер”? Это слово пришло в мир бытовых компьютеров из кинематографии, где так именовались специальные программы ("shaders”), участвующие в рендеринге (формировании) итогового изображения на экран (или в память). Поэтому шейдеры – это относительно небольшие программы, написанные на специализированных языках, которые выполняются графическим процессором. Для чего служат эти программы и почему заранее известно, что они небольшие? Современные ГПУ обрабатывают потоковую информацию – большие массивы однородных данных простых типов, которые надо обработать по короткому алгоритму и быстро передать дальше, чем меньше программа – тем быстрее обработка, хотя тенденция к усложнению явно прослеживается. Впрочем, большими эти программы (по крайней мере по отдельности) еще долго нельзя будет называть, а размер первых шейдеров вообще очень сильно ограничивался возможностями видеокарт (это определялось наличием в ГПУ регистров для хранения обрабатываемых данных и установленным ограничением на число выполняемых инструкций).
А зачем им нужен специализированный язык? ГПУ имеет многочисленные внутренние специализированные потоковые процессоры с ограниченной функциональностью и упрощенной системой команд. Для потоковой обработки этого вполне достаточно. Это – компромисс между функциональностью, стоимостью и быстродействием, оптимальный на сегодня.
Но даже для небольшой игры может потребоваться написание большого числа шейдеров. Шейдеры группируются в логически связанные блоки, именуемые эффектами ("effects”). Дополнительную информацию по этому вопросу можно получить из документации к DirectX SDK.

   
Зачем нужны шейдеры? Конвейер и шейдерная модель

   Было время, когда о шейдерах никто и не думал. Хорошее было время! Откуда же они свалились на нашу голову? Для того, чтобы понять это, надо знать, как работает современная видеокарта и графический процессор и как это было в то далекое время, когда дети, увидев морскую волну, не кричали радостно "Шейдеры! Шейдеры!”. Поэтому будет уместно сделать маленькое лирическое отступление от непосредственной темы DirectX и разобраться в этом. Я постарался максимально упростить технические детали, насколько это мне удалось – судить вам.

   Попробуем упрощенно описать, как функционирует видеокарта. Тут удобно применить технологию "черного ящика”, широко используемую в автоматике. У ящика есть вход и выход, внутренняя функциональность нас интересует весьма приблизительно, причем не интересует, как это происходит на самом деле, а важно лишь то, как это видится снаружи "черного ящика”. Этим черным ящиком и будет выступать видеокарта. Мы должны узнать, что подается на вход, что является выходом и в общих чертах понять, что происходит внутри этого "черного ящика”.

   Что является выходом, большинству сразу понятно – к видеокарте подключается монитор и то, что мы на нем видим, и есть выход. Пока будем считать, что так оно и есть, хотя это является истиной далеко не всегда – карта может работать ведомой в SLI или CF без монитора, видеокарта может производить неграфические вычисления и также не подключаться к монитору, выполняя полезную работу как сопроцессор к ЦПУ, либо часть процессорного времени ГПУ может отдаваться задачам, не связанным непосредственно с графикой.

   Так что же подается на вход видеокарты? Смотря что видно сейчас на мониторе, если, конечно, видеокарта у нас работает как видеокарта, а не считает, к примеру физику или химию .
Допустим, программа должна выводить на экран трехмерный куб.
Как вообще можно описать куб математически? Способов существует много, но если речь идет о DirectX, то трехмерный объект представляется набором треугольников. Чтобы получился квадрат, нужно два треугольника а на шесть граней куба нужно уже 12 треугольников. Каждый треугольник имеет 3 вершины, поэтому всего нужно будет определить 36 вершин. Каждая вершина может быть представлена в виде трех чисел – ее координат в трехмерном пространстве. Область памяти, где хранится информация о вершинах объекта, называется вершинным буфером, или буфером вершин. Кому-то может показаться, что можно бы уложиться и в восемь вершин, и он будет не далек от истины, так как в действительности выборка может происходит по данным дополнительного индексного буфера, содержащего только индексы, привязанные к буферу вершин, а вершинный буфер может состоять только из уникальных координат, но эти нюансы мы здесь не рассматриваем. Координаты всех 36 вершин, одна за одной, непрерывным потоком, каждый кадр, поступают в видеокарту. Как правило, вершины имеют более сложный формат (хотя это и не обязательно), например, используются текстурные координаты для правильного наложения текстуры, вектор нормали, цвет и другие данные, но это выходит за рамки темы данной статьи.
Конечно, поток из 36 чисел за кадр – не нагрузка даже для самого древнего графического процессора, но более сложные объекты – игровые персонажи, окружающие предметы, природа могут содержать миллионы треугольников, и такой поток данных один или два потоковых процессора, имевшихся в наличии у старых видеокарт, уже не смогут обработать без катастрофического падения производительности. Поэтому число потоковых процессоров у видеоадаптеров, поддерживающих DirectX 9, измеряется десятками, а у нынешних топовых карт под DirectX 10 – сотнями. Без сомнения, скоро счет перейдет на тысячи, даже без учета объединения нескольких ГПУ на кристалле, плате видеокарты и в целом на материнской плате (а о кластерах даже думать не будем).

   Таким образом, данные о вершинах хранятся в памяти, в буфере вершин, и периодически поступают на обработку в видеокарту. Что происходит с ними дальше – зависит от того, какую версию DirectX поддерживает видеокарта и какую версию DirectX поддерживает программа. Грамотное DirectX приложение при старте проверяет, удовлетворяют ли возможности видеокарты требованиям программы, и только при положительном ответе (после опроса системных данных) разрешает работу.
Итак, пока мы определились, что в видеокарту постоянно будет поступать информация из буфера вершин.

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

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

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

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

Вернемся к вопросу, а что происходит дальше с данными вершин (в нашем примере – с координатами) в видеокарте? Как их связать с экраном монитора? Потихоньку мы доберемся и до монитора, но сейчас отметим, что то, как выглядит наш куб на мониторе, определяется не только координатами вершин треугольников, из которых складывается куб, но также и положением и ориентацией в пространстве наблюдателя (камеры), и параметрами самой камеры (угол поля зрения, формат кадра и т.д.). Поэтому должна быть возможность измерять координаты и угловую ориентацию объектов относительно общей точки отсчета, что даст возможность пересчитать положение и ориентацию любых трехмерных объектов относительно друг друга. Эти операции не очень сложные, но тем не менее требуют знания высшей математики, хотя при программировании таких задач можно полностью полагаться на известные приемы и алгоритмы, без необходимости изучения матричного исчисления (в профессиональных разработках обычно используется математика кватернионов, но, для простоты, в большинстве примеров программирования в DirectGraphics рассматриваются именно матричные операции).
Поскольку положение (то есть координаты) и ориентация (то есть углы поворота) наблюдателя (камеры) и технические параметры камеры определяют, что мы видим на мониторе, стоит задача – трансформировать 3D координаты вершин куба в 2D экранные координаты.
Для этого уже давно придумали формулы пересчета, и перевод из одной системы координат в другую это – умножение на мировую матрицу (определяющую положение в глобальной системе координат), матрицу вида (положение и ориентация наблюдателя) и матрицу проекции (с параметрами камеры).
Во времена, когда только появились первые специализированные графические процессоры, эту трансформацию координат выполнял процессор. Поскольку таких операций нужно делать много, то умножение матриц (обычно это можно оптимизировать до умножения вектора на матрицу) совокупно представляет собой весьма недешевую операцию и сильно загружает процессор. А поскольку это - операция рутинная и однородная, выполняющаяся над всеми вершинами всех объектов трехмерной сцены, то решено было разгрузить ЦПУ, переведя эти вычисления в ГПУ, на специализированный потоковый процессор, автоматически выполняющий такой пересчет.
Вот по такой логике и стали работать первые ГПУ с аппаратным блоком трансформации и освещения "T&L” (Transform And Lighting) - NVidia GeForce256. Чтобы не загромождать материал статьи, я не буду вдаваться в детали расчета освещения и отсылаю заинтересованных читателей к http://www.nvidia.com/object/transform_lighting.html

   Отныне (но не навсегда!) аппаратная поддержка "T&L” стала символом высокой производительности видеокарт, это давало серьезную прибавку быстродействия программам и было поддержано всеми игроделами – вскоре все 3D игры для запуска стали требовать графического процессора с поддержкой "T&L”. И все бы было хорошо, но прогресс не стоит на месте. Поскольку логика трансформации "T&L” была жестко "зашита”в ГПУ (отсюда и произошло название – фиксированный конвейер), она сильно ограничивала и выравнивала выразительные возможности создаваемых программ, кроме того, жестко реализованная модель освещения во многих случаях была слишком примитивной для реализации красочных или реалистичных эффектов. Да и Microsoft добавляла что-то новенькое в DirectX только каждые год – полтора. Техника мультитекстурирования, некоторое время решавшая проблему и широко использовавшаяся в дошейдерную эпоху для придания "красивостей” игровым объектам, уперлась в пропускную способность видеопамяти – требовалось многократное чтение из текстурной памяти и многократное чтение-запись в буфер кадра. Было очевидно, что долго так продолжаться не сможет. И было предложено революционное решение, предопределившее стратегическое направление развитие графических процессоров на долгие годы - замена фиксированного конвейера на программируемый – вместо блока "T&L” появился блок потоковых процессоров, выполняющих обработку потока данных из вершинного буфера по программе вершинного шейдера. Блок мультитекстурирования сменил блок потоковых процессоров, выполняющих обработку потока данных (уже обработанных вершинным шейдером и прошедшими операции удаления невидимых и неотображаемых поверхностей), по программе пиксельного шейдера.
С выходом DirectX 8, определившим спецификацию новой технологии, появилась возможность относительно легко реализовывать любые модели освещения, произвольные трансформации и попиксельную обработку изображения (намного более гибкую и совершенную, чем появившуюся еще в DirectX 6 технику DOT3 с картами нормалей).

   Новая эпоха шейдерного графического программирования принесла не только улучшение качества графики, но и головную боль программистам и покупателям видеокарт.

   Программисты пострадали из-за того, что новый путь развития графического программирования был новаторским, зачастую методом проб и ошибок, что приводило к постоянным изменениям спецификации от Microsoft в DirectXGraphics и тем возможностям, которые предоставлял API и, следовательно, к появлению новых и новых видеокарт, каждая из которых требовала изменений в коде шейдера. При этом производители видеокарт не утруждали себя 100% воплощением возможностей API в железе, что не мешало им заявлять о полной поддержке DirectX. Особенно ярко это проявилось в DirectX 9 - появились версии 9a, 9b, 9c и различные варианты поддержки программирования шейдеров, что привело к понятию "шейдерная модель” (Shader Model, SM). Поддержка шейдерной модели означала поддержку в АPI специфических команд языка, на котором пишется шейдер, и наличие соответствующих регистров и возможностей обработки данных в видеокартах. Технические различия интересны только программистам, но пользователи стали теряться среди DirectX карт, поддерживающих SM1.0, 1.1,1.3,1.4, 2.0,2.0a, 2.0b.... Плюс непонятные простым смертным аббревиатуры PS или VS рядом с этими цифрами.
Дело дошло до того, что шейдерные модели стали делиться на "для ATI” и "для Nvidia”.
Следующая шейдерная модель SM 3.0 положения со следованием стандарту не улучшила - например, ATI не стала подерживать карты смещения в вершинном шейдере, мотивируя это тем, что у Nvidia эта технология работает медленно и требует несколько десятков миллионов транзисторов на кристалле дополнительно. Вместо этого ATI предложила свой вариант рендеринга в буфер вершин, что опять потребовало от программистов создания еще нескольких программных заготовок.

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

   Посочувствовав друг другу, давайте доведем поток данных по конвейеру до монитора.
После обработки по программе вершинного шейдера, происходит удаление всего того, чего не видит камера – зачем обрабатывать то, что никто не увидит? Но ничего не увидеть можно и по простой причине, если интересующий наш объект не попал в поле зрения камеры. Но если ракурс удачный, расстояние до нашего куба подобрано адекватно его размеру и камера правильно настроена, мы увидим наш куб во всей красе.
А как обеспечивается то, что в полноэкранном режиме куб будет выглядеть примерно одинаково на мониторе и при разрешении 640х480, и при 1024х768? Да очень просто. Растеризатор (блок ГПУ, который и отвечает за перевод 3Д картинки в 2Д), работает с внутренним представлением буфера, независимо от размера, имеющим диапазон по сторонам измерения -1.0..+1.0. Поэтому пересчет в абсолютные экранные пикселы, так, чтобы левый верхний угол выводимого изображения имел координаты (0,0), а правый нижний (639,479) или (1023,767) – это задача по арифметике для первого класса начальной школы.
Конечно, на самом деле растеризация – очень сложный и многоступенчатый процесс, и то, что обычно называют растеризацией, вовсе таковой не является по большому счету, но это вы можете проверить сами, прочитав соответствующие материалы, а начать, естественно, рекомендую с того же первоисточника – документации DirectX SDK, сайта Microsoft и есть масса монографий с такими математическими выкладками, которые вызывают стойкое и долговременное отвращение к любым математическим формулам.

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

   Все вышеизложенное, для более сложной программы, требует сотен и тысяч строк кода (если, конечно, не пользоваться специальными фреймворками или высокоуровневым программированием), и приводится в движение волшебной командой Draw - Рисовать (как правило, их несколько на каждый кадр), которая используя многочисленные условия и договоренности, производит рендеринг (отрисовку) сцены в буфер кадра (ну или в какую - нибудь другую поверхность рендеринга, что в обоих случаях представляет собой выделенный участок видеопамяти).
В случае, если это – буфер кадра, нужно иметь в виду следующее. Как минимум, в DirectX для конкретной программы таких буферов будет два. Зачем? Потому что в процессе рисования объекты выбираются последовательно и новый объект может затирать информацию о предыдущем, если, к примеру, он его загораживает от камеры. Такая смена объектов, конечно, не заметна на глаз в деталях, но вот определенное мелькание и неприятные кратковременные "помехи” будут заметны. Поэтому, для того, чтобы от этого избавиться, применяется так называемая двойная буферизация. Создается два идентичных буфера кадра. Как только выполнены все команды Draw, по команде Present (Показать) происходит быстрое переключение адреса буфера, в котором формировалось изображение. Буфер, в который отрисовка закончилась, становится FrontBuffer (Передний Буфер) – областью памяти, которая уже формирует глобальный буфер кадра, который уже и поступает на монитор (если программа работает в полноэкранном режиме, то кадровый буфер программы и представляет собой глобальный буфер кадра). А буфер, который до этого был FrontBuffer, становится BackBuffer (Задний буфер) и в нем будет формироваться следующий кадр. Таким образом, рендеринг происходит все время в BackBuffer, а на монитор всегда идет изображение с FrontBuffer. Частота, с которой переключаются буферы кадра, определяет то число кадров в секунду, по которому судят об "играбельности” компьютерной игры и оно характеризует производительность графической подсистемы компьютера в данный фрейм. А если точнее, то в предшествующий. Но если уж совсем быть точным – то за некоторый период, зависящей от текущей 3D сцены, от объема видеопамяти и еще некоторых факторов. И в итоге это означает что это число характеризует совокупные аппаратные возможности компьютера при выполнении конкретной программы в конкретной операционной среде .

   Может возникнуть вопрос, если на видеокарте, поддерживающей DirectX 9, запускается старая программа, написанная без шейдеров и требующая наличия блока "T&L”, как она выполняется, ведь современные карты уже не содержат аппаратного "T&L”? Очень просто. Драйвер видеокарты различает такую ситуацию и имеет для этих целей простейшие шейдеры с обработкой в стиле а-ля "T&L”, что обеспечивает полную совместимость со старыми приложениями.

   Что дает пользователю компьютера очередная версия DirectX?

   Теперь, когда мы знаем, что такое DirectX, попробуем разобраться, с точки зрения пользователя-непрограммиста, а что нам дает каждая новая версия DirectX?
Ответ однозначен – НИЧЕГО! DirectX – это одновременно и инструмент и потенциал, который надо раскрыть. Это должны сделать и разработчики программы (программисты, администраторы, художники, музыканты, дизайнеры) и программисты – драйверописатели.

   Чтобы раскрыть такой потенциал, нужно немало усилий по изучению нового API и возможностей видеокарт, написанию и отладке кода и его оптимизации, постоянное отслеживание производительности десятков типов видеокарт под последними драйверами, часто вносящими хаос в уже отлаженный под предыдущий драйвер код, нужно умение и способность выкроить чуть – чуть ресурсов для создания нового эффекта, под который их нехватило в предыдущей версии движка под предыдущую версию API... иначе зачем новый API, если все-будет выглядеть по старому? И стоит только выкроить полмиллисекунды на кадр, ее тут же забирают под дополнительные полигоны в сцене, и начинается все сначала.... Проходит время..... Уже анонсирована следующая версия DirectX....
Это была история о программистах из деревни Виллабаджо.

   А в это время в деревне Виллариба программисты под OpenGL радуются и веселятся – смена поколения видеокарт не принесла им никах проблем со сменой API, только лишь возросло быстродействие! И они только что сделали классную новую игру! И не хуже последней игры, выпущенной в деревне Виллабаджо под DirectX!

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

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

   DirectX 10. Эволюционное обобщение пройденного

   У Microsoft было достаточно времени – несколько лет, чтобы провести всесторонний тест выбранного направления развития графических API. И в самый расцвет DirectX 9 стало ясно, что продолжения не будет. В недрах подразделений R&D Microsoft рождалась новая операционная система. Первоначальные перемены названия преемника DirectX и кулуарные высказывания показывали, что DirectX 9 - это если не последний вариант DirectX вообще, то, по крайней мере, последний под Windows XP. Как оказалось, Microsoft все же не стала отказываться от брэнда DirectX и в новой Windows Vista увидела свет DirectX 10.

   Конечно, смена поколения ОС – очень удобный повод железной рукой установить более жесткий порядок в плане следования выработанной спецификации (и тут мы всецело на стороне Microsoft). В этот период можно легко убрать те моменты, которые не устраивали, добавить то, чего не хватало и заложить резерв под будушие нужды. Но Microsoft поступила более радикально, бросив на XP тень полной бесперспективности, видимо с целью несколько ускорить естественный процесс отмирания прежних версий ОС. Ведь как бы ни уверяла Microsoft в том, что поддержка DirectX 10 настолько тесно интегрирована с ядром новой ОС, что никакая полноценная поддержка в Windows XP невозможна, очевидно, что изначально, помимо чисто технических целей улучшения (полного обновления) DirectX ставилась и цель, по чисто маркетинговым соображениям (чтобы поднять продажи ОС Vista), - получить техническую аргументацию в обосновании такой невозможности. На мой взгляд, виртуализация видеопамяти, переключение задач на ГПУ и унификация доступа к ресурсам, как наиболее влияющие на несовместимость факторы, и возникающие в связи с этим проблемы, вполне могли быть решены и в предыдущей версии ОС, если бы такая задача стояла (или, в худшем случае, была бы немного ограничена функциональность DirectX 10). По приведенной выше причине она, естественно, и не ставилась. Впрочем, это мое личное мнение, и оно может не совпадать с реальными намерениями Microsoft, но я не нашел доказательств обратному.

   Гордо заявлено, что все написано с нуля. Хотелось бы спросить, а что, предыдущий опыт был отброшен? Наняты совершенно другие люди? Заведена дружба с разработчиками открытого графического ПО?
Нет, конечно. Первые описания и примеры работы с графической частью DirectX - Direct3D 10 появились публично еще в декабре 2005 года. Команда разработчиков кардинально не менялась. Более того, была сделана попытка ограничить полноценную поддержку OpenGL. Многие, кто был связан с этой темой, помнят размещенное в прошлом году объявление на первой странице официального сайта www.opengl.org , которое долгое время призывало всех оказать давление на Microsoft с целью недопустить дискредитацию OpenGL. Впрочем, эти нападки не новые, можно вспомнить и открытые письма грандов мировой игровой индустрии, направленные Microsoft (по аналогичному поводу!) и в 1997 году http://www.azillionmonkeys.com/windoze/OpenGLvsDirect3D.html .
Вообще, надо отметить, что Microsoft получает массу открытых писем ежегодно по всяческим поводам и без повода, так что ей не привыкать.
Впрочем, хватит лирики, раз приказано жить по новому, то вариантов у нас немного - значит, будем жить. Что же нового принес нам DirectX10 (и Vista) ?

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

   Внедрена новая модель драйвера Windows Vista Display Driver Model (WDDM). Чем стала плоха старая модель WDM, использовавшаяся в прежних версиях Windows, можно узнать по ссылке:
http://www.microsoft.com/whdc/driver/wdf/wdf-intro.mspx
а вот все о новой модели WDDM:
http://msdn2.microsoft.com/en-us/library/ms797619.aspx

   Краткий комментарий.
Произошла полная виртуализация графической памяти. Набирающая силу тенденция виртуализации всего и вся наконец-то добралась и до видеоподсистемы компьютера в полную силу. Чем же она так хороша? Да многим, и с точки зрения безопасности, и с точки зрения размера адресного пространства. Теперь каждому окну приложения выделяется собственная виртуальная память в размере полного экрана, собственный рендеринг (впрочем, WDM – Windows Display Manager трогать не будем). Разрешение экрана 1280х1024 потребует более 5Мб видеопамяти. 10 открытых приложений займет под 60 Мб. Без виртуализации, особенно на карте со 128Мб это называется приехали. Так что очень полезная штука.

   Появилась возможность переключения задач на ГПУ. Теперь есть возможность прервать выполнение основной графической задачи и быстро выполнить в фоне, к примеру, расчет какого-нибудь физического взаимодействия объектов. Причем предоставляется возможность и прерывания выполнения работы над примитивом или посреди выполнения шейдера, если это поддерживается видеокартой (так как это не является требованием DirectX 10).

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

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

   Если теперь производитель карты заверяет, что его видеокарта поддерживает DirectX 10, то этому уже, наверное, можно поверить. По новой спецификации, такая поддержка означает полное соответсвие API – все, что запрограммировано правильно, должно выполняться на любом DirectX 10 железе. Другое дело, что карты все равно разные и обеспечивают разные возможности. К примеру, Радеоны включили аппаратную тесселяцию, что скоро станет требованием DirectX, а видеокарты Nvidia 86хх имеют несколько аппаратных отличий, выгодно отличающих их (конечно, временно, до выхода нового поколения карт) от топовых решений 88хх (к примеру, это позволяет им обращаться к атомам в технологии CUDA, чего лишены их более старшие собратья, есть и другие преимущества. Впрочем, это вряд ли компенсирует владельцам этих карт банальный разрыв в быстродействии).

   Появилась новая стадия в конвейере – стадия исполнения геометрического шейдера. Что можно интересного запрограммировать в коде геометрического шейдера? Как и вершинный шейдер, он на входе получает вершины и вершины же выдает на выход, но появляются существенные отличия. Входными данными уже являются не обезличенные вершины в потоке, а вершины примитивов, то есть вершины треугольника, линии или точки, а также соответствующие примыкающие вершины (три на треугольник и две на линию). В выходном потоке стадия геометрического шейдера может генерировать дополнительные вершины, образующие коллекцию вершин (point list), ломаную линию (line strip), либо группу связанных треугольников (tristrip).
Выходной поток вершин стадии геометрического шейдера может быть направлен, как входной поток, на стадию растеризации, либо в буфер памяти, и тогда он снова может являться входным источником вершин для стадии исполнения вершинного шейдера.

   Безусловно, операция крайне процессороемкая (имея в виду ГПУ) в плане создания на лету высокополигональной геометрии (особенно, если делать ее за один присест).

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

   Шейдерная модель получила номер 4.0.
Программный язык написания шейдеров – только НLSL (хотя по-прежнему можно подключать внешний байт-код).

   Произошла унификация подхода к используемым ресурсам – все ресурсы могут быть деривативами только от текстуры или буфера памяти.

   Остальные отличия и нововедения, да, впрочем, как и большинство уже перечисленных, интересны только для программистов, которые эти новшества и так знают, всех интересующихся я отсылаю к документации по DirectX 10 SDK. Не думаю, что всем пользователям будут интересны сведения, звучащие как "в отличие от DirectX 9, теперь текстурные сэмплеры не ассоциированы с конкретной текстурой, а описывают применяемый к ресурсу метод фильтрации” или "DirectX 10 позволяет сократить ресурсоемкие операции смены состояния объекта Direct3D10, путем введения объектов состояния. Это особенно важно для организации обеспечения валидации объектов при их создании (а не при каждом использовании). Объекты состояния можно кэшировать в видеопамяти и в API - вызовах использовать хэндл на объект”.

   Соответствуют ли изменения от DirectX 9 к DirectX 10 революционному обновлению? Мое скромное мнение – нет, это большой шаг вперед, но по значимости он не дотягивает до действительно революционного скачка от DirectX 7 к DirectX 8. Тем более очень интересная особенность – динамическая смена задач на ГПУ – не относится к DirectX.

   Что мы, как обычные пользователи, вправе ожидать от технологии DirectX, присутствующей на рынке 8 месяцев плюс год открытого предварительного тестирования?

   Увы. Мое мнение такое. Самые новые игры под DirectX 9 напрягали соответствующие топовые видеокарты под завязку. Новые возможности API, теоретически давая очень интересный инструмент в руки разработчика, не позволят реализовать его полный потенциал на существующих топовых DirectX видеокартах (имеется в виду Nvidia 8800 и AMD 2900) так, чтобы это было играбельно.
То, что анонсируемые на этот год премьеры будут ориентированы на эти топы, понятно, но уровеь всеобщего ожидания и интерес к этим играм такой, что плохо быть сделанными они не имеют права. Значит, их будут делать хорошо, чтобы разница в передаче игровой атмосферы под DirectX 10 была бы заметна. При этом, чтобы обеспечить приемлимый фпс, наверняка частью красот придется пожертвовать. Миддл сектор в лице 8600 и 2600 отдыхает.

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

   Но есть и хорошие моменты.
Во-первых, это только мое личное мнение, и я очень хочу, чтобы оно оказалось ошибочным (у меня самого пара 8600GT).
Во-вторых, наверняка будет много игр, не выжимающих все из железа, но реализующих какие-нибудь интересные возможности DirectX 10.
В третьих, скоро подоспеет новый топ от Nvidia. Но я не говорил, что это хорошая новость для всех.

   DirectX 10.1 Как же теперь жить? И пара слов об OGL

Вы можете спросить, а что появляется вперед – API или новое оборудование? Конечно, API определяет будущую архитектуру и первым появляется на рынке, но этот процесс итерационный и происходит путем консультаций специальной группы ведущих вендоров, безусловно с участием AMD и NVidia, с главенствующей ролью Microsoft, ибо решающее слово – за ней. С момента официального появления DirectX10 прошло уже достаточно времени для подготовки и анонса очередного изменения. И этот анонс Microsoft сделала на SIGGRAPH - DirectX 10.1 появится в Windows Vista SP1. Это получило широкий резонанс и обсуждение (люди, не разбирающиеся в этой технологии просто подняли панику, интерпретировав информацию таким образом, будто бы видеокарты только c поддержкой DirectX 10.0 уже ни на что не годны), а сделанное за четыре дня до этого заявление о релизе OpenGL 3.0, окончательный стандарт которго будет принят в конце сентября 2007 года, осталось практически незамеченным. С другой стороны, нельзя не отметить, что разработчики OpenGL всегда более взвешенно подходят к своим пользователям и более лояльно относятся к имеющемуся у них оборудованию.

   Кстати, еще пара слов о конкурирующем стандарте графического API – OpenGL. Его глобальное обновление, с точки зрения временных рамок, вторично по отношению к DirectX, так как он уже ориентируется на те аппаратные изменения, которые производители делают для соответствия спецификации DirectX. Поскольку аппаратное обеспечение и при OpenGL и DirectX одинаково, принципиально эти технологии примерно равноценны, если говорить о потенциальном качестве картинки, а различия проявляются на уровне самого API, открытости кода, мультиплатформенности, способе принятия расширений стандарта и еще нескольких менее важных для конечного пользователя моментов.

Но вернемся к DirectX 10.1. Абсолютно ничего страшного не произошло, всего лишь мелкое эволюционное изменение, вполне соответствующее тем временным рамкам, которые были приняты между предыдущими обновлениями версий DirectX. Поскольку изменений не так много, я решил привести их все (хоть это и сугубо технические моменты), чтобы вы также смогли оценить размеры "катастрофы”.

   Перевожу с английского, документация DirectX SDK за август 2007 года:

   Direct3D 10.1 добавляет 3 новых API интерфейса. Они добавлены в Direct3D.1 DLL (D3D10_1.DLL и D3D10Core.dll), и будут доступны в Windows Vista Service Pack 1, а именно:
две новые функции D3D10CreateDevice1 и D3D10CreateDeviceAndSwapChain1 для создания интерфейса ID3D10Device1, который получил новые методы для создания интерфейса блендинга ID3D10BlendState1, поддерживающего независимые моды блендинга для каждой поверхности рендеринга и для создания интерфейса ID3D10ShaderResourceView1 c подержкой новых массивов кубических текстур (см. D3D10_TEXCUBE_ARRAY_SRV1).

   Это все.

   Соответственно, появляется SM 4.1 для поддержки дополнительного метода работы с субресурсами и массивами кубических текстур.

   Правда, к выходу Windows Vista Service Pack 1 список изменений может быть дополнен. Думается, что если бы Microsoft знала, какую волну подымет анонс и какой это найдет резонанс в среде технических дилетантов, она бы анонсировала его только вместе с выходом Windows Vista Service Pack 1, тем более, что всем кто следит за DirectX, о выходе версии DirectX 10.1 было известно давным-давно. Ни один разработчик не будет поддерживать DirectX 10.1 эксклюзивно, и если хочется поддерживать оба варианта, то никаких усилий для этого прикладывать не надо.

Категория: Службы и процессы | Добавил: solidax (11 Январь 2014)
Просмотров: 870 | Рейтинг: 0.0/0
Всего комментариев: 0
Имя *:
Email *:
Код *: