На WWDC 2014 всех нас ждал сюрприз: анонс нового графического 3D API под названием Metal. Но на этот раз мы имеем дело не с новым высокоуровневым API поверх OpenGL ES (как было в случае с Scene Kit), а с новым низкоуровневым API для рендеринга и вычислений, которое может служить заменой OpenGL в играх. По словам Apple, Metal может быть до 10 раз быстрее, чем OpenGL ES (точнее говоря - может генерировать вызовы отрисовки [draw calls ; передача данных на GPU] в 10 раз быстрее) и доступен только на устройствах с iOS и процессором последнего поколения A7.

Этот анонс спровоцировал новую волну обсуждения и споров насчет необходимости появления новых графических API, которые должны (или не должны - кто знает) заменить OpenGL. Предлагаемый вашему вниманию пост не намерен участвовать в этой дискуссии – его целью является разъяснение того, чем все-таки Metal отличается от OpenGL ES, чьей заменой он является. Чтобы понять, что такого особенного (или же наоборот, ничего особенного) есть в Metal API, нам придется немного заглянуть под «капот» графических API и GPU.

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

Для простого улучшения в работе GPU этот процесс стоит запустить асинхронно; тогда GPU не будет блокировать CPU и вызовы API будут возвращать результат почти мгновенно. В этом случае GPU возможно не будет использоваться на все 100%, поскольку ему возможно придется ждать от CPU новых вызовов рендеринга (= начала кадра), в то время как вызовы остальных команд будут ждать завершения предыдущих. Это становится причиной того, почему большинство графических драйверов собирают все вызовы отрисовки (и другие задачи, которые нужно будет выполнить на GPU - например, изменение состояний) для отрисовки всего кадра перед отправкой его на GPU. Эти буферизованные команды будут затем отосланы обратно после того, как будет получена команда для отрисовки следующего кадра, благодаря чему GPU будет использоваться настолько эффективно, насколько это возможно. Конечно, это добавит один кадр задержки: пока CPU будет создавать задание для текущего фрейма, прошлый фрейм будет рендериться на GPU. На самом деле, можно буферизовать больше одного кадра и таким образом добиваться большей частоты смены кадров - за счет еще большей задержки.

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

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

В приложении, один поток актуальных команд для одного кадра, которые надо выполнить на GPU, формируется и отправляется на GPU сразу весь за один раз (на самом деле все немного сложнее, но давайте не будет пока углубляться).

Подробнее прочитать о том, как работает современный пайплайн компьютерной графики вы можете в серии статей Fabian Giesens - “A trip down the Graphics Pipeline “.

Почему у другой программной модели могут быть преимущества
Как вы уже увидели, от программиста спрятано огромное количество сложностей и хитрых трюков (их наверняка еще больше, чем я упомянул), которые прячут то, что непосредственно происходит. Одни из них делают жизнь простого разработчика проще, другие - заставляют его искать способы обхитрить драйвер или «копать» в сторону побочных эффектов работы вызовов API.

Некоторые графические API сегодня пытаются убрать большую часть этих трюков, раскрывая скрываемую ими «запутанность» – и в некоторых случаях оставляя на волю программы решение всех связанных проблем. В этом направлении шли графические API PS3, в нем же идет AMD со своим Mantle, туда же собираются грядущие DirectX 12 и Apple Metal.

Что же изменилось?
Буферы команд теперь открыты и приложение должно заполнять эти буферы и отправлять их в очередь команд, которая будет выполнять эти буферы в заданном порядке на GPI - таким образом приложение будет иметь полный контроль над заданием, отправляемым на GPU, и определять, сколько кадров задержки необходимо добавить (добавляя задержку, но при этом увеличивая степень используемости GPU). Буферизация команд на GPU и отправка их асинхронно в следующий фрейм должна быть реализована самим приложением.

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

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

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

Есть нюанс и в заточке под A7 - благодаря ему Metal заточен под работу на системах с общей памятью, т.е. CPU и GPU могут получать прямой доступ к одним данным без необходимости перебрасывать их по шине PCI. Metal дает прямой доступ для программы к буферам из CPU, и ответственность за то, что эти данные не используются одновременно и GPU, ложится на плечи программиста. Эта полезная функция позволяет смешивать произведение вычислений на GPU и CPU.

И как это в 10 раз быстрее?
Каждый вызов отрисовки стоит сколько-то времени на CPU и сколько-то времени на GPU. Metal API уменьшает время, затрачиваемое CPU, благодаря упрощению контроля за состояниями и благодаря этому уменьшению числу проверок на ошибки от драйвера на правильность комбинаций состояний. Еще помогает предварительное вычисление состояний: можно не просто выполнять проверку на ошибки во время билда, но и само изменения состояния потребует меньшее количество вызовов API. Возможность параллельного построения буферов команд еще больше увеличивает число вызовов отрисовки в том случае, если приложение привязано к CPU.

А вот рендеринг на GPU с другой стороны быстрее не становится, приложение которое делает совсем немного вызовов отрисовки для больших мешей (меш - часть модели, состоящая из вершин объекта] не получит никакого преимущества от перехода на Metal.

Может ли то же самое быть сделано на OpenGL?
На GDC 14 была отличная презентация “Approaching Zero Driver Overhead ” за авторством Cass Everitt, John McDonald, Graham Sellers и Tim Foley. Основной ее идеей было уменьшение работы драйвера в OpenGL при помощи увеличения количества работы, производимым вызовов отрисовки, и использованием новых объектов GL и меньшего количества числа вызовов GL для повышения эффективности.

Эта и другие идеи потребуют дальнейшего расширения OpenGL и появления новых версий этого API, но многое из этого можно будет перенести в OpenGL ES. Что мы потеряем - так это возможность прямого управления командными буферами, со всеми своими «за» и «против».

Какова вероятность увидеть это в будущем? Из-за поддержки обратной совместимости, остается надеяться только на появление некоего набора функций, который можно будет назвать «современное ядро», но и его скорее всего придется сделать совместимым со всем вплоть до оригинальной функции glBegin(). Это ограничение будет действовать на протяжении всего потенциального будущего OpenGL и станет пределом его эволюции, делая альтернативы вроде Metal API все более предпочитаемыми…

Теги:

  • Metal API
  • Apple
  • opengl
Добавить метки

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

Энциклопедичный YouTube

  • 1 / 5

    API определяет функциональность, которую предоставляет программа (модуль , библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.

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

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

    По такому принципу построены протоколы передачи данных по Интернет . Стандартный стек протоколов (сетевая модель OSI) содержит 7 уровней (от физического уровня передачи бит до уровня протоколов приложений, подобных протоколам HTTP и IMAP). Каждый уровень пользуется функциональностью предыдущего («нижележащего») уровня передачи данных и, в свою очередь, предоставляет нужную функциональность следующему («вышележащему») уровню.

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

    API библиотеки функций и классов включает в себя описание сигнатур и семантики функций .

    Сигнатура функции

    Иногда различают сигнатуру вызова и сигнатуру реализации функции. Сигнатура вызова обычно составляется по синтаксической конструкции вызова функции с учётом сигнатуры области видимости данной функции, имени функции, последовательности фактических типов аргументов в вызове и типе результата. В сигнатуре реализации обычно участвуют некоторые элементы из синтаксической конструкции объявления функции: спецификатор области видимости функции, её имя и последовательность формальных типов аргументов.

    Например, в языке программирования C++ простая функция однозначно опознаётся компилятором по её имени и последовательности типов её аргументов, что составляет сигнатуру функции в этом языке. Если функция является методом некоторого класса, то в сигнатуре будет участвовать и имя класса.

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

    С другой стороны, отличия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности - написание «промежуточных» API (API графических интерфейсов wxWidgets , , GTK и т. п.), написание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой ОС (такие среды исполнения, как Wine , cygwin и т. п.), введение стандартов кодирования в языках программирования (например, стандартная библиотека языка C), написание интерпретируемых языков, реализуемых на разных платформах ( , python , perl , php , tcl , Java и т. д.).

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

    Например: для того, чтобы увидеть в браузере строчку «Hello, world! », достаточно лишь создать HTML -документ с минимальным заголовком и простейшим телом, содержащим данную строку. Когда браузер откроет этот документ , программа-браузер передаст имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы, та, в свою очередь, при помощи API операционной системы прочитает этот файл и разберётся в его устройстве, затем последовательно вызовет через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать „Hello, world!“ выбранным шрифтом». Во время выполнения этих операций библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, уже эта библиотека обратится к API операционной системы, чтобы записать данные в буфер видеокарты .

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

    Основными сложностями существующих многоуровневых систем API, таким образом, являются:

    • Сложность портирования программного кода с одной системы API на другую (например, при смене ОС);
    • Потеря функциональности при переходе с более низкого уровня на более высокий. Грубо говоря, каждый «слой» API создаётся для облегчения выполнения некоторого стандартного набора операций. Но при этом реально затрудняется, либо становится принципиально невозможным выполнение некоторых других операций, которые предоставляет более низкий уровень API.

    Наиболее известные API

    Операционных систем

    зуются более высокой степенью сжатия, чем изображения с низким содержанием таких элементов (например, графики, схемы, простые текстуры). Изображения с высоким разрешением можно сжимать с высокой степенью сжатия, не влияя на их качество. Для сохранения высокого качества изображений с низким разрешением итоговая степень сжатия должна быть гораздо ниже. Изображения с большой глубиной цвета (например, 24-битовые Truecolor-изображения) сжимаются более эффективно, чем изображения с меньшим количеством бит на пиксель (в частности, 8-битовые полутоновые).

    Большинство других методов сжатия с потерями по своему характеру симметричны. Это значит, что они основаны на использовании конкретной последовательности операций, которые при распаковке выполняются в обратном порядке. На сжатие и распаковку данных требуется приблизительно одинаковое время. Фрактальное сжатие – процесс асимметричный, сжатие длится гораздо дольше, чем распаковка. Отсюда следует, что фрактально сжатые данные целесообразно применять в тех случаях, когда файлы изображений часто распаковываются, но никогда не сжимаются, например, при хранении изображений в графических базах данных на CD-ROM.

    Ниже кратко рассмотрены некоторые наиболее распространенные форма-

    Современные графические API-интерфейсы

    Разработка современных сложных графических программ, особенно 3Dприложений, неразрывно связана с использованием API-интерфейсов

    (Application Programming Interface).

    API – это набор библиотек, представляющих собой готовый интерфейс для работы программы с 3D-акселераторами. В настоящее время подобных ин-

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

    Универсальные API являются общими для всех 3D-акселераторов, а поддержка аппаратного ускорения для этих API возлагается на сами ускорители. В первую очередь здесь следует выделитьMicrosoft DirectX иOpenGL . Оба они используются, в основном, в программах компьютерной анимации.

    Специализированные API предназначены для работы с графическими акселераторами, построенными на определенных 3D-чипсетах; наиболее известными среди них являютсяGlide API – интерфейс для работы с чипами VooDoo® ;Metal – для чипов Savage3D и т.п. Программы, написанные с использованием специализированных API, работают только на тех акселераторах, под которые создавались эти API. Большинство специализированных API предоставляет только низкоуровневый интерфейс программирования, однако в последнее время, новые версии DirectX включают интерфейсы высокоуровневой поддержки, такие какDirectX for VisualBasic , который осуществляет языковую поддержку мультимедиа-приложений, написанных в среде визуального программирования Visual Basic.

    API Microsoft DirectX

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

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

    тами, трехмерной анимацией и стереозвуком. Встроенный непосредственно в ядро ОС Windows интерфейс DirectX является интегрированным сервисом

    Windows 98 и Windows 2000, а также Microsoft Internet Explorer. Компоненты

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

    Во-первых, DirectX превращает разработанные с его помощью приложения в программы, совместимые с любой версией Windows и работающие на любом компьютере, где установлена эта операционная система, независимо от типа используемого программного обеспечения. При этом подобные приложения максимально используют технические возможности компьютера, обеспечивая наивысшую производительность. Это достигается за счет сервиса, предоставляемого двумя основными компонентами DirectX: низкоуровневыми интерфейсами, входящими в состав DirectX Foundation, и высокоуровневыми интерфейсами, составляющими DirectX Media.

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

    DirectX Foundation предоставляет в распоряжение разработчиков набор низкоуровневых программных интерфейсов, который обеспечивает эффективный доступ ко всем возможностям компьютера, работающего под управлением ОS Windows, реализованным на уровне аппаратного обеспечения – 3Dускорителям, звуковым картам, устройствам ввода информации. До появления DirectX разработчики, создававшие мультимедийные приложения для платформы Windows, должны были настраивать свои программы на работу с различными типами устройств и конфигураций. Теперь эта проблема устранена. DirectX Foundation содержит компонент, известный как "слой аппаратной абстракции" (Hardware Abstraction Layer, HAL), который использует программные

    драйверы для обеспечения взаимодействия программных и аппаратных средств. В результате разработчики могут создавать единую версию приложения с использованием интерфейсов DirectX, не заботясь о том, чтобы оно работало на конкретных аппаратных конфигурациях. DirectX автоматически определяет технические возможности компьютера и устанавливает соответствующие параметры. DirectX также позволяет выполнять мультимедийные приложения, требующие аппаратной поддержки, отсутствующей на данном компьютере. В этом случае они программно эмулируются компонентом, который называется "слой аппаратной эмуляции" (Hardware Emulation Layer, HEL) и обеспечивает программные драйверы, работающие как недостающие устройства.

    DirectX Media располагается над DirectX Foundation и обеспечивает высокоуровневые сервисы – поддержку анимации, потоковый вывод (возможность передачи и просмотра аудио- и видеоинформации по мере ее загрузки из Internet) и интерактивность. Автоматическая интеграция низкоуровневых сервисов, реализуемых DirectX Foundation, и высокоуровневых, реализованных в DirectX Media, облегчает процесс создания и воспроизведения мультимедийных элементов, позволяя разработчикам включать их в свои приложения и Web-страницы и обеспечивая тем самым недоступное ранее интерактивное мультимедийное содержимое. Кроме того, DirectX Media помогает решить задачу координации различных типов мультимедийных эффектов, облегчая синхронизацию их воспроизведения. Помимо двух указанных основных составляющих Microsoft DirectX в их состав также входят высокоуровневые компоненты, которые обеспечивают мультимедийные функции для Webприложений. К ним относятся:NetMeeting - средство для организации групповых онлайновых дискуссий иWindows Media Player - средство для передачи мультимедийного содержимого по Internet. Рассмотрим кратко основные ком-

    поненты DirectX Foundation. К ним относятся Microsoft DirectDraw, Direct3D (режимыImmediate иRetained ), DirectInput , DirectMusic , DirectSound ,

    DirectSound 3D иDirectPlay . Эти программные интерфейсы системного уровня

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

    Microsoft Direct3D представляет собой интерфейс для работы с 3Dвидеокартами. Архитектура Direct3D представлена на рисунке 1.5.

    Win32-приложение

    Direct3D поддерживает два режима работы – Immediate Mode иRetained Mode . В режимеImmediate Mode Direct3D обеспечивает разработчикам аппаратную поддержку игровых и мультимедийных приложений в среде Microsoft Windows. Он позволяет добиться аппаратной независимости, поддерживает переключаемую Z-буферизацию и Intel ММХ-архитектуру процессоров. В этом режиме основные графические примитивы реализуются напрямую, без использования буферов выполнения (execute buffers).

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

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

    Следует отметить, что Direct3D-приложения общаются с графическими устройствами одинаково, вне зависимости от режима. Они могут использовать или не использовать программную эмуляцию перед обращением к HAL. Реально Direct3D тесно интегрирован с компонентом DirectDraw, поэтому на рисунке 1.2 слой аппаратной абстракции HAL обозначен как DirectDraw/Direct3D HAL. Direct3D осуществляет Z-буферизацию и рендеринг поверхностей, а их непосредственное отображение выполняет DirectDraw. СОМ-интерфейс Direct3D является интерфейсом к DirectDraw.

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

    На рисунке 1.6 показано взаимодействие между DirectDraw, компонентом ядра операционной системы GDI (Graphics Device Interface), слоем аппаратной абстракции (Hardware Abstraction Layer, HAL), и слоем аппаратной эмуляции

    (Hardware Emulation Layer, HEL). Как видно, DirectDraw существует независи-

    мо от GDI и оба интерфейса обладают возможностью прямого доступа к графическим устройствам через аппаратно-независимые слои. В отличие от GDI DirectDraw no возможности использует аппаратные функции. Если конкретное устройство не поддерживает требуемых функций, DirectDraw пытается их эмулировать, используя HEL. DirectDraw поддерживает работу с большим числом дисплейных адаптеров - от простых мониторов до сложных профессиональных устройств. Работая на уровне графических поверхностей, DirectDraw служит

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

    Win32-приложение

    tion Layer (HEL)

    Abstraction Layer

    Видеокарта

    Рисунок 1.6 – Интеграция DirectDraw в систему

    DirectInput представляет собой интерфейс к различным устройствам ввода информации - клавиатуре, манипулятору типа «мышь», джойстику, а также к устройствам с обратной отдачей (force-feedback). По сравнению с обычными, стандартными функциями данный интерфейс поддерживает большее число устройств и обеспечивает более быструю реакцию на запросы. Работая непосредственно с драйверами устройств, DirectInput не использует систему обмена сообщениями Microsoft Windows.

    К новым возможностям DirectInput относится расширенный список поддерживаемых устройств, в том числе: игровые панели (game pads), авиацион-

    ные рули (flight yokes), шлемы виртуальной реальности (virtual-reality headgear)

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

    DirectMusic – это новый компонент семейства технологий DirectX, представляющий собой программную оболочку для создания музыкальных шаблонов и инструкций по реакции на действия пользователя. Это позволяет разработчикам создавать фоновую музыку в реальном времени на основе алгоритмов, задаваемых в Web-страницах или мультимедийных приложениях. DirectMusic обеспечивает полную реализацию стандарта DownLoadable Sounds (DLS), позволяющего разработчикам создавать музыкальные шаблоны, воспроизводимые практически на любой аппаратной платформе. В состав DirectMusic входит DirectMusic Producer - интегрированный редактор, позволяющий работать со всеми объектами DirectMusic: стилями, шаблонами, DLSинструментами и т.д.

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

    В дополнение к низкоуровневым интерфейсам DirectX Foundation в состав DirectX входит более высокоуровневый набор программных интерфейсов

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

    DirectShow (ранее назывался ActiveMovieSDK); DirectAnimation(ранее назывался ActiveX Animation); DirectX Transform. Отметим, что сервисы DirectX Media используют сервисы DirectX Foundation.

    API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.

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

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

    По такому принципу построены протоколы передачи данных по . Стандартный протокол Internet (сетевая модель OSI) содержит 7 уровней (от физического уровня передачи пакетов бит до уровня протоколов приложений, подобных протоколам HTTP и IMAP). Каждый уровень пользуется функциональностью предыдущего уровня передачи данных и, в свою очередь, предоставляет нужную функциональность следующему уровню.

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

    API библиотеки функций и классов включает в себя описание сигнатур и семантики функций .

    Application Programming Interface (API) программный интерфейс взаимодействия между системами, позволяющий:

    • Получать доступ к бизнес-сервисам предприятия
    • Обмениваться информацией между системами и приложениями
    • Упростить взаимодействие между компаниями, партнерами, разработчиками и клиентами

    Open API стратегия

    API стратегия включает в себя:

    • Разработку бизнес-продуктов на основе существующих API
    • Предоставление внутренних сервисов разработчикам
    • Модели монетизации API для построения мультиканального взаимодействия и повышения прибыли

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

    Рынок интеграционных решений развивается в контексте эволюции API - от EDI и SOAP до Web 2.0 , с которого началась эра публичных API. Число таких интерфейсов в ближайшие 3 года может вырасти более чем в 50 раза и достичь 1 миллиона. Это связано с мультиканальностью: каналы взаимодействия с клиентами должны меняться вместе с ними. Непрерывный рост количества потребителей и объема данных привел к появлению экономики API, помогающей на основе открытых интерфейсов создавать инновационные бизнес-модели использования корпоративных активов и сервисов.

    Сигнатура функции

    Сигнатура функции - часть общего объявления функции, позволяющая средствам трансляции идентифицировать функцию среди других. В различных языках программирования существуют разные представления о сигнатуре функции, что также тесно связано с возможностями перегрузки функции в этих языках.

    Иногда различают сигнатуру вызова и сигнатуру реализации функции. Сигнатура вызова обычно составляется по синтаксической конструкции вызова функции с учётом сигнатуры области видимости данной функции, имени функции, последовательности фактических типов аргументов в вызове и типе результата. В сигнатуре реализации обычно участвуют некоторые элементы из синтаксической конструкции объявления функции: спецификатор области видимости функции, её имя и последовательность формальных типов аргументов.

    Например, в языке программирования Си++ простая функция однозначно опознаётся компилятором по её имени и последовательности типов её аргументов, что составляет сигнатуру функции в этом языке. Если функция является методом некоторого класса, то в сигнатуре будет учаcтвовать и имя класса.

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

    Например: для того, чтобы увидеть в браузере строчку «Hello, world!» достаточно лишь создать HTML -документ с минимальным заголовком, и простейшим телом, содержащим данную строку. Что произойдёт, когда браузер откроет этот документ ? Программа-браузер передаст имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы, та, в свою очередь, при помощи API операционной системы прочитает этот файл, и разберётся в его устройстве, повызывает через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать выбранным шрифтом Hello, world!», при этих операциях библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, уже эта библиотека обратится к API операционной системы с запросами вида «а положи-ка мне в буфер видеокарты вот это».

    При этом практически на каждом из уровней реально существует несколько возможных альтернативных API. Например: мы могли бы писать исходный документ не на HTML , а на LaTeX, для отображения могли бы использовать любой браузер. Различные браузеры, вообще говоря, используют различные HTML-библиотеки, и, кроме того, всё это может быть (вообще говоря) собрано с использованием различных библиотек примитивов и на различных операционных системах.

    Основными сложностями существующих многоуровневых систем API, таким образом, являются:

    • Сложность портирования программного кода с одной системы API на другую (например, при смене ОС);
    • Потеря функциональности при переходе с более низкого уровня на более высокий. Грубо говоря, каждый «слой» API создаётся для облегчения выполнения некоторого стандартного набора операций. Но при этом реально затрудняется, либо становится принципиально невозможным выполнение некоторых других операций, которые предоставляет более низкий уровень API.

    Основные типы API

    Внутренние API

    • Доступ к API предоставляется только внутренним разработчикам
    • Приложения нацелены на сотрудников предприятия

    Бизнес-драйверы:

    • Консистентность разработки
    • Снижение затрат
    • Повышение эффективности разработки

    Партнерские API

    • API доступны только ограниченному набору бизнес-партнеров
    • Приложения предназначены для конечных потребителей и для бизнес-пользователей

    Бизнес-драйверы:

    • Автоматизация процесса разработки
    • Развитие партнерских отношений
    • Оптимизация процесса взаимодействия с партнерами

    Публичные API

    Доступ предоставляется любому внешнему разработчику Приложения нацелены на конечных пользователей

    Бизнес-драйверы:

    • Разработка новых сервисов
    • Развитие экосистемы
    • Мультиканальное взаимодействие

    Наиболее известные API

    API операционных систем

    API графических интерфейсов

    • Direct3D (часть DirectX)
    • DirectDraw (часть DirectX)

    На минувшей неделе был представлен API Vulkan, о широкой поддержке которого заявили AMD и NVIDIA. Новый графический интерфейс разрабатывал Khronos Group, консорциум, основанный в 2000 году. Khronos Group отвечает за разработку и поддержку открытых стандартов в сфере мультимедийных приложений на разных платформах и устройствах. Консорциум поддерживают AMD и NVIDIA, а также многие другие компании.

    На минувшей неделе была ратифицирована финальная версия 1.0 API Vulkan. AMD и NVIDIA представили соответствующие бета-драйверы. AMD заранее выпустила бета-версию Radeon Software еще 14 февраля. NVIDIA представила драйвер GeForce 356.39, который тоже ориентирован на поддержку API Vulkan.

    Подход API Vulkan очень похож на API Mantle. Суть заключается в том, чтобы разработчики получили более глубокий доступ к «железу», чтобы выжать из него максимум. Такой подход позволяет максимально избежать существующих «узких мест». С другой стороны, разработчики должны точно знать, что они делают – например, при работе с памятью. Интерфейс OpenGL не так популярен, как DirectX, но позволяет выжать больше.

    Интерфейс API Vulkan в версии 1.0 поддерживается под Windows 7, Windows 8.1, Windows 10, Android и Linux. Разработчики игр пока что не объявили о поддержки в конкретных играх, но здесь стоит дождаться Games Developer Conference, которая будет проводиться с 14 по 18 марта в Сан-Франциско. Из игровых движков пока есть информация о Source 2, который уже поддерживает API Vulkan. Процесс отладки облегчается поддержкой Valve, LunarG и Codeplay.

    The Talos Principle

    Хорошо, но какая игра или движок поддерживают API Vulkan? Игра The Talos Principle разрабатывалась компанией Croteam, которая и в прошлом была известна поддержкой многих графических API. И в последней итерации игра The Talos Principle не стала исключением – она поддерживает DirectX 9, DirectX 11, OpenGL и теперь Vulkan. Для студии разработчиков Vulkan является пробным шаром, хотя API Vulkan доступен в версии 1.0, поддержка пока находится в бета-стадии. На добавление поддержки разработчики Croteam затратили порядка трех месяцев. Но универсальный характер API позволяет вскоре представить вариант Linux.

    API Vulkan теоретически совместим с несколькими платформами – но пока что тесты и сравнения можно провести только под Windows, причем здесь имеются свои ограничения. Реализация пока остается на очень раннем этапе. Путь рендеринга DirectX 11 совершенствовался многие годы, поэтому потенциала для оптимизации здесь уже нет. Здесь ситуация больше зависит от разработчиков драйверов, а именно AMD и NVIDIA. Игра The Talos Principle стала первой с поддержкой Vulkan. Поэтому пока нет возможности сделать сравнительный тест для оценки хорошей или плохой реализации поддержки.

    Новые технологии первое время реализуются в примерах, подготовленных производителями. В случае DirectX 12 акцент был выставлен на Draw Calls, тот же тест 3DMark DirectX 12 опирается только на измерение производительности Draw Calls, игры DirectX 12, подобные Star Wars, тоже пытаются задействовать подобную нагрузку. Но The Talos Principle не так сильно зависит от высокой скорости Draw Call, чтобы низкоуровневый API дал большую разницу.

    Поддержка API Vulkan версии 1.0 находится на ранней стадии, то же самое касается драйверов AMD и NVIDIA. Оба драйвера, по сути, относятся к бета-версиям, именно так их рассматривают производители GPU. Здесь обычно нет новых улучшений производительности или поддержки новых технологий, так что мы получаем шаг назад. Но как только определенный уровень разработки будет достигнут, драйверы обоих разработчиков GPU получат поддержку Vulkan в финальной версии. Когда это произойдет – не совсем понятно. Но пока ключевые приложения не используют Vulkan и игры с поддержкой API находятся в состоянии бета-версии, так что разработчики GPU могут спокойно дорабатывать свои драйверы.

    Для тестов мы взяли нашу тестовую систему для видеокарт. Драйверы видеокарт AMD и NVIDIA мы уже описали выше. В настройках мы выставили максимальный уровень графики, но при этом протестировали и низкие разрешения вплоть до 1.280 x 720 пикселей, чтобы увеличить производительность Draw Call.

    Тест The Talos Principle - 1.280 x 720 пикселей

    Тест The Talos Principle - 2.560 x 1.440 пикселей

    Тест The Talos Principle - 3.840 x 2.160 пикселей

    Как можно видеть по результатам, API Vulkan дает существенный прирост по сравнению с OpenGL. Но до производительности DirectX 11 новый API не дотягивает. Тому есть несколько причин. С одной стороны, разработка под Vulkan находится в ранней стадии. Это касается и самого API, и драйвера, и игры The Talos Principle. По сравнению с OpenGL новый интерфейс позволяет освободить часть ресурсов и избежать «узких мест». Но DirectX много лет совершенствовался до текущего уровня. В любом случае, потенциал у API Vulkan очень хороший.

    Если погрузиться в детали, то визуальных отличий между API Vulkan и DirectX 11 мы не обнаружили. Так что путь рендеринга очень хорошо адаптирован. У текущей реализации The Talos Principle видеокарты с 2 Гбайт памяти получают падение производительности, вероятно, из-за не самой эффективной работы с памятью. Как и Mantle и DirectX 12, API Vulkan может обращаться к ресурсам памяти на более глубоком уровне – сей факт можно рассматривать как преимущество, но он может стать и недостатком, если разработчики не смогут эффективно использовать память.

    Несколько разочаровала ошибка в текущем драйвере NVIDIA, из-за которой после каждого теста приходилось перезагружать систему. Без перезагрузки игра «вылетала». Хотя с драйвером AMD мы не обнаруживали подобной ошибки.

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