Что не является графическим API

Что не является графическим API

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

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

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

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

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

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

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

API Microsoft DirectX. Этот программный интерфейс был разработан еще для операционных систем Windows 95, Windows 98 и Windows NT/2000 и др. С помощью этого API увеличивается быстродействие игр, деловой графики, трехмерного звука и т. д. Несмотря на то, что DirectX был предназначен для игр, он также используется в программах NetMeeting, ActiveMovie и NetShow. Поскольку DirectX относится к уровню аппаратных абстракций (Hardware Abstraction Layer — HAL), разработчикам программного обеспечения необходимо использовать функции DirectX, а не обращаться напрямую к видеоадаптеру, звуковой карте, джойстику и другому ап­паратному обеспечению.

DirectX также относится к уровню аппаратной эмуляции (Hardware Emulation Layer — HEL), что позволяет разработчику программно эмулировать те функции, ко­торые не реализованы аппаратным обеспечением. Уровень HEL «медленнее», чем HAL, но луч­ше иметь нереализованную аппаратно функцию (пусть даже медленную), чем не иметь ничего.

Отношения между аппаратным, программным обеспечением и DirectX можно продемон­стрировать следующей схемой:

(Аппаратное обеспечение) > (Direc+X) > (Програм­мное обеспечение).

Обновление DirectX можно выполнять независимо от операционной системы. DirectX состоит из «основного» слоя, который обеспечивает доступ к звуковым устройст­вам, устройствам двухмерной и трехмерной графики, уст­ройствам ввода и процедурам установки. Программный интерфейс DirectX содержит слой Media, который состоит из API.

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

Что не является графическим API

API (application programming interface) — это набор готовых классов, функций, процедур, структур и констант. Вся эта информация предоставляется самим приложением (или операционной системой). При этом пользователю не обязательно понимать, что это API технология обеспечивает взаимодействие модулей. Цель предоставленной информации – использование этих данных при взаимодействии с внешними программами.

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

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

Функции API

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

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

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

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

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

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

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

В отдельные группы выделяют интерфейсы управления графическими компонентами программных модулей (API графических интерфейсов wxWidgets, Qt, GTK и т. п.), операционными системами (Amiga ROM Kernel, Cocoa, Linux Kernel APIruen, OS/2 API, POSIX, Windows API), звуковые (DirectMusic/DirectSound, OpenAL), оконные интерфейсы и так далее. Здесь их разделение определяется уровнем приложения в иерархии и функциональностью. Пользователи компьютерных игр обычно не подозревают, что это графический API обеспечивает им такую быструю отрисовку картинки и поразительную яркость изображений.

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

Проблемы, возникающие при работе интерфейсов многоуровневых систем, разделяются на две большие группы:

  1. Трудности портирования кода программы при переходе от одной API к другой. Они часто появляются при переносе модулей в другие операционные системы.
  2. Снижения объема функциональности интерфейса при переходе к управлению с более низкого уровня на высокий. В этом случае облегчается выполнение строго определенного класса задач. При этом возможности доступа к элементам управления другими регуляторами теряются. Ведь более низкий уровень позволяет легко управлять базовыми компонентами программы.

API вебмастеров / поисковых систем

Для вебмастеров и программистов особенно важны Web API. Такие системы управления включают в себя комплект HTTP-запросов. В результате получения таких запросов модуль генерирует строго определенную структуру HTTP-ответов. Для транспортировки информации между ними принято использовать форматы XML или JSON.

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

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

Читать еще:  Fast bios mode что это в биосе

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

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

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

Обычно порядок работы интерфейса стараются передать в его названии. Мы можем не найти в поиске, что такое syngestureapisampleapp application. Но из названия понятно, что это пример работы интерфейса для единичного пользователя.

При этом нужно учитывать изменения в интерфейсах, произошедшие после массового внедрения стандартов Web 2.0. В результате был выполнен переход протокола обмена структурированными данными в распределенной вычислительной среде SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам) к архитектурному стилю взаимодействия компонентов распределенного приложения в сети REST (сокр. от англ. Representational State Transfer — «передача состояния представления»). Для многих веб-служб, в число которых входят поисковые системы и интернет-магазины, данный переход привел к упрощению архитектуры и ускорению выполнения задач. Правильная организация информационных потоков приводит к тому, что API сайта предоставляет широкие возможности автоматизации последнего.

При этом отдельные компоненты REST функционируют примерно таким же образом, как взаимодействуют между собой серверы и клиенты в Интернете. Хотя работа систем на архитектуре REST до сих пор не имеет единого стандарта, большинство RESTful-реализаций используют конкретные стандарты, такие как HTTP, URL, JSON и XML. Здесь особенно важно, что открытый API – это возможность дополнения и расширения системы взаимодействия.

Мне действительно нужно использовать графический API?

Нужно ли использовать графические API для получения аппаратного ускорения в 3D-игре? В какой степени можно освободиться от зависимостей от API-интерфейсов графических карт, таких как OpenGL, DirectX , CUDA, OpenCL или что-то еще?

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

11 ответов

Я думаю, что многие ответы пропустят важный момент: вы можете писать приложения, напрямую обращающиеся к оборудованию, , но не в современных операционных системах . Это не просто проблема времени, но проблема «у вас нет выбора».

Windows, Linux, OSX и т. д. запрещают прямое аппаратное обеспечение доступа к произвольным приложениям. Это важно по соображениям безопасности: вы не хотите, чтобы случайное приложение могло читать произвольную память GPU по той же причине, по которой вы не хотите, чтобы случайное приложение могло читать системную память. Такие вещи, как фреймбуфер для вашего банковского счета или чего еще нет в памяти GPU. Вы хотите, чтобы этот материал был изолирован и защищен, а доступ контролировался вашей ОС.

Только драйверы могут напрямую разговаривать с большинством аппаратных средств, и единственный способ поговорить с драйвером — это разоблачение ОС HAL и собственный и несовместимый интерфейс каждого драйвера. Этот интерфейс драйвера не только будет отличаться для каждого поставщика, но даже будет отличаться между версиями самого драйвера, что делает невозможным прямое общение с интерфейсом в потребительском приложении. Эти слои часто покрываются элементами управления доступом, которые дополнительно ограничивают возможность доступа приложения к ним.

Нет, ваша игра не может просто использовать оборудование напрямую, если, конечно, вы не нацеливаете небезопасные операционные системы, такие как DOS, и ваш единственный возможный вариант для игры в современных потребительских операционных системах — нацелить открытый API, такой как DirectX , OpenGL или Vulkan.

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

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

Также помните, что рендеринг ЦП неэффективен и имеет низкую производительность по сравнению с графическими процессорами.

API, такие как OpenGL или DirectX, частично реализованы операционной системой и частично реализованы самим графическим драйвером.

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

Загрузите свой компьютер в MS-DOS. Затем, используя свою копию Энциклопедии программистов для ПК , вы можете напрямую писать в карточку VESA регистрируется и записывается в видеопамять. У меня все еще есть код, который я написал 20 лет назад, чтобы сделать это и сделать рудиментарное 3D в программном обеспечении.

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

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

Более полное объяснение:

Ответ на этот вопрос — скучный да . Реальный вопрос: почему ?

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

С GPU вы получаете «лучшую» производительность, но теряете много свободы. Графические разработчики стремятся вернуть эту свободу. Следовательно, каждый день настраивается каждый день. Вы можете делать почти все, используя CUDA /OpenCL и даже шейдеры, не касаясь драйверов.

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

Однако это не означает, что вы должны быть на 100% зависимыми от одного конкретного API. Вы всегда можете кодировать свой собственный уровень абстракции и затем заменять более конкретные реализации (например, реализацию DirectX, реализацию OpenGL и т. Д.).

Даже тогда, вероятно, это не стоит. Просто выберите то, что работает достаточно хорошо для ваших целей, и сделайте это. Вы инди-разработчик игр — вам нужно сосредоточиться на том, что делает игру, а не на миниатюрах. Просто сделайте игру!

Вы хотите поговорить с оборудованием. Вам нужно использовать способ общения с оборудованием. Таким образом, это интерфейс к оборудованию. Это то, что OpenGL, DirectX, CUDA, OpenCL и все остальное.

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

Чтобы получить 3D Hardware Acceleration без использования традиционного API, вам необходимо написать собственный код, чтобы дублировать функциональность графического драйвера. Таким образом, лучший способ узнать, как это сделать, — это посмотреть на код графического драйвера.

Для карт NVIDIA вы должны посмотреть проект нуворив . У них есть коллекция больших ресурсов здесь .

Для других марок видеокарт вы можете найти похожие проекты и документацию.

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

Избавление от DirectX или OpenGl не приведет к удалению зависимостей, и это приведет к появлению большего числа из них. В других ответах уже есть несколько хороших моментов, из-за которых невозможно даже напрямую разговаривать с графическим оборудованием (по крайней мере, это невозможно), но первым ответом будет: Если бы вы действительно писали библиотеку, которая абстрагирует все обычные 3D-графики в единый API, вы бы действительно переписали DirectX /OpenGl. Если бы вы использовали свой код для написания игры, вы бы добавили новую библиотеку в новую зависимость, как и теперь у вас DirectX /OpenGl в качестве зависимости.

Читать еще:  Что значит VSCO в инстаграм

Используя DirectX или OpenGl, ваши зависимости в основном говорят: «Этот код зависит от библиотеки, чтобы предоставить код, объясняющий, как выполнять определенные команды на разных видеокартах». Если бы вы пошли без такой библиотеки, вы бы представили зависимость «Этот код зависит от графического оборудования, которое ведет себя точно так же, как и аппаратное обеспечение, которое существовало при создании игры».

Абстракции, такие как OpenGl или DirectX, позволяют производителям оборудования предоставлять собственный код (драйверы), которые приводят к общей базе кода, поэтому игры, скорее всего, будут работать на оборудовании, которое даже не существовало, когда игра была написана.

Прежде всего, CUDA и OpenCL не являются графическими. Они представляют собой apis.

Проблема с написанием собственной графики api заключается в том, что она очень сложна. Вы можете напрямую взаимодействовать с оборудованием, но нет гарантии, что если он работает с системой с X-процессором, X-графическим процессором, X-портом RAM и операционной системой X, он будет работать на системе с Y-процессором, графическим процессором Y и т. Д. Хорошим моментом является то, что DirectX работает с драйверами режима ядра. Он внедрен в ядро. Кроме того, графические apis не созданы для поддержки графических процессоров. Для их поддержки создаются графические процессоры (и их драйверы). Таким образом, вы почти не можете создавать графические api, если вы не создаете свою собственную ОС и не используете прерывания VGA с x86. Но вы все равно не сможете правильно взаимодействовать с GPU, и вы будете застревать с низким разрешением.

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

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

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

Что изменит API Vulkan в индустрии графических технологий

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

*

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

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

*

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

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

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

*

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

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

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

Читать еще:  Отсутствует Binkw32 dll что делать

UncaughtException

Что выбрать: GUI или API тесты?

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

Вопрос: Есть ли какой-то проверенное правило для того, чтобы определить, где проводить тестирование? Как понять, в каких случаях нужно выбирать уровень GUI, а в каких API?

Ответ: Не думаю, что есть какой-то универсальный совет. Но я постараюсь описать, как я рассуждаю, когда решаю, где проводить тесты.

Чтобы выбрать между GUI и API тестом, я должен понять:

  • Что я собираюсь тестировать?
  • Могу ли я изолировать тестируемую функцию на одном из «уровней»?
  • Ориентируйтесь на слово «изолировать». На мой взгляд, это и есть то самое правило номер один, про которое вы спрашиваете.
  • Тщательно протестируйте функции, которые можете изолировать
  • Далее тщательно протестируйте интеграцию для уникальной изолированной функции
  • Протестируйте интеграцию настолько тщательно, насколько того требует реализация
  • Протестируйте интеграцию на предмет непредсказуемого поведения
  • Менее подробно протестируйте моменты, в которых системы совпадают при интеграции

Например, в системе есть функция «создать пользователя», причем:

  • В GUI она является элементом интерфейса администратора
  • В API ее можно вызвать с помощью запроса в архитектуре REST

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

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

Далее я тщательно тестирую на уровне API те функции, которые изолированы в API, и менее тщательно – функции, находящиеся на пересечении GUI и API.

Также мне нужно протестировать функции, уникальные для GUI. Например, если GUI позволяет делать ajax-запросы, то тестировать эту возможность следует на уровне GUI.

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

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

Итак, мое правило можно записать в виде списка действий:

  • Постройте модель системы так, чтобы вы могли определить точки интеграции и общие «изолированные» функции;
  • Протестируйте изолированную функцию на самых нижних уровнях, которые вам доступны;
  • По очереди переходите к более высоким (или «одноранговым») уровням интеграции и абстракции и рассмотрите систему с точки зрения интеграции систем;
  • Ищите уникальные функции, присущие более высоким (или «одноранговым») уровням абстракции. Их надо тестировать именно здесь:
  • Если вы проверяете некий функционал изолированно, создавая mock-объекты интегрированных систем, то вам может понадобиться оценить технические риски и решить, нужно ли будет использовать эту функцию после интеграции, и если да, то как часто.

По-другому этот процесс можно представить вот так:

  • Создайте несколько пересекающихся моделей системы;
  • Проверьте тестовое покрытие моделей системы;
  • Проверьте тестовое покрытие потоков, идущих через разные модели системы;
  • Рассмотрите технические риски, связанные с реализацией и средой, в которой работает система;

PS. Когда я все это объясняю, люди часто сопоставляют мой способ со своей любимой моделью пирамиды. Я не использую модели пирамид. Предпочитаю создавать модель системы, с которой работаю, а не полагаться на шаблон. Другие люди, впрочем, предпочитают модели пирамид.

Новости про API

NVIDIA адаптирует RTX Ray для API Vulkan

Компания NVIDIA делает активные шаги по популяризации трассировки лучей в реальном времени.

Сейчас, презентовав технологию RTX, компания пытается заменить на неё растеризующий рендер, используемый для 3D приложений три десятка лет. В Microsoft выпустили своё дополнение к DirectX 12,названное DXR. А теперь, по данным Khronos Group, NVIDIA готовит RTX для Vulkan.

Логотип API Vulkan

Новое расширение Vulkan получило название «VK_NV_raytracing». Оно является вкладом компании в общую работу над стандартом. Это расширение вносит несколько функций NVIDIA RTX и пресетов в Vulkan. Структура кода сходна с DXR, чтобы минимизировать эффект раздвоения и снизить сложность.

Обработка графики с трассировкой лучей Создание ускоряющих структур

Khronos объединит OpenCL и Vulkan

В оригинальном пресс-релизе лишь говорится о работе «консорциума над стремлением и развитием Khronos Vulkan API в объединении современной графики и вычислений в единый API ».

Раскрыты планы работ по Vulcan Next

В ходе презентации Khronos Group на SIGGRAPH 2016, представители организации рассказали о состоянии разработки Vulkan, OpenGL и OpenGL ES . Несмотря на отсутствие заметных изменений, было рассказано о подготовке Vulkan Next — новой версии API Vulkan.

Отмечается, что разработчики продолжают работу над основной спецификацией, и некоторые из этих функций могут быть доступны в виде «расширений» для Vulkan. Пока специалисты не могут назвать даже ориентировочную дату выпуска спецификаций Vulkan Next.

Intel поддерживает Vulkan 1.0 AP

Технология Vulkan 1.0 также сможет работать и на Linux, в составе таких операционных систем, как SteamOS. Компания Intel открыла исходный код драйвера для Linux. Он будет доступен для процессоров с кодовыми именами Broadwell и Skylake.

Vulkan будет работать только с новыми GPU AMD?

Удивительно, но компания AMD, по всей видимости, по-своему понимает значение выражения «открытый исходный код». Такая догадка исходит из того, что готовящийся API Vulkan будет работать лишь с драйвером ядра AMDGPU DRM .

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

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

Vulkan API отложен до 2016 года

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

AMD лучше адаптирована для DX12

Сайт PC Perspective сравнил производительность новой видеокарты AMD Radeon R9 390X с конкурирующим решением NVIDIA GeForce GTX 980, используя новый тест Ashes of the Singularity. В результате выяснилось, что при использовании DX12 производительность карты AMD выросла значительно больше, чем у карты NVIDIA.

При использовании рендера в режиме DirectX11, карта Radeon R9 390X демонстрировала меньшую частоту кадров, по отношению к GeForce GTX 980. В то же время при использовании DX12, карта AMD смогла сравняться с «зелёным» конкурентом, продемонстрировав рывок в скорости обработки. При этом ускоритель NVIDIA таким прорывом похвастать не сумел.

Совершенно ясно, что NVIDIA оказалась в проигрыше. Компания уже заявила, что тест Ashes of the Singularity в нынешнем виде «не является хорошим индикатором общей игровой производительности в DirectX 12». И в этом есть смысл. Нельзя оценивать скорость работы видеокарты по единственному приложению. Также нельзя говорить, что разные игровые движки получат одинаковый прирост производительности при переходе от DX11 к DX12.

Исторически сложилось так, что в некоторых играх преимущество имеют карты Radeon, а в других — GeForce. В этот же раз карты показали равную производительность, при том, что продукт AMD стоит дешевле.

Valve представит новый OpenGL в марте

Сайт Tech Report отмечает, что компания Valve в ходе мартовской выставки GDC представит графический API OpenGL новой версии, который получит название glNext.

Ссылка на основную публикацию
Adblock
detector