API – графические интерфейсы программ.

API Direct 3D. API OpenGL. API Microsoft DirectX.

API (Application Programming Interface) – графический интерфейс программ — предоставляeт разработчикам аппаратного и про­граммного обеспечения средства создания драйверов и программ, работающих быстрее на боль­шом числе платформ.

3D API позволяет программисту создавать трехмерное программное обеспечение, использующее все возможности 3D-ускорителей не прибегая к низкоуровнему программированию. 3D API делятся на стандартные (универсальные: OpenGL, Direct 3D и др.) и собственные (специализированные: Glide, Rredline и др.). Стандартные API поддерживают широкий спектр 3D-ускорителей и освобождает программистов от низкоуровнего программирования. Собственный 3D API предназначен для одного семейства 3D-ускорителей и ограждает программистов от низкоуровнего программирования. Использование 3D API требует применения драйверов для этого 3D API. Наличие драйверов для Direct 3D и OpenGL для Win­dows является обязательным требованием ко всем 3D-ускорителям. В настоящее время существует несколько API — OpenGL (фирма SGI), Direct 3D (фирма Microsoft) и Glide (фирма 3Dfx). Glide поддерживается только набо­ром микросхем, выпускаемым фирмой 3Dfx. Остальные API поддерживаются большинством со­временных видеоадаптеров.

API Direct 3D. Direct 3D является частью API, называемого DirectX. Современное программ­ное обеспечение широко использует графические интерфейсы Х Win­dows и OpenGL. Этот API предназначен для облегчения программирования игровых программ. Direct 3D имеет два режима: RM (Retained mode) – абстрактный и IM (Immediale) – непосредственный. IM состоит из тонкого уровня, который взаимодействует с аппаратурой и обеспечивает самое высокое быстродействие. RM является высокоуровневым интерфейсом, обеспечивающим для программиста множество графических операций, включая инициализацию и трансформацию. Большинство 3D-игр используют режим IM. В Windows Vista реализована поддержка тех же интерфейсов Direct3D и DirectDraw, как в Windows XP, начиная с DirectX 3 (за исключением режима Retained Mode в Direct3D). Существует и еще одно ограничение для полноценных 64-битных приложений Windows XP Professional x64 Edition, поддержка функций которых под Windows Vista ограничена Direct3D9, DirectDraw7 и более новыми версиями интерфейсов.

API OpenGL. API OpenGL является открытым 3D API, который поддерживается ассоциацией крупнейших фирм таких как DEC, E&S, IBM, INTEL, INTERGRAPH, Microsoft , SGI. Этот API реализует широкий диапазон функций от вывода точки, линии, полигона до рендеринга кривых поверхностей NURBS, покрытых текстурой. OpenGL-драйвер может быть реализован в трех вариантах: ICD, MCD и мини порт. ICD (Installable Client Driver) полностью включает все стадии конвейера OpenGL, что обеспечивает максимальное быстродействие, но разработка такого драйвера очень трудоемкий и сложный процесс. MCD (Mini Client Driver) разработан для внесения абстракции в конвейер OpenGL, и поэтому написание драйвера менее трудоемко (MCD работает только в Win­dows NT). Драйвер мини-порт предназначен для одной конкретной игры, обычно для GLQuake и Quake 2. Мини-порт может работать по принципу ICD(Rage Pro), через собственый API (например, Voodoo 2) или через Direct3D (например, 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 содержит слой Media, который состоит из API.

Слой Media DirectX пре­доставляет сервис для разработ­чиков игр, Web и интерактивных медиа-программ. Самая последняя версия DirectX доступна для бесплатной загрузки с Web-узла фирмы Mi­crosoft. Кроме того, DirectX является частью таких продуктов, как Internet Explorer, Win­dows 2000. Некоторые производители аппаратного обес­печения поставляют вместе со своими продуктами последнюю версию DirectX. Перед инсталляцией некоторые программы проверяют номер версии установленного про­граммного интерфейса. Если установленная версия устарела, то пользователю будет предло­жено установить последнюю версию. Программный интерфейс DirectX обратно совместим, т.е. последняя версия поддерживает функции всех предыдущих. Для корректной работы всех программ необходимо использовать последнюю версию программного интерфейса DirectX.

Этот краткий термин на слуху у всех, кто хоть как-то сталкивался с разработкой. Но далеко не все понимают, что именно он обозначает и зачем нужен. Разработчик Пётр Газаров рассказал об API простыми словами в своём блоге.

Аббревиатура API расшифровывается как «Application Programming Interface» (интерфейс программирования приложений, программный интерфейс приложения). Большинство крупных компаний на определённом этапе разрабатывают API для клиентов или для внутреннего использования. Чтобы понять, как и каким образом API применяется в разработке и бизнесе, сначала нужно разобраться, как устроена «всемирная паутина».

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

При введении в адресную строку браузера www.facebook.com на удалённый сервер Facebook отправляется соответствующий запрос. Как только браузер получает ответ, то интерпретирует код и отображает страницу.

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

Многие компании предлагают API как готовый продукт. Например, Weather Underground продаёт доступ к своему API для получения метеорологических данных.

Сценарий использования: на сайте небольшой компании есть форма для записи клиентов на приём. Компания хочет встроить в него Google Календарь, чтобы дать клиентам возможность автоматически создавать событие и вносить детали о предстоящей встрече.

Применение API: цель — сервер сайта должен напрямую обращаться к серверу Google с запросом на создание события с указанными деталями, получать ответ Google, обрабатывать его, и передавать соответствующую информацию в браузер, например, сообщение с запросом на подтверждение пользователю.

В качестве альтернативы браузер может сделать запрос к API сервера Google, минуя сервер компании.

Технически, разница в формате запроса и ответа. Чтобы сгенерировать полную веб-страницу, браузер ожидает ответ на языке разметки HTML, в то время как API Google Календаря вернёт просто данные в формате вроде JSON.

Если запрос к API делает сервер веб-сайта компании, то он и является клиентом (так же, как клиентом выступает браузер, когда пользователь открывает веб-сайт).

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

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

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

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

Такие запросы часто можно отправлять через браузер. Так как передача данных по протоколу HTTP происходит в текстовом виде, браузер всегда сможет отобразить ответ. Например, через браузер можно напрямую обратиться к API GitHub (https://api.github.com/users/petrgazarov), причём без маркера доступа, и получить вот такой ответ в формате JSON:

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

Слово «application» (прикладной, приложение) может применяться в разных значениях. В контексте API оно подразумевает:

  • фрагмент программного обеспечения с определённой функцией,
  • сервер целиком, приложение целиком или же просто отдельную часть приложения.

Любой фрагмент ПО, который можно чётко выделить из окружения, может заменять букву «А» в англоязычной аббревиатуре, и тоже может иметь некоторого рода API. Например, при внедрении в код разработчиком сторонней библиотеки, она становится частью всего приложения. Будучи самостоятельным фрагментом ПО, библиотека будет иметь некий API, который позволит ей взаимодействовать с остальным кодом приложения.

В объектно-ориентированном проектировании код представлен в виде совокупности объектов. В приложении таких объектов, взаимодействующих между собой, могут быть сотни. У каждого из них есть свой API — набор публичных свойств и методов для взаимодействия с другими объектами в приложении. Объекты могут также иметь частную, внутреннюю логику, которая скрыта от окружения и не является API.

Консорциум Khronos Group представил графический API Vulkan и язык SPIR-V, которые призваны заменить OpenGL и составить конкуренцию Direct3D 12, AMD Mantle и Apple Metal. Компании AMD и Imagination Technologies рассказали о том, чем хороши SPIR-V и Vulkan, и что они изменят в индустрии графических технологий.

*

Текущая архитектура трансляции шейдеров в Unity 5

Один из руководителей разработки OpenGL-драйверов в AMD, Грэм Селлерс, отвечая на вопрос, какие возможности даёт язык SPIR-V, сослался на статью разработчика-партнёра Кристофа Риккио, который объяснил многие непонятные моменты. Согласно его статье, в данный момент в мире существуют два основных языка программирования шейдеров — GLSL, связанный с OpenGL, и HLSL, относящийся к Microsoft Direct3D. Обладая разной структурой и своими специфическими особенностями, разработчики различных графических движков и фреймворков должны создавать особый мета-язык, который бы транслировал вызовы GLSL и HLSL между собой. Из-за этого сам процесс кросскомпиляции кода превращался в бардак, где некоторые возможности языков аннулировались из-за недостатка поддержки функций, низкого качества компиляторов, специфических оптимизаций, ведущих к непредсказуемым последствиям, недостаточной документации и других проблем. Как итог, процесс компиляции шейдера, скажем, в движке Unity 5 выглядит монструозно (на картинке выше). SPIR-V, наоборот, спроектирован таким образом, чтобы обойти подводные камни — к языку прилагается подробная документация, и SPIR-V позволяет использовать неизвестные компилятору инструкции, не превращая итоговый двоичный код в мусор. Поддержка SPIR-V позволит разработчикам безболезненно компилировать шейдеры для OpenGL, OpenGL ES, Microsoft Direct3D, Apple Metal и других API. Впрочем, чтобы решить эту головную боль разработчиков графических приложений и игр, понадобятся усилия не только Khronos Group и производителей видеокарт, но также и проектировщиков API, включая Microsoft с Direct3D, Apple с Metal, создателей консолей и других. Кроме того, господин Риккио указал на то, что ежедневно на рынок поставляются сотни тысяч смартфонов и планшетов, которые скорее всего никогда не получат обновления своих драйверов, поэтому безболезненное программирование шейдеров с помощью SPIR-V — дело отдалённой перспективы. Но главные преимущества SPIR-V — переносимость, высокая производительность, хорошая документированность, подробная спецификация и гибкая расширяемость стоят того, чтобы началась работа по его реализации.

*

Упрощение трансляции GLSL HLSL с помощью SPIR-V

Что касается более громкого анонса — API Vulkan, то о его возможностях рассказала компания Imagination Technologies, разрабатывающая графические ускорители PowerVR. По мнению инженеров компании стремление Khronos заменить OpenGL, которому уже исполнилось 22 года, на более современный API с лучшей эффективностью и предсказуемостью достойно похвалы. Для демонстрации возможностей интерфейса программирования в Imagination переписали свою демо-сцену Library с OpenGL ES 3.0 на Vulkan API. Несмотря на то, что сам API только в начале своего развития, а качество тестового драйвера оставляет желать лучшего, первые положительные тенденции были заметны сразу. Так, например, анализ загрузки ресурсов центрального процессора показал, что Vulkan менее требователен к CPU, чем OpenGL ES. Так, например, вызов glUniform*() в старом API требовал работу с буфером драйвера, из-за чего происходил так называемый оверхед, из-за чего нагружался процессор. В Vulkan такой сложный вызов не нужен, и разработчик просто может указать адрес в графической памяти записать туда нужную графическую информацию. Благодаря этому нагрузка на процессор упала с 5% до 1.3%. При проектировании Vulkan разработчики следовали цели по уменьшению самостоятельности драйвера, который мог приводить к непредсказуемым для разработчика игр последствиям. Несмотря на то, что теперь порог вхождения для разработчиков значительно повысился, и при создании шейдеров, например, нужна большая квалификация, исчезает необходимость создавать различные патчи, специфичные для драйвера каждого производителя. Теперь драйвера делает ровно то, что ему скажет разработчик, и требования к качеству драйвера значительно понизились просто потому, что создателю видеокарты просто негде допустить ошибку. Это особенно важно для мобильных устройств, где обновление драйвера GPU редчайшее событие, сравнимое с большим праздником. Обновить игру с исправлением ошибок, естественно, намного проще для владельца смартфона, чем обновить драйвер.

Как следствие упрощённых драйверов, предполагаемая производительность стала куда более предсказуемой. Инженеры Imagination приводят в пример функцию glBlendFunc(), которая крайне зависима от архитектуры GPU и обслуживающего драйвера. Например, некоторые видеокарты могут отложить конфигурацию операции смешивания до тех пор, пока не выполнится определённый шейдер, другие могут сработать иначе, из-за чего производительность одного и того же кода на разных платформах была разной даже если GPU с точки зрения производительности были идентичны. С использованием Vulkan разработчик, заполняя программную структуру, описывающую какую-либо функцию, теперь точно знает, что драйвер не вмешается в работу программного кода, благодаря чему сохраняется консистенция в показателях производительности. Кроме того, огромный прирост к производительности даёт тот факт, что Vulkan изначально спроектирован для комфортной параллелизации. Командные буферы могут разделяться по разным потокам, давая большие преимущества процессорам с большим количеством ядер. Ранее в OpenGL ES для достижения такого результата требовалась нетривиальная работа, так как во время создания этого API многоядерных мобильных систем не существовало, а дальнейшие обновления спецификации не могли решить фундаментальных проблем. Теперь же эти операции фактически автоматизированы.

*

Потребление ресурсов CPU у Vulkan и OpenGL ES

На видео ниже можно увидеть демо-сцену на одном из GPU PowerVR Rogue, на котором, конечно, видно, что предстоит очень много работы впереди. Тем не менее, Эшли Смит, один из разработчиков этой «демки», заявил о том, что несмотря на очевидные притормаживания, драйвера в аналогичной альфа-версии для OpenGL ES выглядели куда хуже, и у Vulkan куда больший потенциал.

С нашей стороны отметим, что для Vulkan API верна та же проблема, что и для SPIR-V — сейчас на рынке огромное количество мобильных устройств, которые никогда не получат обновления драйверов, и следовательно повсеместное применение Vulkan API будет отложено на несколько лет после официальной публикации спецификации. Несмотря на то, что API проектировался с учётом того, что должны поддерживаться GPU, совместимые с OpenGL ES 3.1, крайне маловероятно, что даже самые лучшие мобильные графические ускорители современности получат необходимые обновления. На данный момент под указанные условия подпадают мобильные видеокарты серий Qualcomm Adreno 4xx, Imagination PowerVR 6xxx, ARM Mali-T6xx, NVIDIA GeForce 5 ULP (Tegra K1) и новее. Наибольшие шансы на получение обновленных драйверов у Tegra K1, которая совместима с куда более функциональным API OpenGL 4.5. Для видеокарт от AMD, Intel и NVIDIA шансы на обновленные драйвера всё же значительно выше, чем у мобильных. Публикация предварительной версии спецификаций Vulkan API ожидается к концу года на конференции SIGGRAPH в августе, а её окончательная стандартизация, вероятно, состоится на конференции GDC в следующем году, и тогда же появятся первые публичные драйвера для различных видеокарт и систем.