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

Поддержка Vulkan компанией NVIDIA непосредственно с момента его выпуска, не только на разных платформах, но и в современных играх, таких как The Talos Principle, привлекла внимание самых именитых экспертов индустрии.

“Возможность сыграть в The Talos Principle в день выпуска API – это невероятное достижение, - говорит Джон Педди (Jon Peddie), президент Jon Peddie Research. - Мультиплатформенная совместимость и полноценная поддержка драйверов для разных операционных систем, которую обеспечила NVIDIA, подтверждает ведущую роль компании в разработке API Vulkan”.

Что такое Vulkan?

Vulkan – это низкоуровневый API, который предоставляет разработчикам прямой доступ к GPU для полного контроля над его работой. Отличаясь более простыми и легкими драйверами, Vulkan демонстрирует меньшие задержки и меньшие накладные расходы при обработке графических команд (overhead) по сравнению с традиционными API OpenGL и Direct3D. Vulkan также отличается эффективной поддержкой многопоточности и позволяет многоядерным центральным процессорам более эффективно загружать графический конвейер, поднимая производительность существующего оборудования на новый уровень.

Vulkan – это первый низкоуровневый API нового поколения, который является кроссплатформенным. Разработчики могут создавать приложения для ПК, мобильных и встроенных устройств, работающих под различными операционными системами. Как и OpenGL, Vulkan – это открытый бесплатный стандарт, доступный для любой платформы. Однако NVIDIA продолжит работу над OpenGL и OpenGL ES, чтобы поддержать тех разработчиков, которые предпочитают использовать традиционные API.

Кто стоит за Vulkan?

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

Преимущества Vulkan для пользователей

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

Преимущества для геймеров–владельцев графических процессоров GeForce:

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

· NVIDIA предоставляет драйверы для Vulkan для всех видеокарт GeForce на базе архитектур Kepler и Maxwell, работающих под ОС Windows (Windows 7 и выше) и Linux.

· Владельцы GeForce смогут первыми сыграть в Vulkan-версию игры The Talos Principle – головоломку от Croteam, которая стала доступна вчера. "Мы и раньше успешно работали с командой NVIDIA в плане драйверной поддержки, но я был впечатлен их работой над Vulkan, - говорит старший программист Croteam Дин Секулик (Dean Sekuliuc). – NVIDIA оперативно предоставила нам новейшие бета-драйверы, чтобы мы могли быстро внедрить новый API в Serious Engine и сделать The Talos Principle одной из первых игр с поддержкой Vulkan. Отличная работа!"

Преимущества для разработчиков профессиональных приложений для Quadro:
· в наших драйверах Vulkan и OpenGL применяется бинарная архитектура, которая позволяет применять шейдеры GLSL в Vulkan. Разработчики могут или остаться на OpenGL, или перейти с OpenGL на Vulkan, чтобы воспользоваться преимуществами Vulkan. Например, благодаря многопоточной архитектуре Vulkan ядра CPU могут подготовить данные для GPU быстрее, чем раньше. Для приложений проектирования и создания цифрового контента это означает более высокую степень интерактивности при работе с большими моделями.

AMD Mantle | Основы API

Тема API AMD Mantle разделила сообщество ПК-геймеров на два лагеря. Существует масса мнений, информации, заблуждений и известных фактов, разобраться в которых довольно сложно. Мы хотим собрать всё воедино, причём сделать это наиболее справедливым образом. К сожалению, обсудить данную тему без применения "корпоративного" языка практически невозможно, так что давайте начнём с начала - разберёмся в определениях, подготовим почву, определимся, что и откуда нам известно.

Что такое API?

Аббревиатура API расшифровывается как application programming interface (прикладной интерфейс программирования. Ключевым является слово интерфейс. API разработан для коммуникации между приложениями.

Отличным примером является функция копирования/вставки в Windows. Когда вы копируете абзац текста из браузера в буфер обмена, а затем вставляете его в текстовый редактор, вы используете функции API. Разработчики вашего браузера включили поддержку запроса API на копирование, а программисты текстового редактора – поддержку запроса API на вставку. Две эти программы взаимодействуют друг с другом через API.

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

Если ли негативная сторона? API-интерфейсы не так эффективны, как специализированый код для прямой коммуникации между ПО. Цена удобства – повышенная нагрузка на аппаратное обеспечение и вычислительные ресурсы.

Что такое графический API-интерфейс?

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

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

Если основная цель API – это простота и удобство, почему существует несколько API?

Происхождение OpenGL связано с интерфейсом Iris GL от SGI, который появился в начале 1980-x годов. Как это ни удивительно, но компания сделала его открытым стандартом под названием API OpenGL (Open Graphics Library). Конкуренты SGI получили доступ при условии равного участия в поддержке и обновлении кода.

Даже у Microsoft было кресло в Наблюдательном совете архитектуры OpenGL (OpenGL Architecture Review Board) до 2003, когда компания перешла на свой собственный интерфейс DirectX, который сейчас пользуется гораздо большей популярностью. На данный момент DirectX используется в Windows и Xbox, поэтому обосновать выбор в пользу API от Microsoft легко, если разработчик хочет получить максимум из доступных ресурсов.

Стоит отметить, что известный программист и разработчик Джон Кармак (John Carmack) доказал, что OpenGL по-прежнему можно использовать для запуска современных игр на ПК (таких как Rage). Кроме того, OpenGL держит позиции за счёт поддержки множества платформ: Windows, Mac и Linux. Android, Windows Phone и iPhone используют OpenGL ES (Open GL for Embedded Systems). По мере роста популярности игр на мобильных платформах растёт и популярность OpenGL.

Что не так с DirectX 11 и OpenGL? Зачем понадобился ещё один графический API?

Оба стандарта имеют серьёзные расхождения, и кажется нелогичным внедрение ещё одного. Так чем же существующие стандарты не устраивают разработчиков?

И DirectX, и OpenGL создавались в прошлом тысячелетии, то есть до появления многоядерных процессоров в массовых решениях. Последнее время некоторые разработчики высказывают предположения, что эти API используют слишком много ресурсов, склонны к нестабильности и плохо масштабируются (или вообще не масштабируются) на распараллеленных платформах. Кроме того, ни один API нельзя назвать идеальным. Вам когда-нибудь приходилось обновлять видеодрайвер, чтобы игра работала правильно? Если да, то это означает, что графический API не смог выполнить функцию уровня абстракции.

Вдобавок к этому, ходили слухи, что Microsoft собирается прекратить развитие DirectX в 2013 году. В интервью с вице-президентом AMD, Роем Тейлором (Roy Taylor), было сказано, что "новый заставляет отрасль двигаться вперёд, и новым видеокартам нужно больше процессоров и оперативной памяти. Но DirectX 12 не появился. Вот и всё. Насколько нам известно, на DirectX 12 пока нет никаких планов". Кроме того, из просочившегося в Сеть электронного письма Microsoft нам известно, что кросс-платформенная среда разработки XNA Game Studio сейчас не находится в стадии активной разработки, а развитие DirectX как технологии завершено. Позже Microsoft отказалась от этих заявлений и утверждала, что это было недоразумение, но без опубликованных планов касательно DirectX 12 сообщество разработчиков забеспокоилось.

AMD утверждает, что пришла к разработке нового API, который должен решить существующие проблемы DirectX и OpenGL, вызывающие недовольство разработчиков. Ввиду того, что APU и GPU от AMD применяются в Xbox One, PlayStation 4 и множестве ПК, компания вынуждена предложить API, который можно будет использовать на различных платформах.

Предполагаемые улучшения Mantle в сравнении с OpenGL и DirectX

AMD Mantle ассоциируется с понятием "низкоуровневый". Но что оно означает? Если коротко – это синоним минимализма. API меньше, проще и, следовательно, быстрее DirectX 11 и OpenGL. Новый API от AMD, предположительно, ставит меньше условий для визуализации конкретной сцены. Таким образом, разработчик, а не API, получает управление над ресурсами, что обусловливает большую оптимизацию.

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

Проще говоря, AMD утверждает, что AMD Mantle потенциально может повысить производительность систем с медленными многоядерными центральными процессорами. А там, где CPU не является "бутылочным горлышком", AMD Mantle сможет понизить энергопотребление GPU.

AMD позиционирует себя как сторонника открытых исходных кодов. Относится ли Mantle к API с открытым кодом?

AMD Mantle не является открытым стандартом, и AMD утверждает, что и в будущем он таковым не станет. Однако представители компании заявляют, что SDK AMD Mantle будет доступен для всех к концу 2014 года без лицензионных сборов или ограничений, когда закрытая бета-версия завершится.

Нужно уточнить, что доступ к SDK – это не то же самое, что открытый исходный код. Тем не менее, в теории, Nvidia и Intel смогут написать совместимый с AMD Mantle драйвер. Однако в реальности нам это кажется маловероятным. Но лучше приберечь анализ для заключения. Дело в том, что AMD хочет сохранить контроль над AMD Mantle , чтобы оптимизировать API под архитектуру GCN и позволить разработчикам быстрее принять новые аппаратные функции, которые непрактичны для общих API, таких как DirectX и OpenGL.

Мы разобрались с основами Mantle. Что дальше?

Мы хотим протестировать API AMD Mantle и проанализировать возможности интерфейса. AMD клянётся , что ряд разработчиков работает над поддержкой AMD Mantle в таких играх, как Civilization: Beyond Earth, Star Citizen и Dragon Age: Inquisition. На момент написания статьи только три игры на рынке поддерживают AMD API: Battlefield 4 , Thief и Plants vs. Zombies: Garden Warfare. Поскольку игра Plants vs. Zombies: Garden Warfare не имеет функции тестирования AMD Mantle и использует движок Frostbite, применяемый в Battlefield 4 , мы протестируем первые две игры.

AMD Mantle | Как мы тестировали API Mantle от AMD

Можно предположить, что основная цель AMD Mantle – выжать максимум производительности из видеокарт Radeon. В принципе, так и есть. Но важно помнить, что проблема, которую должен решить интерфейс AMD Mantle , не совсем связана с графикой. Напротив, AMD Mantle должен исправить недостатки в плане эффективности, которые мешают распределению нагрузок на CPU.

Таким образом, в лучшем случае AMD Mantle нивелирует узкие места, характерные при использовании бюджетных процессоров (например, производства AMD). Для примера приведём такой сценарий: с DirectX видеокарта Radeon может обеспечить более высокое быстродействие в паре с процессором семейства Intel Core i7, чем с FX-4170 . Если AMD Mantle работает так, как предполагается, можно ожидать, что с FX-4170 производительность возрастёт и приблизится к уровню Core i7. Вряд ли скорость Core i7 заметно повысится, поскольку процессор и так достаточно быстрый, что перекрывает недочёты DirectX.

Чтобы это проверить, мы используем обширный ряд платформ и видеокарт (список приведён в таблице ниже). Все видеокарты Radeon тестируются в режиме DirectX и AMD Mantle для выявления различий. Также для сравнения мы добавили в выборку карты GeForce.

Обычно для получения показателей в тестах мы используем Fraps или FCAT. Оба решения разработаны для DirectX, и, следовательно, не работают под управлением AMD Mantle . В результате нам пришлось использовать встроенные тестовые утилиты, которыми комплектуются игры Thief и Battlefield 4 . К счастью, командная консоль движка Frostbite в Battlefield 4 достаточно мощная и позволяет получить подробные данные по колебаниям времени подачи кадра. В случае Thief мы можем получить лишь показатели частоты кадров из утилиты в комплекте с игрой, показатели же колебания времени подачи кадров не доступны.

Позже вы увидите, что для специализированного теста нам понадобится видеокарта среднего уровня с памятью 4 Гбайт. Для этих целей MSI прислала нам Radeon R9 270X Gaming 4G, оснащённую кулером Twin Frozr IV и тремя рабочими режимами: "тихий" (1050 МГц), "игровой" (1080 МГц) и "разогнанный" (1120 МГц).

Высокопроизводительные видеокарты требуют соответствующего питания, и XFX прислала нам свой блок питания PRO850W с сертификатом 80 PLUS Bronze. Модульный БП использует одну шину +12 В с силой тока 70 А. Как утверждает XFX, данная модель обеспечивает непрерывную (не пиковую) мощность до 850 Вт при температуре 50 градусов Цельсия (заметно выше, чем в большинстве корпусов).

В нашей лаборатории мы почти полностью избавились от механических жёстких дисков, и вместо них используем твердотельные накопители, для которых нехарактерны задержки, связанные с операциями ввода/вывода. Компания Samsung прислала в наши офисы накопители Samsung 840 Pro на 256 Гбайт, поэтому они у нас используются в качестве стандартных.

Подробная информация по тестам:

AMD Mantle | Тесты Thief на APU и видеокартах начального уровня

Мы начинаем с начального уровня GPU с поддержкой AMD Mantle , включая интегрированный графический процессор в APU A10-7850K . Как мы уже говорили, игра Thief не записывает колебания времени подачи кадров, поэтому мы публикуем только частоту кадров.

AMD Mantle | Тесты Thief на видеокартах среднего и высшего уровня

Мы несколько раз получили подобные значения, но так и не смогли найти разумное объяснение данному явлению. Тем не менее, не стоит забывать, что технология AMD Mantle , по заявлениям AMD, пока находится в бета-стадии. В целом, AMD Mantle повышает производительность по сравнению с DirectX.

AMD Mantle | Тесты Battlefield 4 на встроенной графике APU

Благодаря встроенной утилите захвата для измерения колебаний времени подачи кадров в Battlefield 4 , мы можем получить детальную информацию о производительности. Начнём с очень низких предустановок графики в разрешении 1600x900 точек на интегрированном APU A10-7850K .

AMD Mantle обеспечивает небольшое преимущество, хотя оно вряд ли может повлиять на решение о покупке. Нас больше удивило, что APU смог вытянуть Battlefield 4 в разрешении 1600x900 точек на частоте кадров не ниже 30 FPS.

В этом тесте мы получили идеальное колебание времени кадров как на AMD Mantle , так и на DirectX. Они очень низкие и пиков не наблюдается, поэтому картинка на экране должна быть плавной.

AMD Mantle | Тесты Battlefield 4 на видеокартах начального уровня

Теперь Radeon R7 250X и GeForce GTX 650 продемонстрируют нам, на что способны дешёвые дискретные видеокарты. Для них мы повышаем уровень детализации до высокого и увеличиваем разрешение до 1920x1080 точек.

В двух диаграммах выше видна масса линий и полос. Но в данном случае мы видим, как AMD Mantle вредит производительности, а не помогает.

Мы связались с AMD, чтобы разобраться с результатами, и представители компании рассказали нам, что у Battlefield 4 есть особая проблема с AMD Mantle , возникающая на картах, объём видеопамяти которых меньше 4 Гбайт. Тестируемая карта Radeon R7 250X имеет 1 Гбайт памяти. GeForce GTX 650 - 2 Гбайт, хотя и с AMD Mantle она не совместима. Мы скоро разберёмся с этой проблемой. Но сейчас давайте посмотрим на показатели колебаний времени подачи кадров.

Колебания находятся в приемлемом диапазоне. Ни одна из карт не вышла за отметку 3 мс на 95-ом перцентиле. Есть несколько всплесков, но они незначительны.

AMD Mantle | Тесты Battlefield 4 на видеокартах среднего уровня

Radeon R9 270 и GeForce GTX 660 , оснащённые 2 Гбайт памяти GDDR5, предоставили нам возможность либо опровергнуть, либо подтвердить слова AMD касательно проблемы AMD Mantle с картами, у которых объём видеопамяти меньше 4 Гбайт. Если это правда, мы снова должны наблюдать проблему, обнаруженную ранее. Чтобы обеспечить соответствующую нагрузку, мы повысили уровень детализации до Ultra.

Снижение производительности сохранилось. А изменились ли колебания времени подачи кадров?

Колебания сохранились на низком уровне, хотя притормаживания более заметны, когда частота кадров снижается до 25 FPS.

AMD Mantle | Тесты Battlefield 4 на видеокартах высшего уровня

Пришло время протестировать и GeForce GTX 780 Ti . Видеокарта AMD оснащена 4 Гбайт видеопамяти, так что мы должны избежать вышеупомянутой проблемы с масштабированием AMD Mantle . Мощность обеих карт подтолкнула нас повысить разрешение до 2560x1440 пикселей.

Наконец API AMD Mantle от AMD показал своё влияние, обеспечив системе с FX-8350 среднюю частоту кадров 51,4 FPS против 45 FPS под DirectX. Дополнительно AMD Mantle позволяет приблизиться к уровню производительности GeForce GTX 780 Ti (при том, что карта Nvidia значительно дороже).

Как и в других тестах Battlefield 4 , встроенная в игру утилита по измерению колебаний времени подачи кадров показывает высокий уровень производительности.

AMD Mantle | Тесты Battlefield 4: проблемы с RAM и обновления драйверов

Как уже сказано выше, мы оповестили AMD о проблеме AMD Mantle с Battlefield 4 и нам ответили, что существует преграда, из-за которой производительность снижается на видеокартах с видеопамятью менее 4 Гбайт под управлением AMD Mantle . Чтобы изучить проблему, мы взяли MSI Radeon R9 270X с 4 Гбайт видеопамяти GDDR5. Поможет ли дополнительный объём памяти справиться с недостатками?

Хотя снижения производительности, которое вызывал AMD Mantle ранее, больше не наблюдается, ощутимых преимуществ тоже нет.

Мы снова видим очень низкие средние колебания времени подачи кадров, перебиваемые внезапными всплесками.

Похоже, что видеопамять – не единственный сдерживающий фактор. По крайней мере, в Battlefield 4 AMD Mantle демонстрирует преимущество над DirectX на высокопроизводительных видеокартах с объёмом видеопамяти более 4 Гбайт. Дополнительная память GDDR5 не помогает Radeon R9 270X повысить свой результат под управлением API от AMD.

Обзор получился очень насыщенным в плане бенчмарков, он включает тесты множества видеокарт на различных платформах. Мы начали создавать данный материал, когда самым новым из доступных драйверов была версия Catalyst 14.4, но использовали Catalyst 14.3 Beta, поскольку были случаи, когда драйвер 14.4 ухудшал производительность.

По завершении тестирования мы провели немало времени за дополнительными исследованиями. Полученные данные мы обсудили с AMD. Сотрудники компании сказали про наличие проблемы с видеопамятью до 4 Гбайт. Нужно было кое-что выяснить об API. В общем, пока мы собирали материал, для Battlefield 4 вышло обновление, датированное третьим июня, а AMD выпустила драйвер версии Catalyst 14.6 Beta.

Нужно было убедиться, что показатели производительности AMD Mantle остались актуальными, поэтому мы провели несколько тестов с учётом обновлений и выяснили, что производительность Battlefield 4 под управлением AMD Mantle улучшилась на графических адаптерах, у которых менее 4 Гбайт видеопамяти. Плохие новости заключаются в том, что при уменьшении разрыва API от AMD по-прежнему немного медленнее DirectX 11 по частоте кадров. Даже несмотря на минимальный разброс, AMD Mantle не даёт преимуществ на картах ниже уровня Radeon R9 290.

Какой же можно сделать вывод? Графические ускорители Radeon с объёмом памяти менее 4 Гбайт не получают ускорение при включении AMD Mantle в Battlefield 4 . Однако с новым драйвером и игровым патчем разница становится меньше, чем с пакетом 14.3 Beta. Это обнадёживающий результат, поскольку он говорит о том, что AMD и DICE работают над API. Но также мы видим, сколько ещё усилий потребуется для дальнейшего совершенствования. Мы надеемся, что AMD Mantle Radeon R9 270X с 4 Гбайт, и хотя интерфейс AMD Mantle не снизил производительность, он также не обеспечил никаких преимуществ. По словам AMD, API сейчас находится в стадии бета-разработки, поэтому такие аномалии вполне возможны.

В любом случае, если учесть большую часть наших тестов и заявления разработчика, становится ясно, что AMD Mantle предлагает определённые преимущества по сравнению с DirectX 11. У нас нет игр на базе OpenGL для сравнения, но утверждается, что оба графических API имеют ограничения по сравнению с AMD Mantle . Что это значит для энтузиастов мира ПК?

В краткосрочной и среднесрочной перспективе AMD Mantle сможет обеспечить прирост производительности владельцам карт Radeon на архитектуре GCN в небольшом числе видеоигр. Прирост будет минимален на платформах с процессорами уровня Intel Core i7. Но на системах с дешёвыми процессорами, такими как FX-4170 , APU A10 и Athlon X4, прибавка скорости будет гораздо выразительнее.

В следующем месяце список игр с поддержкой AMD Mantle расширится, но даже в этом случае он будет очень мал. Разработчики, которые считают DirectX 11 слишком ограниченным интерфейсом для их движка, могут инвестировать в код AMD Mantle . Естественно, дополнительная работа требует дополнительных ресурсов. Таким образом, на данный момент AMD Mantle является эквивалентом Nvidia PhysX, которая обеспечивает преимущество в некоторых играх.

Идём дальше. Когда AMD представит SDK AMD Mantle , то теоретически появится возможность разработки совместимых с AMD Mantle драйверов со стороны Intel и Nvidia, что может привлечь независимых разработчиков ПО. Но это кажется маловероятным. Не имеет смысла цеплять свою "телегу" к "лошади" конкурента. Как сообщается, Intel просила доступ к SDK AMD Mantle , но, скорее всего, в целях внутреннего тестирования.

Руководство AMD стоит перед сложным выбором. Будет ли место для AMD Mantle , когда появится DirectX 12 с собственным минималистским подходом и возможностью выполнять задачи прорисовки одновременно на нескольких ядрах CPU? Кажется довольно очевидным, что Intel и Nvidia примут решение Microsoft. Мы полагаем, что если AMD Mantle будет обладать хорошей совместимостью с DirectX 12, разработчики Microsoft захотят потратить своё время на его поддержку. Но AMD неизбежно будет поддерживать и DirectX 12, так что работа может оказаться избыточной. По мере распространения DirectX основным преимуществом AMD Mantle станет возможность быстро предоставлять разработчикам любые эксклюзивные функции Radeon, например, 3dfx Glide.

Сегодня мы в основном говорим о ПК, но не стоит забывать о консолях. Если Microsoft и Sony внедрят AMD Mantle на своих платформах, то с комплектующими AMD, использующими x86-ядра Jaguar, данный API почти наверняка получит мощную поддержку со стороны разработчиков. Многие ПК-игры портируются с консольных версий или разрабатываются одновременно с ними. Естественно, у Microsoft есть стимул дождаться готовности DirectX 12. Что касается Sony, то у PlayStation 4 имеется собственный API, более совершенный, чем DirectX 11 и OpenGL. Ведущий графический программист DICE Йоган Андерсон (Johan Andersson) заявил, что графический API-интерфейс PS4 достаточно хорош, и AMD Mantle на PS4 им не нужен.

Пока неизвестна позиция Steambox от Valve. AMD не поддерживает AMD Mantle в драйвере Linux, однако компания намекнула на реализацию поддержки в будущем. Если предположить, что Valve создаст концепцию выгодного использования APU (пока мы её не видим), спрос на AMD Mantle в этой среде может возрасти. Однако SteamOS придётся пройти долгий путь, прежде чем это случится.

В то же время, AMD Mantle действительно представляет собой инновацию. Даже если его затмит DirectX 12, есть все основная полагать, что AMD Mantle сподвигнет Microsoft на разработку графических API следующего поколения. Очевидно, что существуют реальная необходимость и желание искоренить недостатки и ограничения старых API, негативно влияющих на игровой опыт. Конечно, трудно продвигать новый продукт на рынок, но пока AMD не начнёт делать более заметные шаги в этой индустрии, мы вынуждены рассматривать AMD Mantle как дополнительную функцию наподобие PhysX (естественно, не в техническим плане), поскольку она даёт преимущество только одному производителю в некоторых играх.

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

Энциклопедичный 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

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

  На 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
  Добавить метки

  зуются более высокой степенью сжатия, чем изображения с низким содержанием таких элементов (например, графики, схемы, простые текстуры). Изображения с высоким разрешением можно сжимать с высокой степенью сжатия, не влияя на их качество. Для сохранения высокого качества изображений с низким разрешением итоговая степень сжатия должна быть гораздо ниже. Изображения с большой глубиной цвета (например, 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.