Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Периферийные устройства _ЧАСТЬ_1_Осокин.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
14.85 Mб
Скачать

4.7.4. Интерфейс прикладного программирования (api)

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

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

  • эффективное преобразование запросов прикладной программы в оптимизированную последовательность низкоуровневых команд 3 D-акселератора с учетом особенностей его аппаратного построения;

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

Специальный пакет служебных программ для выполнения этих функций называется интерфейсом прикладного программирования (Application Program Interface = API).

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

В настоящее время в 3D существует несколько API, области применения которых довольно четко разграничены:

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

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

Фирменные (native – родные) API, создаваемые производителями 3D-акселераторов исключительно для своих Chipset с целью наиболее эффективного использования их возможностей.

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

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

Полная версия OpenGL-совместимого драйвера носит название ICD (Installable Client Driver – драйвер приложения-клиента). Он обеспечивает максимальное быстродействие, т.к. содержит низкоуровневые коды, обеспечивающие поддержку не только базового набора функций, но и его расширений. Естественно, что с учетом концепции OpenGL создание подобного драйвера – исключительно сложный и трудоемкий процесс. Это одна из причин более высокой стоимости профессиональных 3D-акселераторов по сравнению с игровыми.

Усеченная версия OpenGL-совместимого драйвера называется MCD (Mini Client Driver). Он содержит оптимизированный код лишь для некоторых этапов 3D-конвейера, поэтому акселератор под управлением работает медленнее. Как правило, драйверы типа MCD поставляются с первыми версиями новых ускорителей, а полноценные ICD появляются позже.