API – графические интерфейсы программ.
API – графические интерфейсы программ.
API Direct 3D. API OpenGL. API Microsoft DirectX.
API Direct 3D. Direct 3D является частью API, называемого DirectX. Современное программное обеспечение широко использует графические интерфейсы Х Windows и 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 и более новыми версиями интерфейсов.
Отношения между аппаратным, программным обеспечением и DirectX можно продемонстрировать следующей схемой:
(Аппаратное обеспечение) > (Direc+X) > (Программное обеспечение).
Обновление DirectX можно выполнять независимо от операционной системы. DirectX состоит из «основного» слоя, который обеспечивает доступ к звуковым устройствам, устройствам двухмерной и трехмерной графики, устройствам ввода и процедурам установки. Программный интерфейс DirectX содержит слой Media, который состоит из API.
Слой Media DirectX предоставляет сервис для разработчиков игр, Web и интерактивных медиа-программ. Самая последняя версия DirectX доступна для бесплатной загрузки с Web-узла фирмы Microsoft. Кроме того, DirectX является частью таких продуктов, как Internet Explorer, Windows 2000. Некоторые производители аппаратного обеспечения поставляют вместе со своими продуктами последнюю версию DirectX. Перед инсталляцией некоторые программы проверяют номер версии установленного программного интерфейса. Если установленная версия устарела, то пользователю будет предложено установить последнюю версию. Программный интерфейс DirectX обратно совместим, т.е. последняя версия поддерживает функции всех предыдущих. Для корректной работы всех программ необходимо использовать последнюю версию программного интерфейса DirectX.
Знакомство с графовыми API
Привет, Хабр! Мы не перестаем отслеживать тему проектирования API после того, как встретили в портфеле издательства «Manning» вот эту книгу. Сегодня мы решили опубликовать обзорную статью об относительно новых Graph API и предлагаем еще раз задуматься о том, каковы будут новые API после безраздельной популярности REST.
Приятного чтения!
Если в последние 10 лет вам доводилось потреблять API – готов поспорить, что это был REST API. Вероятно, данные были структурированы вокруг ресурсов, в отклики включались id, указывающие на связанные объекты, а при помощи HTTP-команд сообщалось, как поступить с информацией: прочитать, записать и обновить (да, согласен, это вольное определение, а не канонический REST Роя Филдинга). Некоторое время API в стиле REST были доминирующим стандартом в нашей индустрии.
Однако, у REST есть свои проблемы. Клиент может привыкнуть извлекать лишние данные, запрашивая целый ресурс в случае, когда ему нужны лишь один-два фрагмента информации. Либо клиенту могут регулярно требоваться несколько объектов одновременно, но он не может извлечь их все в одном запросе – тогда возникает так называемое «недоизвлечение» данных. Что касается поддержки, изменения в REST API могут приводить к тому, что клиенту потребуется обновить всю интеграцию, чтобы программа соответствовала новой структуре API или схемам откликов.
Для решения подобных проблем в последние годы все активнее разрабатываются принципиально иные API, именуемые «графовыми».
Что такое Graph API?
В графовом API клиент формулирует вызов таким образом, что данные со всех трех ресурсов вытягиваются в один заход. Клиент также может указать те поля, которые для него действительно важны, предоставив более полный контроль над схемой отклика.
Чтобы детально исследовать, как устроен этот механизм, рассмотрим пару кейсов с описанием живых невыдуманных API.
Кейс 1: Графовый API Facebook
Facebook выпустил версию 1.0 своего API в 2010 году и с тех пор проектирует новые версии, вдохновляясь примером графовых баз данных. Существуют узлы, соответствующие, например, постам и комментариям, а также ребра, соединяющие их и указывающие, что данный комментарий «относится» к этому посту. Такой подход обеспечивает всей конструкции не менее качественную обнаружимость, чем у типичного REST API, однако, все равно позволяет клиенту оптимизировать извлечение данных. Возьмем в качестве примера отдельный пост и рассмотрим, какие простые операции можно с ним проделать.
Для начала клиент при помощи запроса GET выбирает пост из корня API, исходя из ID поста.
По умолчанию в таком случае возвращается большинство полей верхнего уровня данного поста. Если клиенту требуется доступ лишь к некоторым элементам поста – например, заголовку и времени создания – то можно запросить только эти поля, указав данную информацию в качестве одного из параметров запроса:
Чтобы выбрать требуемые данные, клиент запрашивает ребро, например, комментарии к посту:
До сих пор все это напоминает функции REST API. Пожалуй, возможность задать подмножество полей – в новинку, но в целом данные воспринимаются во многом как ресурсы. Ситуация становится интереснее, когда клиент собирает вложенный запрос. Вот как еще клиент может выбрать комментарии к посту:
Вышеприведенный запрос возвращает отклик, в котором содержится время создания поста, его заголовок и список комментариев (из каждого сообщения выбирается только id и сообщение). В REST вы бы такое сделать не смогли. Клиенту потребовалось бы сначала выбрать пост, а затем — комментарии.
А что, если клиенту потребуются более глубокие вложения?
В этом запросе выбираются комментарии к посту, в том числе, id и имя автора каждого комментария. Рассмотрим, как это делалось бы в REST. Клиенту потребовалось бы запросить пост, запросить комментарии, а затем в серии отдельных запросов извлечь информацию об авторе каждого комментария. Сразу набирается множество HTTP-вызовов! Однако, при проектировании в виде графа вся эта информация конденсируется в одном вызове, и в этом вызове оказывается лишь та информация, что нужна клиенту.
Наконец, последний момент, который следует отметить о графовом проектировании: любой объект, выбираемый с ребра, сам является узлом и, следовательно, его можно запросить непосредственно. Вот, например, как выбирается дополнительная информация о конкретном комментарии:
Обратите внимание: клиенту не нужно собирать URL вида /posts/
Кейс 2: GitHub V4 GraphQL API
Другим конкурентом графового API можно считать спецификацию под названием GraphQL. Эта концепция значительно отличается от REST, здесь предоставляется всего одна конечная точка, принимающая запросы GET и POST. При всех взаимодействиях с API отправляются запросы, соответствующие синтаксису GraphQL.
В мае 2017 года GitHub выпустил 4-ю версию своего API, соответствующую этой спецификации. Чтобы попробовать, каков из себя GraphQL, давайте рассмотрим отдельные операции, которые можно проделать с репозиторием.
Чтобы выбрать репозиторий, клиент определяет запрос GraphQL:
В данном запросе выбирается ID и описание репозитория “transformer” с ресурса Zapier org. Здесь следует отметить несколько вещей. Во-первых, мы считываем данные с API при помощи POST, поскольку посылаем в запросе тело сообщения. Во-вторых, полезная нагрузка самого запроса записана в формате JSON, что предписано в стандарте GraphQL. В-третьих, структура запроса будет именно такой, какая указана в нашем запросе, <"data": <"repository": <"id": "MDEwOlJlcG9zaXRvcnk1MDEzODA0MQ==", "description": ". ">>> (корневой ключ data – еще один обязательный элемент, который должен присутствовать в откликах GraphQL).
Чтобы выбрать данные, относящиеся к репозиторию – например, задачи и их авторов, клиент применяет вложенный запрос:
Этот запрос выхватывает ID и описание репозитория, название и текст последних 20 задач, созданных в репозитории, а также логин (имя) автора каждой задачи. То есть, в каждом запросе укладывается масса информации. Вообразите, как выглядел бы REST-эквивалент такого запроса – и становится понятно, какие возможности и гибкость обеспечивает клиентам GraphQL в данном отношении.
При обновлении данных GraphQL использует концепцию под названием «мутация». В отличие от REST, где обновление выполняется путем PUT или POST измененной копии ресурса на ту же конечную точку, с которой клиент ее извлек, мутация GraphQL – это явная операция, определяемая API. Если клиенту требуется подкорректировать данные, то требуется знать, какие мутации поддерживаются на сервере. Удобно, что GraphQL позволяет обнаруживать их в рамках процесса под названием «интроспекция схемы».
При наличии подробной схемы GraphQL в обязательном порядке требует, чтобы клиент имел возможность запрашивать эту схему в соответствии с синтаксисом GraphQL. Таким образом клиент может узнать возможности API путем интроспекции.
Если клиенту требуется узнать, какие мутации возможны в GitHub, можно просто запросить:
Надеюсь, эти кейсы наглядно демонстрируют, как развивается дизайн API в SaaS-индустрии. Я не пытаюсь сказать, что за графовыми API будущее, а REST мертв. В таких архитектурах как GraphQL есть собственные проблемы. Но хорошо, что круг возможностей ширится, и в следующий раз, когда вам потребуется создать API, вы сможете взвесить все компромиссы, на которые приходится идти при том или ином варианте дизайна, и выбрать оптимальное решение.
Graphics APIs in Windows
WindowsВ Vista includes support for an entirely new display driver model that represents a major revision in the design of video drivers since the introduction of the Windows Driver Model (WDM) for Windows 98. This redesigned model reflects the evolution of video hardware from the world of 2D raster operations and GDI applications to that of 3D games with fixed-function graphics hardware, and finally to that of the modern programmable graphics processing unit (GPU) that supports a wide-range of high-performance graphics applications. WindowsВ 7 and WindowsВ 8 build on the WindowsВ Vista graphics infrastructure by providing additional graphics features and APIs. This articles discusses Windows graphics features and APIs.
Background
The primary API for programming graphics since the early days of Windows has been the Graphical Device Interface (GDI). This API was designed to handle numerous 2D output devices, and it formed the basis for the Windows user interface experience. DirectDraw and Direct3D were introduced as alternative APIs to support full-screen games and 3D rendering as extensions to the existing hardware of the time. Interactions with GDI were complicated. The effective intermixing of traditional GDI elements with Direct3D elements has been limited by this design. The Windows XP version of WDM, known as XPDM, reflects the side-by-side nature of GDI and Direct3D (see Figure 1).
Figure 1. Graphics APIs in Windows XP
Over the years, the power of 3D video cards has grown dramatically to the point where the vast majority of hardware is dedicated to this function. A new driver model, Windows Display Driver Model (WDDM), brings the GPU and Direct3D to the forefront, allowing the creation of an entirely new experience, the 3D desktop, that seamlessly blends the 2D world of GDI with the power of modern programmable GPUs. With WDDM, the video hardware is driven entirely by Direct3D, and all other graphics interfaces communicate with the video hardware via the new Direct3D–centric driver model (see Figure 2).
Figure 2. Graphics APIs in Windows Vista
For more information about the WDDM, see Windows Vista Display Driver Model (WDDM) Design Guide on MSDN.
Direct3D 9
Version 9 of DirectX was first released for Windows in 2002, with subsequent updates in 2003 and 2004. This API represents a decade of evolution of the DirectX technologies, the introduction of more powerful shader programming models for Direct3D, and a maturity backed by thousands of shipping titles. Direct3D 9 is the primary graphics interface on Windows Vista. It remains the ideal API to use for writing 3D games and applications that need to run on the broad range of existing hardware and Windows releases. The details of the new driver model are hidden from applications using the Direct3D 9 interfaces, but behind the scenes the operating system is taking full advantage of the new capabilities to provide true multitasking of the GPU, more efficient resource management, and robust performance.
To ensure full compatibility with older versions of Windows, some quirks of the old driver model must be emulated even with the new Windows Vista display driver model. For example, when a full-screen application loses focus, it must assume it has lost all the resources in video memory (VRAM) and reload those it created as unmanaged resources even though the new driver model handles the resources transparently without evicting them from the device context. Even the concept of a managed vs. default resource type is specific to the old driver model. Another example is the expectation of failure when allocating unmanaged (default pool) resources in excess of the amount of VRAM available, even though the new driver model can provide a nearly unlimited amount of virtual video memory. Because of these requirements, Direct3D applications running on Windows Vista will still receive these error conditions. Thus, they are limited in their ability to use the basic Direct3D 9 interfaces to fully use some features of the new driver model.
While new systems shipping with Windows Vista will include video cards with WDDM drivers, and new drivers for a number of popular video cards are included in the box, Windows Vista continues to support the ability to use older XPDM drivers for upgrades and corporate editions. On systems using the old driver model, Direct3D 9 and older interfaces must be used, and the operation of the graphics system is very similar to that of Windows XP (Figure 1). WDDM is required for applications to use Direct3D 9Ex, Direct3D 10, and later versions.
Direct3D 9Ex
The Direct3D 9Ex interface provides access to a slight extension of the standard Direct3D 9 API that exposes the virtualized resource allocation, new lost device semantics, and some other new features available while running on Windows Vista. By creating this extended object, the Direct3D 9 API uses the new semantics, and therefore requires the application to use different logic (and therefore different code paths) for resource creation, management, and error handling for new kinds of conditions. This API is only available on Windows Vista, and it requires WDDM drivers. Because Direct3D 9Ex uses a separate API and driver code path than Direct3D 9, supporting this API requires additional test cases for your application.
The primary reason for creating the new Direct3D 9Ex API was to allow full access to the new capabilities of WDDM while maintaining compatibility for existing Direct3D applications. The new 3D desktop and many Windows Vista-specific applications make use of this version of Direct3D 9, but they are not functional when running on older XPDM drivers. Because the Direct3D 9Ex API will never appear on older versions of Windows due to a lack of support for the WDDM, the standard Direct3D 9 interfaces cover a much broader set of systems. For high-performance applications that can take advantage of the next generation of video hardware, the entirely new version 10 of Direct3D provides many new capabilities not exposed by Direct3D 9Ex. As a result, for games and most other applications, Direct3D 9 or Direct3D 10 is the recommended API.
The DirectX SDK does not provide samples, headers, or libraries for the Direct3D 9Ex interface. The MSDN Library and Windows SDK (formerly known as the Platform SDK) contain the available documentation, headers, and libraries.
For more information about Direct3D 9Ex, see DirectX for Windows Vista on MDSN.
Direct3D 10
To fully realize the potential of the new Windows Vista driver model and next-generation hardware, an entirely new version of the Direct3D API has been created. While WDDM eliminates some of the limitations on performance in the existing graphics system, Direct3D 10 goes further by removing design bottlenecks in the existing Direct3D API, and greatly simplifies the task of programming the GPU.
The new API completely eliminates all but a few fixed-function aspects, replacing them with programmable constructs and greatly streamlining the internal implementation. The hundreds of capability bits in previous versions of Direct3D have been completely eliminated and replaced with a well-defined, inclusive set of functionality that has only a few optional usage scenarios for specific resource formats. CPU-intensive resource creation and validation now have explicit semantics in the new API. This allows for much more predictable performance behavior, and greatly reduced per-draw overhead. Resources can be reconfigured into multiple forms to allow efficient use at various stages, and the feature set imposes far fewer restrictions on usage scenarios for formats. There are also new block-compressed normal-map texture formats.
In the new API, shader constants and device state are explicit resources, allowing for far more efficient caching on the hardware and greatly simplified driver validation. The programmable shader model has been unified across both vertex and pixel shaders, and made more expressive with a well-defined computational model and operator set. Also, a new geometry shader stage has been added to operate on primitives after the vertex shader stage. The results of the GPU’s work in the vertex and geometry shader stages of the pipeline can be streamed out to video RAM for reuse, allowing for the possibility of extremely complex multi-pass GPU operations with minimal CPU interaction.
All of these enhancements enable next-generation graphics technology and expand the ability of applications to off-load work to the GPU. Offloading allows more complex GPU-based character skinning, accelerated morphing techniques, shadow volume generation and extrusion, particle and physics systems that are entirely GPU-based, more complex materials combined into efficient large-draw batches, procedural detailing, real-time ray-traced displacement mapping, single-pass cube-map generation, and many more techniques—all while freeing up CPU resources for more complex applications.
To provide this level of innovation in Direct3D 10, older hardware cannot be expressed as a partial implementation of a new interface. A video card is either capable of supporting all of the new features, or it’s not a Direct3D 10–capable card. Therefore, while Direct3D 9 could drive DirectX7-era hardware with many missing capability bits and usage limitations, Direct3D 10 only works on a new generation of video cards. For an application to support older video hardware, it must also support the Direct3D 9 interfaces. Future versions of Direct3D will build on version 10, extending it to new versions of the API while ensuring a strict superset of Direct3D 10 functionality.
For more information about Direct3D 10, see Direct3D 10.
Direct3D 10.1
Windows Vista Service Pack 1 extends the Direct3D 10 API with Direct3D 10.1, which adds optional interfaces and an additional shader model to support new hardware features of video cards that support Direct3D 10.1. All hardware that is capable of supporting Direct3D 10.1 also fully supports all features of Direct3D 10, and game developers can make use of the additional features of Direct3D 10.1, when available.
Direct3D 10.1 is the graphics API used by the Windows 7 desktop.
Windows 7 and the Windows Vista update (KB 971644) add support for DXGI 1.1, 10level9 feature levels, and the WARP10 device to the existing Direct3D 10.1 API.
Direct3D 11
Windows 7 supports a new revision of Direct3D, Direct3D 11, built on the design of Direct3D 10.1 API. New features of the API include multithreaded rendering and resource creation, Compute Shader, support for 10level9 feature levels and the WARP10 software rendering device, and new Direct3D 11 class hardware features such as tessellation using hull & domain shaders, BC6H and BC7 texture compression formats, Shader Model 5.0, and Dynamic Shader Linkage. The new API can use existing Direct3D 10 and 10.1 class video cards, some Direct3D 9 cards through the 10level9 feature levels with limited feature support, and the latest generation Direct3D 11 class video cards.
In addition to the Direct3D 11 API, Windows 7 includes DXGI 1.1, Direct2D, DirectWrite, and support for WDDM 1.1 drivers.
The Direct3D 11 and related APIs are also available as an update to Windows Vista (see KB 971644).
Direct3D 11.1
WindowsВ 8 extends the Direct3D 11 API with Direct3D 11.1. Direct3D 11.1 supports all existing hardware that feature levels 11, 10_x, and 9_x support, as well as a new 11_1 feature level.
In addition to the Direct3D 11.1 API, WindowsВ 8 includes DXGI 1.2, Direct2D device contexts, and support for WDDM 1.2 drivers.
If you want your Windows Store apps to program 3D graphics with DirectX, you can use the Direct3D 11.1 API. For more info about programming 3D graphics with DirectX, see Introduction to 3D graphics with DirectX.
Platform Update for WindowsВ 7: Partial support is available for the Direct3D 11.1 API on WindowsВ 7 or Windows ServerВ 2008В R2 with the Platform Update for WindowsВ 7 installed. For more info about the Platform Update for WindowsВ 7, see Platform Update for Windows 7.
OpenGL
WindowsВ Vista, WindowsВ 7, and WindowsВ 8 provide the same support as Windows XP for OpenGL, which allows video card manufactures to provide an installable client driver (ICD) for OpenGL that provides hardware-accelerated support. Note that newer versions of such ICDs are required to fully support WindowsВ Vista, or WindowsВ 7, or WindowsВ 8. If no ICD is installed, the system will fall back to the OpenGL v1.1 software layer in most cases.
Application Compatibility, GDI, and older versions of Direct3D
The WindowsВ Vista, WindowsВ 7, and WindowsВ 8 graphics systems are designed to support a broad range of hardware and usage scenarios to enable new technology while continuing to support existing systems. Existing graphics interfaces, such as GDI, GDI+, and older versions of Direct3D, continue to work on Windows Vista and Windows 7, but are internally remapped where possible. This means that the majority of existing Windows applications will continue to work.
WindowsВ Vista, WindowsВ 7, and WindowsВ 8 continue to support the same Direct3D and DirectDraw interfaces as Windows XP, back to version 3 of DirectX (with the exception of Direct3D’s Retained Mode, which has been removed). Just as with Windows XP Professional x64 Edition, 64-bit native applications on newer versions of Windows are limited to Direct3D9, DirectDraw7, or newer interfaces. High-performance applications should make use of Direct3D 9 or later to ensure that they have the closest match to the hardware capabilities.
Recommendations
Consider the following recommendations when selecting an API for your graphical application:
Что такое Vulkan и DirectX и как они влияют на видеоигры
Большинство из нас, геймеров, слышали о Microsoft DirectX. Однако, немногие из нас знакомы с его утилитами и как они влияют на видеоигры. В настоящее время, фактически, приобретя конкурента в форме Vulkan, вещи относящиеся к двум API, как правило, становятся еще более сложными. В этом руководстве мы увидим, что такое API, Vulkan и DirectX, и мы покажим метод, с помощью которого они влияют на наши игры.
Предварительная информация о API
Прежде чем мы начнем говорить о DirectX и Vulkan, нам нужно сначала понять, что такое API. Аббревиатура означает «Интерфейс прикладного программирования».
Интерфейс предназначен для обеспечения связи между двумя объектами. Одним из примеров является графический интерфейс Windows, который играет роль посредника между операционной системой и пользователем.
Интерфейс обеспечивает удобную среду. С помощью этой среды мы используем операционную систему, не зная, как ее функции реализованы в фоновом режиме. Интерфейс прикладного программирования (API) заполняет роль посредника. Однако на этот раз пользователь может быть ПК или другой программой и не обязательно человеком. API-интерфейсы гораздо более распространены, чем можно было бы подумать, предлагая программистам необходимые инструменты для создания своего программного обеспечения.
Ориентировочный пример, в котором мы используем API, — это когда мы автоматически регистрируемся в новом социальном средстве или онлайн-сервисе, используя наши ранее существующие учетные записи из Facebook или Google (вместо создания новой учетной записи вручную).
В таких случаях веб-сайт использует API, через который он связывается с конкретной услугой (например, Facebook или Twitter), чтобы собирать нашу личную информацию (имя (имена), адрес электронной почты, контактные номера и т. д.) Для создания нашего нового аккаунта.
Тем не менее существует множество других применений API для всех видов взаимодействия между приложениями и компьютерами, такими как системы баз данных, операционные системы и библиотеки программного обеспечения.
В таких случаях использование API-интерфейсов применимо к нашему компьютерному оборудованию и в частности, к нашей графической карте (видеокартам).
DirectX и Vulkan фактически улучшают связь между приложением (игрой) и графическим процессором, чтобы повысить производительность графики.
Microsoft DirectX
Microsoft DirectXС выпуском Windows 95 и модели защищенной памяти разработчики не имели такого же доступа к ресурсам, как в MS-DOS. DirectX впервые появился в виде набора конкретных API для разработки мультимедийных приложений, таких как игры.
Термин «DirectX» начинается со слова «Direct», ссылаясь на прямой доступ к ресурсам системы. Некоторые примеры включают Direct3D для графики и DirectSound для аудио. Часть «Х» относится к API в общей коллекции; таким образом объединив все API-интерфейсы под названием DirectX. Вышеупомянутое название также вдохновило название популярной видеоигр компании Xbox.
Вышеприведенное иллюстрирует тесную связь между DirectX и консолью Microsoft. Его последняя версия, DirectX 12, имеет большие улучшения. Тем не менее он поддерживается только Windows 10 и новейшей игровой консолью компании Xbox One.
Direct3D является жемчужиной DirectX и полезен для создания 3D-объектов на нашем экране. Он также позволяет просматривать игры в полноэкранном режиме, а также использовать аппаратные ускорители. Последний метод позволяет реализовать некоторые функции более эффективно, чем они работают в программном обеспечении. Это может быть достигнуто за счет более эффективного использования аппаратного обеспечения нашего компьютера. В этом случае это будет наша видеокарта.
Вулкан AMD
В 2015 году Kronos Group разработала свой собственный API. Vulkan — это низкоуровневый API, используемый для разработки графически требующих приложений. Его первая стабильная версия дебютировала в августе 2016 года.
Следует четко указать, что «низкий уровень» не относится к качеству. Вместо этого этот термин описывает способность Вулкана работать на аппаратном уровне.
Хронос окружает себя одними из самых больших имен в ИТ-индустрии. Некоторые из них — Google, Intel, Sony, Nvidia и AMD. Последние два дали API, свести к минимуму время разработки Vulkan.
OpenGL — популярный API среди графических дизайнеров. Фактически он был разработан Хроносом, и он также включает в себя многие характеристики Вулкана. Однако его прием игровыми дизайнерами был непредвиденным.
Одним из самых сильных активов Vulkan является тот факт, что он с открытым исходным кодом. Кроме того, совместимость Vulkan с несколькими платформами вместе с общей производительностью — это два дополнительных актива, которые делают его более прибыльным, чем DirectX.
Здесь вы можете найти полный список с именами, которые содержат Khronos. Мантия обеспечила основную базу, на которой был разработан Вулкан. Наконец Vulkan в настоящее время находится в версии 1.1.
Как они влияют на игры
До этого момента мы рассмотрели некоторые основы, касающиеся API, Microsoft и Khronos. Но как они влияют на игры?
Эти два API значительно улучшили производительность. До сих пор DirectX, по-видимому, обеспечивал лучшую производительность, чем Vulcan, что на самом деле он не так далеко позади.
Microsoft утверждает, что DirectX 12 снижает потребление на 50% при использовании DirectX 11. С другой стороны, Vulkan также демонстрирует лучшую гибкость, чем его предшественник. Говоря о предшественниках, DirectX 11 и OpenGL были созданы с учетом одноядерных процессоров; что означает, что они не были точно настроены с использованием новых, многоядерных процессоров.
В результате одно ядро управляет большинством различных процессов, в то время как остальные работают с низкой скоростью, а иногда и вовсе отключены. Оба API (DirectX 12 и Vulkan) поддерживают процессоры с несколькими ядрами и потоками, чтобы максимально эффективно использовать свои возможности. Более того, они передают большую часть требуемых задач от процессора к графической карте (видеокартам), предлагая более сбалансированный опыт.
Взаимодействие между этими двумя элементами может существенно повлиять на будущие сборки ПК. Графические карты в значительной степени важнее, чем процессоры, когда дело доходит до игр. С дальнейшим развитием игровых API маловероятно, что процессоры могут стать еще менее важными, когда дело доходит до него. Таким образом, даже с простым процессором мы можем получить хорошую производительность без каких-либо узких мест.
Поддержка нескольких графических карт
Здесь Khronos Group столкнулась со значительным разрывом между двумя API-интерфейсами с поддержкой использования нескольких графических карт (использование явного многоканального GPU). Мы можем использовать разные карты, если их чипы имеют аналогичную архитектуру и используют один и тот же драйвер. Это позволит различным картам обрабатывать другую часть экрана.
Microsoft здесь еще на один шаг впереди, позволяя использовать несколько графических карт даже у другого производителя, что часто бывает, поскольку большинство систем имеют независимый и интегрированный графический процессор. Важно подчеркнуть тот факт, что эти реализации отличаются от возможностей SLI и Crossfire от Nvidia и AMD, которые реализованы с помощью драйверов, и в частности, в случае SLI требуют идентичные графические карты.
Шейдеры
Шейдеры — это небольшие программы, которые запускаются на наших видеокартах. Они отвечают за определенные функции различных объектов в 3D-среде. Тени, туман и освещение в игре являются результатом шейдера.
Vulkan использует промежуточное представление для шейдеров под названием SPIR-V. Его двоичная форма похожа на байт-код DirectX DX.
SPIR-V версия 1.3 отличается SPIR-V opt, инструментом для уменьшения размера шейдеров. Максимальный размер достигает + 40% от байт-кода DX соответствующего представления для DirectX.
Кроме того, некоторые структуры в HLSL (высокоуровневый шейдерный язык), которые были разработаны Microsoft, не поддерживались непосредственно некоторыми видеокартами.
HLSL широко используется DirectX с версии 9. Он использовался в качестве дополнения к существующему языку ассемблера шейдеров. С новой версией SPIR-V Vulkan также поддерживает ее.
Таким образом, разработчики смогут использовать существующий код для своих шейдеров, и им не нужно будет изобретать колесо. Следовательно, игры будут легко перенесены с одной платформы на другую.
Совместимость с несколькими платформами
Что касается платформ, большое преимущество Vulkan заключается в том, что он поддерживает Windows, Linux, Mac OS, Android и iOS. DirectX 12 с другой стороны, поддерживается только в Windows 10 и Xbox One. Чтобы использовать усовершенствования, предлагаемые DirectX 12, нам нужно либо обновить нашу операционную систему до Windows 10, либо получить новую консоль компании.
Если вы хотите попробовать DirectX 12, и вам не удалось получить Windows 10 во время бесплатного обновления, ознакомьтесь с нашим пошаговым руководством по свободным методам модернизации, которые доступны:
Возвращаясь к предыдущей теме, игровой порт, поддерживаемый API Vulkan, будет значительно проще по сравнению с портом, поддерживаемым DirectX.
С одной стороны, мы можем иметь названия на нескольких платформах, а с другой разные операционные системы имеют возможность размещать наши игры. Одна из причин, почему Linux не так популярен, как Windows, связана с тем, что последняя отличается от игр.
Распределение Linux может быть лучшим выбором для размещения наших игр, поскольку он может быть скорректирован для этой цели. Например Steam OS — это специализированная операционная система, предназначенная исключительно для игр.
Также подумайте: компания думает о создании программного обеспечения для разработки игр и хочет поддерживать API. Кто бы вы выбрали?
Оба имеют схожие мощности оба лучшие, чем их предшественники, и оба обеспечивают явное использование видеокарт. Vulkan поддерживает все платформы, включая Windows 10 и Xbox One, в то время как DirectX поддерживает только последние две.
Виртуальная реальность
Виртуальная реальностьНеобходимо сказать, что Vulkan является примером больших улучшений в области виртуальной реальности. Приложение VR должно отображать определенную 3D-сцену с двух разных точек зрения — по одному для каждого глаза.
До этого момента вышесказанное было возможно, отправив все необходимые команды на нашу графическую карту, чтобы сформировать трехмерное изображение для одной перспективы. Подход такой же для перспективы нашего второго глаза.
Версия 1.1 Vulkan предлагает набор команд рендеринга для формирования нескольких, немного разных выходов (изображений), которые в конечном итоге дают лучшую производительность в приложениях VR.
Развитие и будущее
Было бы упущением, не говоря уже о ходе разработки двух API. С одной стороны, у нас есть ветеран DirectX с более чем 20-летним развитием. С другой стороны, Вулкану едва будет 3 года с 2015 года. Тот факт, что Vulkan является открытым исходным кодом, может немного повлиять на его темпы роста. Конечно игроки Khronos, похоже серьезно относятся к разработке API, так как уровни улучшения впечатляют.
Все мы можем создавать новые инструменты и модификации и предоставлять их сообществу, помогая API расти быстрее. Наконец следует упомянуть, что DirectX не имеет вышеуказанной функции. Несмотря на свои годы развития, около 40 игр в настоящее время используют Vulkan, занимая большую часть рынка. Некоторые из них — Quake, Roblox, Talos и Dota 2. Что касается производительности, Vulkan приближается к DirectX, и в некоторых случаях он превосходит его. Самые захватывающие примеры работы Вулкана — игра Doom.
Vulkan расширил свою поддержку названий AAA, таких как Wolfenstein II, не пренебрегая названиями VR, такими как Doom VFR и Serious Sam VR. Здесь вы можете увидеть подробный список поддерживаемых игр. Хотя здесь вы найдете игры с поддержкой DirectX 12.
Оба API значительно улучшили производительность. Лучшее использование нескольких графических карт и меньшее использование ЦП повысит общую производительность наших систем. По слухам, новые видеокарты от Nvidia будут выпущены к концу лета и значительно превзойдут сегодняшние высокопроизводительные графические карты. В целом, общее состояние вещей кажется довольно гибким. В любом случае, изменения в разработке игр скоро будут у нас, и оба API несомненно будут играть важную роль.
Как вы относитесь к двум API?
Вы уже узнали всю информацию, которую мы предоставили на Vulkan и DirectX? Со временем их соперничество усиливается, какой из двух API вы считаете более полезным для развития игры? Мы с нетерпением ждем ваших комментариев.
