Драйвер api что это
Аннотация: В данной лекции основное внимание уделяется драйверам устройств ввода/вывода. Приводятся практические примеры и задачи для самостоятельного рассмотрения.
Эта телефонная система LG Electronics Voice over IP (VoIP) основывается на Windows Embedded CE. Фотография с разрешения Mike Hall.
Введение в драйверы устройств В/В
Драйверы устройств помогают создать слой абстракции между оборудованием и прикладными программами пользователя. Типичный пользователь , разрабатывающий приложение , не должен понимать низко-уровневые детали оборудования каждого интерфейса. Вместо этого прикладная программа вызывает API ОС, который вызывает драйвер устройства. Работая на более высоком уровне абстракции, используя ОС и драйверы устройств, программисты приложений могут быть более продуктивными. При использовании ОС и драйверов устройств приложения можно переносить на различные аппаратные платформы с меньшими усилиями, и система будет также более стабильной и безопасной. ОС является критически важной в планировании, размещении, и управлении устройствами, которые совместно используются несколькими процессами. В качестве примера представьте, что произойдет, если два приложения начнут одновременно посылать символьные данные непосредственно оборудованию принтера. В результате получится случайная смесь символов на каждой напечатанной странице.
Большинство распространенных драйверов устройств поставляются вместе с ОС или доступны производителям микросхем, но многие нужно будет переносить на новую аппаратную платформу, так как даже небольшие изменения, такие как задание адреса порта В/В или уровня прерывания могут требовать небольших модификаций кода драйвера.
Одной из проблем, постоянно встречающейся разработчикам встроенных систем, является необходимость разработки драйверов устройств для уникального оборудования, вводимого при проектировании каждой новой платы. Документация по интерфейсам драйверов и примеры драйверов устройств поставляются с каждой ОС. Детали реализации драйверов варьируются от ОС к ОС. Может также поставляться инструмент типа мастера, помогающий сгенерировать шаблонный код, необходимый в новом драйвере устройства для правильного взаимодействия с ОС. В некоторых случаях драйверы устройств покупаются даже у сторонних разработчиков или разрабатываются внешними консультантами. Написаны целые книги по теме написания драйверов устройств. Библиотеки драйверов устройств CE перечислены в таблице 9.1.
Модель потокового интерфейса для драйверов устройств
Драйвером 1 Part of the material presented in this Chapter was obtained from or is derived from the CE 6.0 on-line help files, MEDC 2006 conference presentations by members of the Windows Embedded CE design team , and Microsoft’s Windows Embedded CE Professional Training Materials. Reprinted with Permission of Microsoft Corporation. с потоковым интерфейсом является любой драйвер, который предоставляет функции потокового интерфейса, независимо от типа устройства, которым управляет драйвер. Модель потокового интерфейса является простейшим способом реализации большинства драйверов пользователя, и приложения обращаются к ним с помощью обычных функций API файловой системы. Подобно многим свойствам ОС, подход на основе потокового интерфейса ведет свое начало из первых версий Unix.
Потоковый интерфейс подходит для любого устройства В/В, которое можно логически считать источником или стоком данных. То есть, любое периферийное устройство, которое создает или потребляет потоки данных как свою основную функцию, является хорошим кандидатом для предоставления потокового интерфейса. Примером является устройство потокового порта. Примером устройства, которое не создает и не потребляет данные в традиционном смысле, будет устройство дисплея, и действительно, для управления оборудованием дисплея потоковый интерфейс не предоставляется.
Потоковый интерфейс может использовать другой нижележащий драйвер устройства для доступа к физическим периферийным устройствам, которыми управляет драйвер, или он может обращаться к устройству непосредственно, если устройство отражено в память. Драйверы аудио-устройств для встроенного аудио-оборудования являются примером прямого доступа.
Сами функции потокового интерфейса создаются таким образом, чтобы как можно ближе соответствовать семантике обычных интерфейсов прикладного программирования (API) файловых систем, таких как CreateFile , WriteFile , ReadFile , IOControl , и CloseHandle . В качестве побочного эффекта такого дизайна устройства, которые управляются потоковым интерфейсом, доступны для приложений через файловую систему; приложения взаимодействуют с драйвером, открывая специальные файлы в файловой системе.
Драйверы потокового интерфейса могут иметь монолитную архитектуру или архитектуру с двумя слоями, MDD и PDD , как показано на рисунке 9.1.
Рис. 9.1. Две альтернативные архитектуры драйвера потокового интерфейса. Монолитный драйвер потокового интерфейса или Разделенный на слои драйвер потокового интерфейса. В разделенной на слои архитектуре драйвера в CE два слоя называются MDD и PDD
Интерпретация устройств как специальных файлов распространена во многих операционных системах, включая настольные версии Microsoft Windows и даже первые версия Unix. Там устройства печати традиционно представлялись именами специальных файлов LPTx:, а последовательные порты именами специальных файлов COMx:, и т.д.
Несмотря на базовые характеристики потокового интерфейса, его можно реализовать различным образом. Например, даже хотя потоковый интерфейс обычно создается для периферийных устройств независимыми поставщиками оборудования ( IHV ), производители оригинального оборудования (OEM) могут предоставлять потоковый интерфейс для определенных встроенных устройств.
В некоторых менее распространенных случаях драйверы потокового интерфейса могут переупаковывать существующие ресурсы, обычно таким образом, который специфические приложения смогут более легко использовать. Например, такой тип драйвера потокового интерфейса может управлять приемником системы глобального позиционирования (GPS) с последовательным интерфейсом. В этом примере ISV может выбрать создание специального драйвера потокового интерфейса для работы в соединении с приложением отображения GPS. Многие приемники GPS соединяются с последовательными портами. Приложение отображения GPS может, поэтому, открыть специальный файл COMx:, соответствующий последовательному порту и непосредственно взаимодействовать с приемником GPS.
Однако приемник GPS может предоставлять данные позиционирования в неудобном формате, или создатель приложения может захотеть сохранить скрытыми детали управления специальными моделями приемников GPS. Поэтому можно написать драйвер потокового интерфейса для обеспечения взаимодействия между приложением и приемником GPS. Драйвер будет взаимодействовать с приемником GPS как и раньше через специальный файл COMx:, но может переупаковывать данные позиционирования в более удобном формате для приложения. Драйвер может предоставлять свои собственные службы как специальный файл GPSx:, который будет открывать приложение, чтобы прочитать данные позиционирования.
Драйвер потокового интерфейса получает команды от Device Manager или из приложений посредством вызовов файловой системы. Драйвер инкапсулирует всю информацию, которая необходима для трансляции этих команд в соответствующие действия на устройствах, которыми он управляет.
Все драйверы потоковых интерфейсов, управляют ли они встроенными устройствами или устанавливаемыми устройствами, загружаются ли они во время начальной загрузки или загружаются динамически, имеют похожие взаимодействия с другими системными компонентами. Рисунок 9.2 показывает архитектуру драйверов потокового интерфейса для встроенных устройств, которые загружаются Device Manager во время начальной загрузки.
Различные вопросы могут влиять на конструктивные решения во время реализации динамически подключаемой библиотеки (DLL) драйвера потокового интерфейса. Чтобы реализовать драйвер потокового интерфейса, создайте DLL, содержащую требуемые точки входа для драйверов, и затем решите, хотите ли вы реализовать одиночный или множественный доступ к драйверу.
Можно реализовать драйвер только с точками входа Init и Deinit и без префикса устройства. Невозможно получить доступ к этому драйверу с помощью CreateFile. PCIBUS и RegEnum являются двумя примерами такого типа драйвера. Эти драйверы находятся в каталогах ..\WINCE600\Public\Common\OAK\Drivers\PCIbus и ..\WINCE600\Public\Common\ OAK\Drivers\RegEnum .
Если DEVFLAGS_NAKEDENTRIES определен в подключе реестра Flags драйвера, то имена точек входа могут быть лишены отличий; например, Open, Close, и т. д. Пример драйвера батареи, который находится в ..\WINCE600\Public\Common\OAK\Drivers\Battdrvr , является примером драйвера, который использует точки входа без отличий. Настройки реестра драйвера батареи должны тем не менее включать префикс.
Реализации этих точек входа должны объявляться для экспорта из DLL, размещая __declspec(dllexport) перед объявлением функции. При разработке в C++, точки входа должны также объявляться как внешние "C".
Таблица 9.2 показывает функции драйвера потокового интерфейса с описанием назначения каждой из них. XXX в имени каждой функции заменяется трехсимвольным именем устройства. Эти функции определяются внутренне только для менеджера устройств, а не для приложений пользователя.
Так как периферийные устройства доступны приложениям как файлы, когда создается потоковый интерфейс, то нужно предоставить реализацию такого файла. Поэтому, рассмотрите, будет ли это практично, на основе возможностей устройства, которые предоставляет драйвер, чтобы позволить нескольким приложениям иметь одновременный доступ к файлу, который представляет устройство. То есть, рассмотрите, может ли драйвер иметь несколько открытых указателей файлов на своем устройстве. Драйвер потокового интерфейса может реализовать одиночный доступ или множественный доступ, используя параметр hOpenContext, передаваемый всем функциям В/В файла.
Чтобы реализовать множественный доступ, каждый вызов функции XXX_Open должен возвращать различное значение для hOpenContext . Драйвер устройства должен отслеживать, какие возвращаемые значения из XXX_Open используются. Последующие обращения к XXX_Close , XXX_Read , XXX_Write , XXX_Seek , и XXX_IOControl передают эти значения назад драйверу устройства, позволяя драйверу идентифицировать, какими внутренними структурами данных манипулировать.
Для реализации одиночного доступа, только первый вызов XXX_Open должен возвращать действительное значение hOpenContext . Пока это значение остается действительным, что будет иметь место, пока для этого значения не будет вызвана функция XXX_Close , последующие обращения к XXX_Open должны возвращать NULL вызывающему приложению, чтобы указать на отказ.
Видеодрайверы взаимодействуют непосредственно с API (ликбез).
Правильная и полнофункциональная работа современного графического адаптера обеспечивается с помощью видеодрайвера — специального программного обеспечения, поставляемого производителем видеокарты и загружаемого в процессе запуска операционной системы. Видеодрайвер выполняет функции интерфейса между системой с запущенными в ней приложениями и видеоадаптером. Так же как и видео-BIOS, видеодрайвер организует и программно контролирует работу всех частей видеоадаптера через специальные регистры управления, доступ к которым происходит через соответствующую шину. Программный драйвер является одним из важнейших элементов видеосистемы, с помощью которого осуществляется связь программного обеспечения с видеокартой. Видеокарта может быть оснащена самым быстрым процессором и наиболее эффективной памятью, но плохой драйвер способен свести на нет все эти преимущества. Видеодрайверы используются для поддержки процессора видеоадаптера. Несмотря на то, что видеокарты поставляются изготовителем вместе с драйверами, иногда используются драйверы, поставляемые вместе с набором микросхем системной логики.
Большинство производителей видеоадаптеров и наборов микросхем системной логики имеют свои Web-серверы, где можно найти информацию о самых последних версиях драйверов. Хотя может пригодиться драйвер, поставляемый вместе с набором микросхем системной логики, желательно использовать драйверы, поставляемые производителем адаптера. API ( Application Programming Interface ) – графический интерфейс программ - предоставля e т разработчикам аппаратного и программного обеспечения средства создания драйверов и программ, работающих быстрее на большом числе платформ.
Программные драйверы разрабатываются для взаимодействия непосредственно с API, а не с операционной системой и программным обеспечением. В настоящее время существует два основных графических API - OpenGL (компания SGI) и Direct 3D (Microsoft).
Хотя производители видеоадаптеров поддерживают стандарт OpenGL, компания Microsoft предоставляет поддержку Direct3D для более комплексного API, называемого DirectX.
С DirectX 9 и выше, и последними версиями программного интерфейса, значительно расширина поддержка трехмерной графики обеспечившей улучшенные игровые возможности. Для получения дополнительной информации относительно DirectX или загрузки его последней версии можно обратиться на Web-узел DirectX компании Microsoft.
Видеодрайверы используются для поддержки процессора видеоадаптера. Несмотря на то, что видеокарты поставляются изготовителем вместе с драйверами, иногда используются драйверы, поставляемые вместе с набором микросхем системной логики. Желательно использовать драйверы, поставляемые производителем адаптера.
3 D API позволяет программисту создавать трехмерное программное обеспечение, использующее все возможности 3 D -ускорителей не прибегая к низкоуровнему программированию.
3 D API делятся на стандартные (универсальные: OpenGL , Direct 3 D и др.) и собственые (специализированные: Glide , Rredline и др.). Стандартные API поддерживают широкий спектр 3 D -ускорителей и освобождает программистов от низкоуровнего программирования. Собственный 3 D API предназначен для одного семейства 3 D -ускорителей и ограждает программистов от низкоуровнего программирования. Использование 3 D API требует применения драйверов для этого 3 D API . Наличие драйверов для Direct 3 D и OpenGL для Windows является обязательным требованием ко всем 3 D -ускорителям.
В настоящее время существует несколько API - OpenGL (фирма SGI ), Direct 3 D (фирма Microsoft ) и Glide (фирма 3 Dfx ). Glide поддерживается только набором микросхем, выпускаемым фирмой 3Dfx. Остальные API поддерживаются большинством современных видеоадаптеров.
Direct 3D является частью API , называемого DirectX . Современное программное обеспечение широко использует графические интерфейсы Х Windows и OpenGL . Этот API предназначен для облегчения программирования игровых программ. Direct 3 D имеет два режима: RM ( Retained mode ) – абстрактный и IM ( Immediale ) – непосредственный.
IM состоит из тонкого уровня, который взаимодействует с аппаратурой и обеспечивает самое высокое быстродействие.
RM является высокоуровневым интерфейсом, обеспечивающим для программиста множество графических операций, включая инициализацию и трансформацию. Большинство 3 D -игр используют режим IM .
API OpenGL является открытым 3 D API , который поддерживается ассоциацией крупнейших фирм таких как DEC , E & S , IBM , INTEL , INTERGRAPH , Microsoft , SGI . Этот API реализует широкий диапазон функций от вывода точки, линии, полигона до рендеринга кривых поверхностей NURBS , покрытых текстурой.
OpenGL-драйвер может быть реализован в трех вариантах: ICD , MCD и мини порт. ICD ( Installable Client Driver ) полностью включает все стадии конвейера OpenGL, что обеспечивает максимальное быстродействие, но разработка такого драйвера очень трудоемкий и сложный процесс. MCD ( Mini Client Driver ) разработан для внесения абстракции в конвейер OpenGL, и поэтому написание драйвера менее трудоемко. Драйвер мини-порт предназначен для одной конкретной игры, обычно для GLQuake и Quake 2. Мини-порт может работать по принципу ICD ( Rage Pro ), через собственый API (например, Voodoo 2) или через Direct 3 D (например, Intel 740). В последнем случае он называется враппером.
API Microsoft DirectX - э тот программный интерфейс был разработан еще для операционных систем Windows 95, Windows 98 и Windows NT /2000 и др. С помощью этого API увеличивается быстродействие игр, деловой графики, трехмерного звука и т.д. Несмотря на то, что DirectX был предназначен для игр, он также используется в программах NetMeeting , ActiveMovie и NetShow .
Поскольку DirectX относится к уровню аппаратных абстракций ( Hardware Abstraction Layer - HAL ), разработчикам программного обеспечения необходимо использовать функции DirectX , а не обращаться напрямую к видеоадаптеру, звуковой карте, джойстику и другому аппаратному обеспечению.
DirectX также относится к уровню аппаратной эмуляции ( Hardware Emulation Layer - HEL ), что позволяет разработчику программно эмулировать те функции, которые не реализованы аппаратным обеспечением. Уровень HEL "медленнее", чем HAL , но лучше иметь нереализованную аппаратно функцию (пусть даже медленную), чем не иметь ничего.
Отношения между аппаратным, программным обеспечением и DirectX можно продемонстрировать следующей схемой:
(Аппаратное обеспечение) - > ( Direc + X ) - > (Программное обеспечение).
Обновление DirectX можно выполнять независимо от операционной системы. DirectX состоит из "основного" слоя, который обеспечивает доступ к звуковым устройствам, устройствам двухмерной и трехмерной графики, устройствам ввода и процедурам установки.
Сейчас поколения ускорителей в видеокартах можно считать по версии DirectX, которую они поддерживают. Различают следующие поколения:
- DirectX 7 — карта не поддерживает шейдеры, все картинки рисуются наложением текстур;
- DirectX 8 — поддержка пиксельных шейдеров версий 1.0, 1.1 и 1.2, в DX 8.1 ещё и версию 1.4, поддержка вершинных шейдеров версии 1.0;
- DirectX 9 — поддержка пиксельных шейдеров версий 2.0, 2.0a и 2.0b, 3.0;
- DirectX 10 — поддержка унифицированных шейдеров версии 4.0;
- DirectX 10.1 — поддержка унифицированных шейдеров версии 4.1;
- DirectX 11 — поддержка унифицированных шейдеров версии 5.0;
- DirectX 12 — поддержка унифицированных шейдеров версии 6.0.
С выходом DirectX 11 и появлением модели поддержки API Feature Level (FLxx), видеокарты в большинстве своем перестали быть привязаны к конкретной версии DirectX.
Версия OpenGL обозначает то, какие операции графического ускорения поддерживает данная графическая карта:
- OpenGL 1.1 — Объекты текстур;
- OpenGL 1.2 — 3D-текстуры, форматы BGRA и упакованных пикселей;
- OpenGL 1.3 — Мультитекстурирование, multisampling, сжатие текстур;
- OpenGL 1.4 — Текстуры глубины;
- OpenGL 1.5 — VBO, Occlusion Querys;
- OpenGL 2.0 — GLSL 1.1, MRT, текстуры с размерами, не являющимися степенью двойки, Point Sprites, Two-sided stencil;
- OpenGL 2.1 — GLSL 1.2, Pixel Buffer Object (PBO), текстуры sRGB;
- OpenGL 3.0 — GLSL 1.3, Массивы текстур, условный рендеринг , FBO;
- OpenGL 3.1 — GLSL 1.4, Instancing, Texture Buffer Object, Uniform Buffer Object, Primitive restart;
- OpenGL 3.2 — GLSL 1.5, Geometry Shader, Multi-sampled textures Buffer Object: FBO (Frame), VBO (Vertex), PBO (Pixel), Texture, Uniform;
- OpenGL 4.0 — GLSL 4.00, Тесселяция на GPU, шейдеры с 64-битной точностью.
в Windows Vista реализована поддержка совершенно новой модели видеодрайверов, которая представляет собой основную редакцию в архитектуре видеодрайверов, начиная с введения WDM (WDM) для Windows 98. Эта переработанная модель отражает развитие видеооборудования из мира 2D-растровых операций и приложений GDI для трехмерных игр с графическим оборудованием с фиксированными функциями и, наконец, с помощью современных программируемых графических процессоров (GPU), поддерживающих широкий спектр высокопроизводительных графических приложений. Windows 7 и Windows 8 сборки в графической инфраструктуре Windows Vista, предоставляя дополнительные графические функции и интерфейсы api. в этой статье обсуждаются Windows графические функции и интерфейсы api.
История
основной API для программирования графики, начиная с ранних дней Windows, был интерфейсом графического устройства (GDI). этот API предназначен для работы с множеством двумерных устройств вывода, а также для формирования Windows пользовательского интерфейса. DirectDraw и Direct3D были представлены в качестве альтернативных API-интерфейсов для поддержки полноэкранных игр и трехмерной отрисовки как расширений существующего оборудования. Взаимодействие с GDI было сложным. Эффективное сочетание традиционных элементов GDI с элементами Direct3D было ограничено этой структурой. версия WDM в Windows XP, известная как XPDM, отражает параллельную природу GDI и Direct3D (см. рис. 1).
Рис. 1. графические api в Windows XP
В течение многих лет возможности трехмерных видеоадаптеров значительно увеличились до того места, где эта функция выделяется подавляющим большинством аппаратных средств. новая модель драйверов, Windows дисплейной модели (WDDM), переводит GPU и Direct3D в forefront, позволяя создавать совершенно новые возможности, трехмерные настольные системы, которые легко смешиваются с возможностями современных программируемых графических процессоров. При использовании WDDM видеооборудование полностью зависит от Direct3D, а все остальные графические интерфейсы взаимодействуют с видеооборудованием с помощью новой модели драйверов, ориентированной на Direct3D (см. рис. 2).
Рис. 2. графические api в Windows Vista
Direct3D 9
версия 9 DirectX впервые была выпущена для Windows в 2002 с последующими обновлениями в 2003 и 2004. Этот API представляет собой десятилетие эволюции технологий DirectX, знакомство с более мощными моделями программирования шейдеров для Direct3D и сроком погашения, основанный на тысячах поставок. Direct3D 9 является основным графическим интерфейсом в Windows Vista. он остается идеальным интерфейсом API для написания трехмерных игр и приложений, которые должны выполняться в широком спектре существующих аппаратных и Windows выпусков. Сведения о новой модели драйверов скрыты от приложений, использующих интерфейсы Direct3D 9, но в фоновом режиме операционная система использует все преимущества новых возможностей для обеспечения истинной многозадачности GPU, более эффективного управления ресурсами и надежности производительности.
чтобы обеспечить полную совместимость с более ранними версиями Windows, некоторые особенности старой модели драйверов должны быть эмулироваться даже с новой моделью видеодрайвера Windows Vista. Например, когда полноэкранное приложение теряет фокус, оно должно считать, что оно потеряло все ресурсы в видеопамяти (видеопамять) и перезагружало их, созданные как неуправляемые ресурсы, несмотря на то, что новая модель драйверов обрабатывает ресурсы прозрачно, не удаляя их из контекста устройства. Даже понятие типа ресурса управляемого и по умолчанию относится к старой модели драйвера. Еще один пример — ожидание сбоя при выделении ресурсов неуправляемого (пула по умолчанию) сверх объема доступной видеопамяти, даже несмотря на то, что новая модель драйверов может предоставлять почти неограниченное количество виртуальных видеопамятьй. из-за этих требований приложения Direct3D, работающие в Windows Vista, все равно будут принимать эти ошибки. Поэтому они ограничены возможностью использования базовых интерфейсов Direct3D 9 для полного использования некоторых функций новой модели драйверов.
в то время как новые системы, поставляемые с Windows Vista, будут включать видеокарты с драйверами WDDM, а новые драйверы для ряда популярных видеоадаптеров будут включены в Windows Vista поддерживает возможность использования старых драйверов XPDM для обновлений и корпоративных выпусков. в системах, использующих старую модель драйвера, необходимо использовать Direct3D 9 и более старые интерфейсы, и работа графической системы очень похожа на ту, что Windows XP (рис. 1). WDDM требуется, чтобы приложения использовали Direct3D 9Ex, Direct3D 10 и более поздние версии.
9Ex Direct3D
интерфейс direct3d 9Ex предоставляет доступ к небольшому расширению стандартного API Direct3D 9, предоставляющему виртуальное выделение ресурсов, новую семантику потерянных устройств и другие новые функции, доступные при работе в Windows Vista. Создавая этот расширенный объект, API Direct3D 9 использует новую семантику и, следовательно, требует, чтобы приложение использовало другую логику (и, следовательно, разные пути кода) для создания ресурсов, управления и обработки ошибок для новых типов условий. этот API доступен только в Windows Vista и требует наличия драйверов WDDM. Так как Direct3D 9Ex использует отдельный путь к API и коду драйвера, чем Direct3D 9, для поддержки этого API требуются дополнительные тестовые случаи для приложения.
Основная причина создания нового API Direct3D 9Ex — обеспечить полный доступ к новым возможностям WDDM, сохраняя совместимость с существующими приложениями Direct3D. новые приложения для 3d desktop и многие Windows Vista используют эту версию Direct3D 9, но не работают при работе на старых драйверах XPDM. поскольку API direct3d 9Ex никогда не будет отображаться в более старых версиях Windows из-за отсутствия поддержки WDDM, стандартные интерфейсы Direct3D 9 охватывают более широкий набор систем. Для высокопроизводительных приложений, которые могут использовать преимущества следующего поколения видеооборудования, совершенно новая версия 10 Direct3D предоставляет множество новых возможностей, не предоставляемых Direct3D 9Ex. В результате для игр и большинства других приложений рекомендуется использовать API Direct3D 9 или Direct3D 10.
Пакет SDK для DirectX не предоставляет образцы, заголовки или библиотеки для интерфейса Direct3D 9Ex. библиотека MSDN и Windows SDK (ранее назывались пакетом Platform SDK) содержат доступную документацию, заголовки и библиотеки.
дополнительные сведения о Direct3D 9Ex см. в статье DirectX for Windows Vista on MDSN.
Direct3D 10
чтобы полностью реализовать потенциал новой модели драйверов Windows Vista и оборудования следующего поколения, была создана совершенно новая версия API Direct3D. Хотя WDDM устраняет некоторые ограничения на производительность в существующей графической системе, Direct3D 10 становится еще больше за счет удаления узких мест проектирования в существующем API Direct3D и значительно упрощает задачу программирования GPU.
Новый API полностью исключает все аспекты, кроме фиксированных функций, заменяя их программируемыми конструкциями и значительно оптимизируя внутреннюю реализацию. Сотни битов возможностей в предыдущих версиях Direct3D были полностью устранены и заменены четко определенным набором функций, которые имеют лишь несколько необязательных сценариев использования для определенных форматов ресурсов. Создание и проверка ресурсов с интенсивным использованием ЦП теперь имеют явную семантику в новом API. Это обеспечивает гораздо более предсказуемое поведение производительности и значительно сокращает затраты на рисование. Ресурсы можно перенастроить в несколько форм, чтобы обеспечить эффективное использование на различных этапах, а набор функций накладывает гораздо меньше ограничений на сценарии использования для форматов. Существуют также новые форматы текстур с нормальным форматом блочных карт.
В новом API константы шейдера и состояние устройства являются явными ресурсами, что позволяет значительно повысить эффективность кэширования на оборудовании и значительно упростить проверку драйверов. Программируемая модель шейдеров объединена в шейдеры вершин и пикселей и стала более выразительным с помощью четко определенной вычислительной модели и набора операторов. Кроме того, для использования примитивов после этапа шейдера вершин был добавлен новый этап шейдера геометрии. Результаты работы графического процессора на стадиях шейдера вершин и геометрии конвейера можно передать в видеопамять для повторного использования, что позволяет выполнять очень сложные многопроходные операции GPU с минимальным взаимодействием ЦП.
Все эти улучшения позволяют использовать технологию графики следующего поколения и расширять возможности приложений для их отключения от загрузки GPU. Разгрузка обеспечивает более сложные выборки символов на основе GPU, ускоренные преобразования, создание теневых томов и объемы, частицы и физические системы, которые полностью основаны на GPU, являются более сложными материалами, объединенными в эффективные пакеты больших объемов, процедурная детализация, отслеживание смещения лучей в реальном времени, однопроходное создание карт Куба и многие другие методы, в то же время освобождая ресурсы ЦП для более сложных приложений.
Чтобы обеспечить этот уровень инноваций в Direct3D 10, старое оборудование не может быть выражено как частичная реализация нового интерфейса. Видеоадаптер либо может поддерживать все новые функции, либо не является платой с поддержкой Direct3D 10. Таким образом, несмотря на то, что Direct3D 9 может использовать оборудование DirectX7 с множеством отсутствующих битов и ограничений на использование, Direct3D 10 работает только с новым поколением видеоадаптеров. Чтобы приложение поддерживало старое видео оборудование, оно также должно поддерживать интерфейсы Direct3D 9. Будущие версии Direct3D будут создавать версии 10, расширяя ее до новых версий API, обеспечивая при этом более широкие возможности Direct3D 10.
Дополнительные сведения о Direct3D 10 см. в разделе Direct3D 10.
Direct3D 10,1
пакет обновления 1 (sp1) для Windows Vista расширяет API direct3d 10 с помощью direct3d 10,1, который добавляет дополнительные интерфейсы и дополнительную модель шейдера для поддержки новых аппаратных функций видеоадаптеров, поддерживающих Direct3D 10,1. Все оборудование, способное поддерживать Direct3D 10,1, также полностью поддерживает все функции Direct3D 10, а разработчики игр могут использовать дополнительные функции Direct3D 10,1, если они доступны.
Direct3D 10,1 — это графический API, используемый Windows 7 desktop.
Windows 7 и обновление Windows Vista добавляют поддержку для функций DXGI 1,1, 10level9 и WARP10 для существующего API Direct3D 10,1.
Direct3D 11
Windows 7 поддерживает новую версию direct3d, direct3d 11, основанную на проектировании API direct3d 10,1. К новым возможностям API относятся Многопотоковая визуализация и создание ресурсов, шейдер вычислений, поддержка уровней функций 10level9 и устройства WARP10 Software Rendering, а также новые функции оборудования класса Direct3D 11, такие как тесселяция, с использованием поверхности & шейдеров доменов, BC6H и BC7 форматов сжатия текстур, модели шейдеров 5,0 и динамической компоновки шейдеров. Новый API может использовать существующие видеокарты классов Direct3D 10 и 10,1, некоторые карты Direct3D 9 через уровни функций 10level9 с ограниченной поддержкой функций и последние видеокарты класса Direct3D 11 нового поколения.
в дополнение к API Direct3D 11 Windows 7 включает DXGI 1,1, Direct2D, DirectWrite и поддержку драйверов WDDM 1,1.
с помощью Direct3D 11 и связанных api также можно обновить Windows Vista (см. статью KB 971644).
Direct3D 11,1
Windows 8 расширяет API direct3d 11 с помощью direct3d 11,1. Direct3D 11,1 поддерживает все существующее оборудование, поддерживающее уровни функций 11, 10 _ x и 9 _ x, а также новый _ уровень возможностей 11 1.
помимо API-интерфейса Direct3D 11,1, Windows 8 включает в себя 1,2 DXGI, Direct2D для устройств, а также поддержку драйверов WDDM 1,2.
если вы хотите, чтобы приложения из магазина Windows могли программировать трехмерную графику с помощью DirectX, можно использовать API Direct3D 11,1. Дополнительные сведения о программировании трехмерной графики с помощью DirectX см. в статье Введение в трехмерную графику с помощью DirectX.
обновление платформы для Windows 7: доступна частичная поддержка API Direct3D 11,1 на Windows 7 или Windows Server 2008 R2 с обновлением платформы для Windows 7 . дополнительные сведения об обновлении платформы для Windows 7 см. в разделе обновление платформы для Windows 7.
OpenGL
Windows Vista, Windows 7 и Windows 8 обеспечивают ту же поддержку, что и Windows XP для opengl, что позволяет производителям видеоадаптеров предоставлять устанавливаемый драйвер клиента (ICD) для opengl, обеспечивающий поддержку аппаратного ускорения. обратите внимание, что более новые версии таких икдс необходимы для полной поддержки Windows Vista, Windows 7 или Windows 8. Если программа ICD не установлена, в большинстве случаев система вернется к программному уровню OpenGL v 1.1.
Совместимость приложений, GDI и более ранние версии Direct3D
графики Windows Vista, Windows 7 и Windows 8 предназначены для поддержки широкого спектра аппаратных и программных сценариев, позволяющих использовать новые технологии, продолжая поддерживать существующие системы. существующие графические интерфейсы, такие как GDI, GDI+ и более ранние версии Direct3D, продолжают работать в Windows Vista и Windows 7, но при этом по возможности пересопоставляются. это означает, что большинство существующих Windows приложений будут продолжать работать.
Windows Vista, Windows 7 и Windows 8 продолжают поддерживать те же интерфейсы Direct3D и DirectDraw, что и Windows XP, обратно в версию 3 DirectX (за исключением Direct3D's сохраненного режима, который был удален). как и в случае с Windows XP Professional x64 Edition, 64-разрядные машинные приложения в более новых версиях Windows ограничены интерфейсами Direct3D9, DirectDraw7 или более поздней версии. Высокопроизводительные приложения должны использовать Direct3D 9 или более поздней версии, чтобы обеспечить наиболее близкое соответствие возможностей оборудования.
Рекомендации
При выборе API для графического приложения учитывайте следующие рекомендации.
Интерфейс прикладных программ (API – Application Programming Interface) – часть ОС, через которую происходит взаимодействие ОС с приложениями, решающими задачи пользователя. API – это набор средств (обычно – процедур и функций), входящих в состав ОС, который может использоваться любой прикладной программой для обеспечения взаимодействия ее с ядром ОС, внешними устройствами и пользователем. Обычно в API входят средства, обеспечивающие выделение ресурсов, работу с файловой системой, взаимодействие с пользователем и управление работой самой ОС. Физически API обычно представляет собой одну или несколько общедоступных библиотек процедур, каждая из которых является частью ОС и может быть вызвана любой программой, выполняющейся под управлением этой ОС. Конкретный механизм вызова процедур API зависит от типа ОС.
Использование API избавляет разработчика прикладных программ от необходимости программировать ряд рутинных операций, таких как чтение файла, ввод с клавиатуры, запуск программ и многое другое. Теоретически, использование программой для работы с системой пользователями и внешними устройствами исключено API ОС обеспечивает системе полную независимость от оборудования, которое физически установлено на компьютере и от особенностей реализации ОС. Программа, работающая только через API, будет (после перекомпиляции в код нужного процессора, естественно) безо всяких изменений работать на компьютере другого типа, нежели тот, на котором она написана, если на этих компьютерах работает ОС, для которой написана программа. Таким образом, использование API обеспечивает лучшую переносимость программы.
Поскольку API, как правило, разрабатывается как универсальная библиотека, которая, по определения, должна подходить для практически всех применений, ее процедуры обычно неоптимальны для решения каждой конкретной задачи. Поэтому часть программ в некоторых ОС работает с оборудованием ЭВМ напрямую, минуя ОС и API, что может значительно увеличить производительность, но создает проблемы с работой этих программ на некоторых конкретных компьютерах.
Внешние устройства (ВУ) компьютера очень разнообразны. Для того, чтобы прикладные программы могли работать с ними. Программы, теоретически, должны содержать модули, обеспечивающие взаимодействие с каждым типом ВУ, который может встретиться. В какой-то мере эта задача решается путем стандартизации самих ВУ, что делает возможной работу со многими устройствами с помощью одного и того же программного кода. Так, например, для вывода информации на большинство матричных принтеров можно воспользоваться системой команд фирмы Epson, поскольку эта система команд поддерживается большинством аналогичных принтеров других производителей.
Однако постоянно появляются новые ВУ, которые реализуют принципиально новые возможности или делают возможным выполнение ранее поддерживаемых операций более простыми и эффективными методами. Ограничение командного языка ВУ только общим подмножеством языков всех ВУ такого типа ограничит использование специфических возможностей каждого конкретного устройства.
В связи с этим наиболее приемлемым решением проблемы взаимодействия программ и ВУ является перекладные функции непосредственного взаимодействия с ВУ на ОС. ОС должна содержать модули, умеющие работать с каждым конкретным ВУ, а программа должна работать с ВУ через API ОС. Интерфейс внешних устройств реализуется в ОС с помощью специального вида программ, называемых драйверами. Драйвер – это программа, которая обеспечивает взаимодействие между ВУ определенного типа и операционной системой.
ОС имеет строго заданный стандарт на перечень функций, которые должно выполнять устройство того или иного типа и на порядок взаимодействия с таким ВУ (то есть обобщенные интерфейс ВУ данного типа). Фактически, этот интерфейс описывает некоторое виртуальное устройство, с которым и работает ядро системы.
Драйвер пишется так, сто та его часть, с которой взаимодействует ядро ОС, полностью соответствует заданному интерфейсу виртуального ВУ. Драйвер принимает от ОС команды в стандартизированном виде, перекодирует их в команды конкретного вида ВУ и передает в ОС данные от ВУ также в стандартном формате. ОС может работать с любым ВУ, для которого имеется драйвер, реализующий стандартный протокол взаимодействия. Ядро ОС, а значит и прикладные программы, использующие API, работают с ВУ через драйвер. В результате они могут общаться с ВУ, не зная ничего о его конкретном типе, наборе команд и прочих особенностях.
Более того, некоторые функции, поддерживаемые драйвером, устройство может вообще не реализовать аппаратно. Если, в соответствии с протоколом, в данной ОС устройство данного типа обязано реализовать данную функцию, то эта функция может быть реализована не самим устройством, а его драйвером. Впрочем, и такое поведение драйвера вовсе не обязательно. Часто бывает, что ряд функций ВУ считается необязательным. Для таких функций предусматриваются средства проверки, с помощью которых обращаются к драйверу программа (или ядро ОС) могут определить поддерживается ли определенная функция. Если необходимая функция поддерживается, она используется, а если нет, то программа должна самостоятельно решить эту проблему.
Так, например, если видеоадаптер компьютера не поддерживает возможности рисования ломанных линий, но ОС требует, что такая функция была, драйвер может перекодировать запрос на рисование ломанной линии в набор из нескольких запросов на рисование отрезков и именно этот набор передать устройству. Естественно, такая реализация даст худшую производительность, чем на устройстве, аппаратно поддерживающем рисование ломанных, однако, функция все-таки будет реализована, и устройство можно будет использовать. С другой стороны, драйвер может просто отказаться рисовать ломанные. Ели функция вывода ломанных не является обязательной, система, прежде чем ее использовать, должна проверить, поддерживается ли она используемым устройством, и если нет, то выполнить рисование ломаной отрезками самостоятельно.
// Send Mode IR.ALWAYS_CONNECTED = 0; // Драйвер всегда остается подключенным, может получать и отправлять данные. IR.CONNECT_WHEN_SENDING = 1; // Драйвер подключается в момент отправлки, после отключается, может только отправлять данные.
// Script Mode IR.DIRECT_AND_SCRIPT = 0; // Можно отправлять команды через скрипт и через каналы редактора IR.SCRIPT_ONLY = 1; // Можно отправлять команды только через скрипт
// Background Mode IR.BACKGROUND_OFF = 0; // Драйвер работает только при развернутом приложении IR.BACKGROUND_ON = 1; // Драйвер работает как при развернутом приложении, так и при свернутом
IR.CreateDevice
Эта функция используется для создания драйвера.
Драйвер AV & Custom System TCP
Драйвер AV & Custom System UDP
Драйвер Custom Server TCP
Драйвер Custom Server UDP
Драйвер AMX
Драйвер KNX
Драйвер BAOS 1(770)
Драйвер BAOS 2(771/772)
Драйвер CRESTRON
IR.GetDevice
Используется для получения доступа к драйверу.
Эта функция используется для отсылки данных на устройство
Синтаксис 1: Отправление на устройство несколько переменных инструкций:
IR.GetDevice("Device_Name").Send([command_1, .. , сommand_n]);
- Device_Name - имя устройства созданного в iRidium GUI или в iRidiumScript
- command_1 - первая переменная или строка - инструкция, отправляемая на устройство
- command_n - последняя переменная или строка - инструкция, отправляемая на устройство
Синтаксис 2: Отправление на устройство массив инструкций:
IR.GetDevice("Device_Name").Send(array_command);
- Device_Name - имя устройства созданного в iRidium GUI или в iRidiumScript
- array_command - массив инструкций для отправки на устройство
При использовании HTTP драйвера, необходимо в самое начало строки добавлять тип запроса "GET,", "PUT,", "POST,":
Connect
Эта функция устанавливает соединение с устройством
- Device_Name - имя устройства созданного в iRidium GUI или в iRidiumScript
Disconnect
Эта функция разрывает соединение с устройством
- Device_Name - имя устройства созданного в iRidium GUI или в iRidiumScript
Эта функция активирует канал команды и устанавливает в него значение. Установка значения возможна только для нативных драйверов.
- Device_Name - имя устройства созданного в в Project Device Panel или в iRidiumScript
- channel - идентификатор канала(имя или порядковый номер)
- value - значение, записываемое в канал
Для HDL-BUS Pro и Domintell, используется синтаксис: IR.GetDevice("NetWork").Set("Device_Name:channel",value);
- NetWork - имя сети HDL, увидите его можно в Project Device Panel
- Device_Name - имя устройства созданного в в Project Device Panel
- channel - идентификатор канала(имя или порядковый номер)
- value - значение, записываемое в канал
InvokeAction
Эта функция отсылает инструкцию на устройство поддерживающее UPnP
- Device_Name - имя устройства созданного в iRidium GUI или в iRidiumScript
- ActionName - имя команды
- ServiceType - используемый сервис
- Arguments - список аргументов команды
Subscribe
Эта функция подписывается на события устройства поддерживающее UPnP
- Device_Name - имя устройства созданного в iRidium GUI или в iRidiumScript
- ServiceType - используемый сервис
UnSubscribe
Эта функция отписывается от события устройства поддерживающего UPnP
- Device_Name - имя устройства созданного в iRidium GUI или в iRidiumScript
- ServiceType - используемый сервис
HtmlDecode
Замена спецсимволов Html
JSON.Stringify
Эта функция преобразовывает JSON объект с строку
JSON.Parse
Эта функция преобразовывает строку в JSON объект
new XML
Эта функция создает XML объект
Синтаксис: var xml = new Xml(Text);
XML.ToString
Эта функция преобразует XML объект в строку
Синтаксис: var str = xml.ToString();
SetFeedback
Эта функция используется для записи значения (строки или числа) в канал обратной связи. Канал обратной связи должен быть заранее создан в Project Device Panel. Применяется для отображения данных получаемых от работы скриптовых драйверов.
Синтаксис: IR.GetDevice("MyDevice").SetFeedback("MyFeedbackChannel", value);
- MyDevice - имя устройства из Project Device Panel
- MyFeedbackChannel - имя канала обратной связи из Project Device Panel
- value - значение, строка или число, которое требуется записать в канал
GetFeedback
Эта функция используется для получения значения из канал обратной связи. Канал обратной связи должен быть заранее создан в Project Device Panel.
Синтаксис: IR.GetDevice("MyDevice").GetFeedback("MyFeedbackChannel");
- MyDevice - имя устройства из Project Device Panel
- MyFeedbackChannel - имя канала обратной связи из Project Device Panel
SetParameters
Эта функция используется для изменения параметров подключения драйвера к управляемому устройству. Типичный пример переключения LAN - WAN сетей.
Функция SetParameters физически не перезаписывает настройки подключения драйвера в проекте, поэтому новые параметры не сохраняется после закрытия приложения.
- MyDevice - имя устройства из Project Device Panel или созданное динамически
- NewHost - IP адрес устройства, к которому необходимо подключиться
- NewPort - Порт для подключения к устройству
Если драйвер имеет дополнительно специфические параметры, например KNX BAOS 771/772 (TCP) имеет параметр UpdateTime помимо Host и Port. Дополнительные параметры обязательно прописываются.
AMX имеет параметры DeviceID, Login, Password помимо Host и Port. Дополнительные параметры обязательно прописываются.
AV & Custom Systems (UDP) имеет параметры Script Mode, Local Port, BackGroundMode помимо Host и Port. Дополнительные параметры обязательно прописываются.
AV & Custom Systems (TCP) имеет параметры SendMode, Script Mode, BackGroundMode, помимо Host и Port.
Crestron имеет параметр NetID помимо Host и Port. Дополнительные параметры обязательно прописываются.
DuoTecno не имеет дополнительных параметров. Параметры Host и Port обязательно прописываются.
Modbus(TCP) имеет параметр UpdateTime помимо Host и Port. Дополнительные параметры обязательно прописываются.
UPnP имеет параметр DescriptionUrl помимо Host и Port. Дополнительные параметры обязательно прописываются.
KNX IP Router (KNXnet/IP) имеет параметры ConnectTime, SendTime, PingTime, Nat помимо Host и Port. Дополнительные параметры обязательно прописываются.
Параметр Nat - это переключатель 0 - выключить, 1 - включить. Включает / выключает подключения через NAT-сервер. Необходимо для работы по UDP через Интернет. По умолчанию 0.
Смена подключения LAN - WAN для HDL, скрипт, загрузить
GetCommandAtName
- DriverName(переменная или строка) - имя устройства из Project Device Panel
- CommandName(переменная или строка) - имя команды/идентификатор команды (начинается с 1)
Выходные данные:
- id: идентификатор команды
- data: hex данные команды
- name: имя команды
GetCommandAtPos
- DriverNamу(переменная или строка) - имя устройства из Project Device Panel
- CommandPos(целое число) - индекс позиции команды (начинается с 0)
Выходные данные:
- id: идентификатор команды
- data: hex данные команды
- name: имя команды
GetCommandsCount
- DriverName(переменная или строка) - имя устройства из Project Device Panel
GetFeedbackAtName
- DriverName(переменная или строка) - имя устройства из Project Device Panel
- FeedbackName(переменная или строка) - имя/идентификатор канала обратной связи (начинается с 1)
Выходные данные:
- id: идентификатор канала обратной связи
- data: hex данные канала обратной связи
- name: имя канала обратной связи
GetFeedbackAtPos
- DriverNamу(переменная или строка) - имя устройства из Project Device Panel
- FeedbackPos(целое число) - индекс позиции канала обратной связи (начинается с 0)
Выходные данные:
- id: идентификатор канала обратной связи
- data: hex данные канала обратной связи
- name: имя канала обратной связи
GetFeedbacksCount
- DriverName(переменная или строка) - имя устройства из Project Device Panel
HexArrayToAsciiString
Эта функция позволяет конвертировать массив Hex символов в ASCII строку.
Синтаксис: var l_sStr += String.fromCharCode(parseInt(in_aArray["Index"], "N"));
- Index - индекс символа массива Hex
- N - число от 2 до 36 обозначающее систему счисления
С помощью параметра система счисления вы можете указать в какой системе счисления находится число в строке. Число в результате выполнения метода будет переведено в десятичную систему счисления.
EVENT_RECEIVE_DATA
Эта событие срабатывает когда от устройства приходят данные в байт формате
Синтаксис: IR.AddListener(IR.EVENT_RECEIVE_DATA, IR.GetDevice(Device_Name), function(text)
- Device_Name - имя устройства созданного в iRidium GUI или с помощью iRidiumScript
EVENT_RECEIVE_TEXT
Эта событие срабатывает когда от устройства приходят данные в строковом формате
Синтаксис: IR.AddListener(IR.EVENT_RECEIVE_TEXT, IR.GetDevice(Device_Name), function(text)
- Device_Name - имя устройства созданного в iRidium GUI или с помощью iRidiumScript
EVENT_ONLINE
Эта событие срабатывает когда установлено соединение с устройством
Синтаксис: IR.AddListener(IR.EVENT_ONLINE , IR.GetDevice(Device_Name), function()
- Device_Name - имя устройства созданного в iRidium GUI или с помощью iRidiumScript
EVENT_OFFLINE
Эта событие срабатывает когда разорвано соединение с устройством
Синтаксис: IR.AddListener(IR.EVENT_OFFLINE , IR.GetDevice(Device_Name), function()
- Device_Name - имя устройства созданного в iRidium GUI или с помощью iRidiumScript
EVENT_TAG_CHANGE
Эта событие срабатывает при изменении тега на устройстве(только для нативных драйверов).
Синтаксис: IR.AddListener(IR.EVENT_TAG_CHANGE, IR.GetDevice(Device_Name), function(name, value)
- Device_Name - имя нативного драйвера из Project Device Panel
- name - имя измененного тега
- value - Новое значение тега
Для HDL синтаксис: IR.AddListener(IR.EVENT_TAG_CHANGE, IR.GetDevice(Network_Name), function(name, value)
- Network_Name - Имя сети HDL из Project Device Panel
- name - Переменная получающая имя устройства + двоеточие + имя измененного канала
- value - Новое значение канала
EVENT_DEVICE_FOUND
Это событие срабатывает когда iRidium находит UPnP устройства
Синтаксис: IR.AddListener(IR.EVENT_DEVICE_FOUND, 0, function(name)
- Device_Name - имя устройства созданного в iRidium GUI или с помощью iRidiumScript
- name - имя найденного устройства
EVENT_RECEIVE_EVENT
Это событие срабатывает когда происходит событие на UPnP устройстве
Синтаксис: IR.AddListener(IR.EVENT_RECEIVE_EVENT , IR.GetDevice("Device_Name"), function(type, text)
EVENT_CHANNEL_SET
Это событие срабатывает когда активируется канал
Синтаксис: IR.AddListener(IR.EVENT_CHANNEL_SET , IR.GetDevice("Device_Name"), function(Name)
Читайте также: