|
DirectX 10 -
16.02.2007, 12:46
автор статьи Антон Бреусов, размещено на itc.ua
DirectX занимает важное место в архитектуре Windows. Этот набор системных компонентов отвечает за все мультимедийные задачи в системе: видео, звук, графику. Мы расскажем об интересных новинках и изменениях в десятой версии Direct3D – компонента, ответственного за трехмерную графику. Тем более что в Microsoft Vista на его плечи легла визуализация графического интерфейса операционной системы – Aero.
На самом деле мы были бы рады познакомить читателей с новыми возможностями всех компонентов DirectX, если бы... таковые имели место. В этот раз впервые значительным, даже кардинальным изменениям подвергся только Direct3D. Прочие крупные компоненты (а из актуальных их теперь лишь два: DirectInput и DirectSound) остались без изменений, еще несколько уже довольно давно считаются устаревшими (DirectDraw, DirectMusic и DirectPlay) либо предназначенными для мультимедийных, а не игровых задач (DirectShow).
Хотя такой компонент, как Direct3D (D3D), адресован разработчикам ПО и игр и обычные пользователи напрямую с ним не работают, знать о нем им не помешает. Ведь каждая новая версия D3D устанавливает некую планку технических возможностей, которые должен поддерживать 3D-акселератор аппаратно (т. е. без эмуляции видеодрайвером), чтобы называться совместимым с ней, – и эта информация поможет в выборе модели видеокарты. К тому же по поддержке той или иной игрой определенной версии Direct3D можно примерно судить о техническом потенциале графического движка игры, по крайней мере на переходном этапе между версиями (т. е. в ближайшие год-полтора), так как в первую очередь новую версию D3D стараются поддержать наиболее технологичные и современные проекты. И наконец, та или иная игра делается в расчете на определенную минимальную версию Direct3D и без поддержки ее системой (ОС и видеокартой) просто не запустится – это может послужить толчком к апгрейду либо уберечь от покупки несовместимой игры для старого компьютера.
Direct3D 10 стал первым крупным обновлением данного API за последние четыре года – со времен появления D3D 9.0 в 2002 г. И это первый случай, когда его новая версия поддерживается только самой последней операционной системой Microsoft Vista. Поддержка D3D10 в Windows XP официально не планируется, к тому же она трудно осуществима технически. Причина кроется в значительном изменении архитектуры дисплейного драйвера, т. е. уходе от принципа его совместимости с прошлым семейством Windows NT 5.x (Windows 2000, XP, 2003 Server). Новая архитектура называется WDDM (Windows Display Driver Model), и переход на нее во многом вызван появлением нового графического интерфейса в Vista – Aero, базирующегося на Direct3D и в немалой степени «нагружающего» 3D-акселератор. Aero не использует для рендеринга GUI старый двумерный GDI API, применявшийся в Windows для этих целей еще с первых версий, и при использовании которого перерисовываются только части экрана, изменившиеся или «затертые» другими окнами, например, при их перемещении. Многие эффекты Aero являются динамическими и истинно трехмерными, что GDI не под силу. В Aero пересмотрена сама концепция рендеринга интерфейса программ: вместо непосредственного рисования на экране происходит сборка изображения из отдельных частей с применением эффектов на лету, несколько раз в секунду, как это осуществляется в играх. В свою очередь рендеринг трехмерного изображения параллельно несколькими программами, а также самой ОС без возникновения задержек требует лучшего управления его ресурсами, что и достигается с помощью WDDM-совместимых драйверов.
От общеархитектурных изменений в Vista для поддержки D3D10 перейдем к новым возможностям этого API и акселераторов, аппаратно совместимых с ним. На диаграмме изображена общая схема 3D-конвейера в Direct3D, округлые блоки являются гибко программируемыми с помощью шейдеров, прямоугольные же по-прежнему управляются путем установки набора состояний, задающих режим их работы. Уделим внимание новым этапам конвейера.
Input Assembler (IA) предназначен для задания набора входных данных, размещенных в видеопамяти, для использования их последующими этапами конвейера и интерпретации нужным образом. Следующий за ним этап вершинного шейдера (vertex shader, VS) не претерпел особых изменений по сравнению с прошлой версией и служит для трансформации информации отдельных вершин-точек 3D-объектов, изменяя такие их параметры, как координаты или освещенность.
Одним из самых интересных и наиболее мощных нововведений D3D10 являются геометрические шейдеры (geometry shader, GS). Вершинные шейдеры ничего не знают о связях отдельных вершин объекта, над которым работают, т. е. геометрической топологии объекта, и не могут вмешиваться в эти связи, добавляя или удаляя вершины. В отличие от них геометрические шейдеры работают уже с целыми примитивами (точка, линия либо треугольник) и их связями с соседними примитивами, но главное – могут более произвольно с ними обращаться, генерируя на выходе новые примитивы на лету в любом количестве либо пропуская ненужные, в зависимости от входных данных и своего алгоритма. Такие богатые возможности в обращении с геометрией позволяют перенести полностью на GPU многие вещи, которые ранее делались частично под управлением CPU, что снижало скорость параллельной работы процессора и видеокарты за счет частых блокировок 3D-ресурсов для произведения операций над ними на CPU. К примеру, стало возможным полностью перенести на GPU системы частиц, расчет теневых объемов для ряда алгоритмов динамических теней, реализовать наконец честный displacement mapping, некоторые прогрессивные техники motion blur, визуальные эффекты (мех, волосы, растительность), однопроходное создание кубических карт отражения (cubemap).
Стадия геометрического шейдера в 3D-конвейере является опциональной и расположена между этапами вершинного шейдера и растеризации. Кроме того, как видно из схемы, выход геометрического шейдера может быть отправлен и просто в буфер памяти, а затем повторно подан на вход конвейера в произвольный момент, даже на другом кадре. Это позволяет, к примеру, однократно вычислить скелетную анимацию или морфинг для очень сложной модели, сохранить результат операции в видеопамяти, после чего многократно подавать ее на рендеринг на том же или последующих кадрах, реализуя таким образом новый метод инстансинга (instansing) объектов.
Все прочие стадии конвейера не являются чем-то новым: растеризатор преобразует трехмерную сцену в двумерное изображение с учетом перспективы и вызывает пиксельный шейдер (pixel shader, PS) для расчета цвета и Z-глубины каждого пиксела. После чего на последнем этапе сборки и вывода производятся окончательные проверки на глубину (Z test) и соответствие буферу шаблонов (stencil test, может применяться для самых разных алгоритмов, чаще для теней и отражений), в случае успеха результат пиксела сохраняется в буфер кадра или текстуру (render target).
В Direct3D 10 используется очередное поколение шейдеров – Shader Model 4.0 (SM 4.0). Среди новых возможностей: целочисленные и побитовые команды для лучшего управления логикой шейдера, снятие ограничений на количество инструкций в шейдере, увеличение лимитов на количество используемых шейдером текстур. Разработчики отказались и от поддержки низкоуровневого ассемблерного языка программирования шейдеров, теперь все шейдеры должны быть написаны на высокоуровневом языке HLSL. Сама функциональность HLSL в четвертой версии разбита на некую базовую, которую поддерживают все три типа шейдеров (VS, GS и PS), и специфическую для каждого из них. Легко видно, что такие изменения, как введение третьего типа шейдеров и унификация их базовой функциональности, лишний раз послужили толчком к переходу в новом D3D10-совместимом поколении акселераторов к унификации архитектуры GPU, когда в зависимости от нагрузки на ту или иную часть 3D-конвейера отдельные вычислительные блоки GPU временно берут на себя функции по работе над одним из трех типов шейдеров. И хотя подобная архитектура GPU не является непременным требованием со стороны спецификаций Direct3D, она оказалась вовремя поддержанной как NVIDIA в GeForce 8 series, так и AMD/ATI в еще не вышедшем R600.
В SM 4.0 было уделено особое внимание передаче константных данных в код шейдера. Через них в шейдер передавались самые разные наборы данных, например о костях модели для скелетной анимации, информация об источниках света, позиции, повороте и масштабе модели. Ранее у каждого шейдера имелся один довольно небольшой блок константных данных, его приходилось часто менять, иногда перед каждым вызовом рендеринга, постоянно перекачивая весь блок между системной и видеопамятью. В SM 4.0 константные данные разбиты на наборы, которыми можно управлять независимо и подключать к шейдеру до 16 таких наборов. Подобный подход дает немалый выигрыш в производительности, поскольку разные наборы констант можно обновлять независимо и с разной частотой. Некоторые загружаются в видеопамять единожды, сразу после загрузки уровня (например, список статических источников света), другие будут изменяться лишь один раз за кадр (положение и параметры динамических источников света в сцене), а третьи – с каждым выводимым объектом (позиция, ориентация, анимационные данные).
|