Фоновая обработка шейдеров vulkan что это
Фоновая обработка шейдеров vulkan что это
Steam for Linux
I have the same problem on my PC (100% Manjaro Linux) since at least 4-6 months which I especially noticed playing Rocket League.
Sometimes it launches instantly (2/10) and the other times it displays the vulkan shader progress bar (even after I restart the game).
Multiple other titles do not have a problem with this (idk the names but I have played a lot of Windows titles using Proton and a lot of them do never ask this twice or do complete the progress bar so fast that I don’t really care 1-4s).
I made the question because it happened two or three times with the same game («a hat in time»). Each time i allowed the extremely long process to end while doing something else, but for whatever reason i had to do it again (maybe related to the game crashing?). Hope the way steam is handling this process improves.
I dont use the same library files in different machines (yet), but i would try that sometime to see what happens. Im also using manjaro.
+1, I have the same issue on «a hat in time».
It takes forever, every time I launch the game.
That by itself is a turn off.
Then it will crash when I am configuring my controller.
I cant even play the game anymore.
is there any chance of exiting the game after the lengthy shader compilation and before the crash?
then running it again to confirm it doesn’t do it again unless it crashes or something gets updated (game/proton/related OS components)
is there any chance of exiting the game after the lengthy shader compilation and before the crash?
then running it again to confirm it doesn’t do it again unless it crashes or something gets updated (game/proton/related OS components)
that’s shader caches.
they change when the game changes. but they also need to change when vulkan changes, etc
so even if the game itself gets no update at all, there may be need for shader updates
Steam выпустил обновление, избавляющее от долгой загрузки при первом запуске игр
Патч также должен убрать появляющиеся в некоторых случаях проблемы с фреймрейтом.
13 декабря компания Valve обновила онлайн-сервис Steam, при этом одним из главных нововведений стало так называемое предварительное кэширование шейдеров (Shader Pre-Caching). С её помощью при скачивании игр клиент также загружает и предварительно кэширует (оптимизирует вместо постоянной перекомпиляции) графические шейдеры, которые обычно используются для различных эффектов и работы с освещением.
В результате при нескольких первых запусках уменьшается время загрузки, а также улучшается возможный нестабильный фреймрейт. Эти изменения относятся не ко всем существующим играм в Steam, а подобные проблемы встречаются нечасто, однако патч в целом должен улучшить ситуацию.
По словам Valve, использование технологии зависит в том числе и от установленных у пользователя устройств и системных драйверов. При этом способ помогает улучшить запуск игр, базирующихся как на спецификациях OpenGL, так и на API Vulkan. Нововведение может потребовать чуть большую пропускную способность канала, так как Steam после каждого запуска анализирует и загружает на сервер полученную информацию.
При желании функцию можно отключить. Обновление уже доступно в основном клиенте Steam.
А я, наивный, читая заголовок, надеялся, что убрали дебильные обновления directx и прочего мусора
Не у всех стоять эти библиотеки, поэтому и скачиваются.
Во время хейта No man sky находились твиты идиотов, которые жаловались на поставку без этих библиотек и она не запускалась у них.
Хотя пиратские репаки дают выбор, мол ставить их или нет. Стиму стоило сделать так же.
Но всё же лучше бы стим сжимал файлы игры и распаковывал их уже на пука, дольше, зато качать меньше.
Я до сих пор вспоминаю апдейты на пейдей 2, обнова на 100 мб а разархивирование занимаело часа 2, да и тем более что мало у кого сейчас не найдется безлима на интернет
Судя по статистике с опроса системы пользователей стима, у 72% стоят диски на террабайт. Я не вижу проблемы в сотне мегабайт лишнего хлама, мне это не мешает даже на диске с объемом 512 гб. Всё это какие то странные доебушки, с учетом того, что кэш в браузере или какие нибудь дрова от нвидии куда больше места занимают.
С DX проблема в том, что каждый инсталлер содержит разный набор DLL’ок, и даже разные их версии, иногда в дичайших комбинациях. А шипить раздельно библиотеки не позволяет EULA Microsoft.
Есть легковесная веб версия директа. Докачивает недостающие либы. Удобно и практично. Весит вроде меньше мегабайта.
Она скачивает актуальные версии библиотек, а при разработке могли использоваться и более древние. Так мы постепенно приходим к DLL Hell и истории winSxS.
Есть такое. После каждой AAA-игры приходится удалять папку Redist или время от времени запускать Steam Cleaner.
А они чем то мешают? Или ты гордый владелец ссд на 128гб?
Я гордый владелец SSD на 128гб, но Steam держу не на нём. Но что мешает Steam хотя бы вычислять дубликаты по хэш-сумме и удалять их? Super simple stuff.
Мобильная версия сайта не дала мне отредактировать комментарий, что бы дописать слово «единственного»
У меня к примеру на SSD места достаточно, но зачем мне каждый раз Steam устанавливает устаревшие библиотеки Visual C++, при том что у меня в системе установлены все актуальные версии. Надоело удалять после каждой установки игры.
Кто-то обещал тебе обратную совместимость.
Кто тебе сказал, что если ты возьмёшь ПО, использующее старые версии библиотек и подсунешь им новые, у тебя всё заведётся? Кроме непосредственно версионности, даже если предположить, что у нас кумулятивная сборка всех редистров от начала времён, кто станет гарантировать, что баг, исправленный в актуальном билде, не ломает что-то в ПО, основанном на более старой версии билда этой библиотеки?
Можно в системных требованиях к продукту прописать наличие в системе необходимых библиотек, а уже пусть каждый пользователь сам решает что ему устанавливать на СВОЁМ компьютере.
А кто тебе сказал что наличие старых библиотек с дырами в безопасности и прочими багами положительно скажется на работе твоего ПК и сохранности данных?
Установка игор — это офигеть какое продуманное решение в плане стабильности и безопасности, да. Даже если не брать в расчёт DRM. Для обычного пользователя должно быть «установил и играй», без соответствующих путающих непонятных вопросов, с чем Steam и прочие справляются и для чего всё необходимое и протестированное поставляется с игрой, как это и было задумано и оттестировано разработчиком. Особенно сильно это касается не самых свежих игр, в дальнейшем уровень тестирования и разработки как библиотек, так и готовых решений на их основе ощутимо возрос. А вот использование каких-то конкретных «актуальных» версий библиотек, а не всего зоопарка предоставляемых редистров — это не очень дальновидный поступок (что никак не оправдывает dll hell как концепцию). Но такова данность в unmanaged решениях. И если тебя что-то не устраивает, наблюдается какая-то половая травма или ещё что — ты можешь попытаться это удалить вручную на свой страх и риск.
«Установка игор — это офигеть какое продуманное решение в плане стабильности и безопасности,»
Для этого игры легально покупаются в соответствующих магазинах, а не качаются репаки с торрентов.
«чем Steam и прочие справляются и для чего всё необходимое и протестированное поставляется с игрой, как это и было задумано и оттестировано разработчиком. Особенно сильно это касается не самых свежих игр»
Только эти не самые свежие игры в большинстве случаев не работают на современном железе и современных ОС и покупаешь в Стиме заведомо нерабочий продукт.
Vulkan. Руководство разработчика. Графический конвейер
Я переводчик в IT-компании CG Tribe, и я продолжаю выкладывать перевод руководства к Vulkan API (vulkan-tutorial.com).
Сегодня я хочу поделиться с вами переводом первых двух глав раздела, посвященного графическому конвейеру (Graphics pipeline basics), — Introduction и Shader modules.
9. Загрузка моделей
10. Создание мип-карт
FAQ
Политика конфиденциальности
Вступление
В течение следующих нескольких глав мы будем настраивать графический конвейер, который позволит нам нарисовать первый треугольник. Графический конвейер — это последовательность операций, которые преобразуют вершины и текстуры мешей в пиксели в render target-ах.
Ниже представлена упрощенная схема:
Input assembler собирает сырые данные вершин из буферов. На этом этапе также может использоваться индексный буфер, который избавляет от необходимости дублировать данные вершин для повторяющихся элементов.
Вершинный шейдер (vertex shader) вызывается для каждой вершины и используется, в основном, для трансформации вершин из локальной системы координат в экранную. Также он передает данные каждой вершины далее по конвейеру.
Шейдеры тесселяции (tessellation shaders) позволяют увеличить количество мешей за счет дополнительного разбиения геометрии. Их часто используют, чтобы сделать близлежащие поверхности, например, кирпичные стены или лестницы, менее плоскими.
Геометрический шейдер (geometry shader) вызывается для каждого примитива (треугольник, линия, точка) и может отменить их отрисовку или сгенерировать новые примитивы. Геометрический шейдер похож на шейдер тесселяции, только, в отличие от него, более гибкий. Однако он не часто используется в современных приложениях из-за недостаточно высокой производительности большинства видеокарт, за исключением встроенных графических процессоров Intel.
На этапе растеризации (rasterization) каждый примитив раскладывается на множество фрагментов. Фрагменты — это пиксельные элементы, которые заполняют примитивы во фреймбуфере. Все фрагменты, которые выходят за пределы экрана, отсекаются, а атрибуты, переданные вершинным шейдером, интерполируются по фрагментам, как показано на рисунке. Фрагменты, находящиеся за другими фрагментами, как правило, тоже отсекаются из-за теста глубины (depth testing).
Фрагментный шейдер (fragment shader) вызывается для каждого фрагмента и определяет, в какие фреймбуферы и с каким значением цвета и глубины записываются фрагменты. Для этого он использует интерполированные данные из вершинного шейдера, такие как текстурные координаты и нормали для освещения.
На этапе смешивания цветов (color blending) происходит смешивание различных фрагментов, относящихся к одному и тому же пикселю во фреймбуфере. Фрагменты могут перекрывать друг друга или смешиваться в зависимости от прозрачности.
Этапы, выделенные зеленым цветом, называются непрограммируемыми (fixed-function). На этих этапах вы можете корректировать операции с помощью параметров, но принцип их работы определен заранее.
Этапы, выделенные оранжевым цветом, — программируемые этапы (programmable). Это значит, что вы можете загрузить свой собственный код на видеокарту, чтобы выполнить необходимые операции. Это позволяет вам использовать, например, фрагментные шейдеры для самых разных задач от текстурирования и освещения до трассировки лучей. Эти программы запускаются одновременно на множестве ядер GPU для параллельной обработки таких объектов как вершины и фрагменты.
Некоторые программируемые этапы можно пропустить. Например, вы можете отключить тесселяцию и геометрический шейдер, если рисуете простую геометрию. Если вас интересуют только значения глубины (например, при создании карты теней), вы можете отключить фрагментный шейдер.
В следующей главе мы начнем с создания двух программируемых этапов, необходимых для отображения треугольника на экране: вершинного шейдера и фрагментного шейдера. Далее мы настроим непрограммируемые этапы, указав такие параметры, как режим смешивания и viewport. Заключительная часть создания графического конвейера включает настройку входных данных и выходных фреймбуферов.
Шейдерные модули
Преимущество использования байт-кода в том, что компиляторы, написанные производителями GPU и компилирующие шейдеры в нативный код, получаются значительно проще. К тому же прошлое показало, что при использовании человеко-ориентированного синтаксиса, как GLSL, некоторые вендоры интерпретировали стандарт весьма свободно. При написании нетривиальных шейдеров для GPU такого производителя был большой риск, что код окажется несовместим с драйверами других производителей или, еще хуже, из-за ошибок компилятора шейдер будет работать иначе. Простой формат байт-кода SPIR-V позволяет избежать этих проблем.
Нам не придется писать байт-код вручную. Khronos выпустил собственный компилятор, независимый от производителя, который компилирует GLSL в SPIR-V. Он проверяет, соответствует ли шейдерный код стандарту, и создает бинарный файл SPIR-V для использования в вашей программе. Также этот компилятор можно использовать в качестве библиотеки для создания SPIR-V в рантайме (во время исполнения), но в руководстве мы не будем этого делать. Вместо glslangValidator.exe мы будем использовать glslc.exe от Google. Преимущество glslc в том, что он использует тот же формат командной строки, что и компиляторы GCC или Clang, и включает некоторые дополнительные функции, например, includes. Обе программы уже включены в Vulkan SDK, поэтому не нужно скачивать ничего дополнительно.
Как уже было сказано, для отрисовки треугольника мы должны написать вершинный шейдер и фрагментный шейдер. В следующих двух пунктах мы рассмотрим код GLSL для каждого шейдера и покажем, как создать бинарные файлы SPIR-V и загрузить их в программу.
Вершинный шейдер
Вершинный шейдер обрабатывает каждую входящую вершину. В качестве входных данных он принимает вершинные атрибуты, такие как координаты в мировом пространстве, цвет, нормаль и текстурные координаты. Выходные данные — преобразованные координаты в пространстве отсечения (clip space) и атрибуты, которые передаются фрагментному шейдеру (например, цвет и текстурные координаты). Позже эти значения будут интерполированы по фрагментам для создания плавного градиента.
Координатами в пространстве отсечения называют четырехмерный вектор, принимаемый из вершинного шейдера, который преобразуется в нормализованные координаты устройства в результате деления вектора на его последний компонент. Нормализованные координаты устройства (normalized device coordinate) — это гомогенные координаты, находящиеся в диапазоне [-1, 1], и проецирующиеся на фреймбуфер, как показано на картинке ниже:
Если до этого вы работали с OpenGL, вы можете заметить, что координата Y теперь зеркально отражена. А для координаты Z задан тот же диапазон, что и в Direct3D, от 0 до 1.
Для нашего первого треугольника мы не будем применять никаких преобразований, а просто укажем положения трех вершин в нормализованных координатах устройства для создания такой фигуры:
Мы можем отдавать непосредственно нормализованные координаты устройства, используя координаты пространства отсечения с единицей в качестве последнего компонента. Таким образом, деление на w не изменит значения координат при переходе от клип пространства к экранному.
Как правило, нормализированные координаты хранятся в вершинном буфере, но создание вершинного буфера в Vulkan и заполнение его данными — задача нетривиальная. Поэтому мы отложим это до тех пор, пока на экране не появится первый треугольник. А пока применим небольшую хитрость: вставим координаты непосредственно в вершинный шейдер. Код будет выглядеть так:
Фрагментный шейдер
Вершины, полученные из вершинного шейдера, образуют треугольник, который должен быть заполнен фрагментами (пикселами) на экране. Фрагментный шейдер вызывается для каждого фрагмента и определяет его цвет и значение глубины во фреймбуфере (или фреймбуферах). Чтобы окрасить весь треугольник в красный цвет, используется простой фрагментный шейдер:
Цвет каждой вершины
Полностью красный треугольник выглядит слишком просто, может, сделаем его поинтереснее?
Для этого внесём кое-какие изменения в оба шейдера. Сначала укажем цвет для каждой из трех вершин. Вершинный шейдер должен включать в себя массив цветов:
Теперь нужно передать цвет каждой вершины во фрагментный шейдер, чтобы он мог вывести их интерполированные значения во фреймбуфер. Добавим выходную переменную для цвета в вершинный шейдер и заполним её в функции main :
Затем добавим соответствующую ему входную переменную во фрагментный шейдер:
Компиляция шейдеров
Содержимое файла shader.vert должно быть следующим:
А содержимое файла shader.frag следующим:
Замените путь к glslc.exe на путь установки Vulkan SDK. Дважды щелкните по файлу, чтобы запустить его.
Замените путь к glslc на путь установки Vulkan SDK. Сделайте скрипт исполняемым с помощью команды chmod + x compile.sh и запустите его.
Эти две команды говорят компилятору прочитать исходный файл GLSL и вывести его в байт-код SPIR-V с помощью флага -o (output).
Если в вашем шейдере есть синтаксическая ошибка, компилятор сообщит вам номер строки и укажет на проблему. Чтобы в этом убедиться, попробуйте, например, убрать точку с запятой откуда-нибудь из текста шейдеров и по новой запустить скрипт. Также можете запустить компилятор без аргументов, чтобы узнать, какие типы флагов он поддерживает. Кроме того, компилятор может, например, вывести байт-код в формат удобный для чтения, чтобы вы могли посмотреть, что делает шейдер и какие оптимизации были выполнены на этом этапе.
Компиляция шейдеров в командной строке — один из самых простых способов, который мы будем использовать в руководстве, но вы можете скомпилировать шейдеры непосредственно из вашего кода. Для этого в Vulkan SDK есть libshaderc — библиотека для компиляции кода GLSL в SPIR-V.
Загрузка шейдера
Пришло время загрузить шейдеры SPIR-V в нашу программу, чтобы позже подключить к графическому конвейеру. Прежде всего напишем простую вспомогательную функцию для загрузки бинарных данных из файлов.
Затем мы можем вернуть указатель в начало файла и считать все байты за один вызов:
И, наконец, закроем файл и возвратим буфер:
Создание шейдерных модулей
Функция принимает буфер с байт-кодом в качестве параметра и создает из него VkShaderModule.
В функцию передаются уже знакомые нам параметры: логическое устройство, указатель на структуру с необходимой информацией, опциональный указатель на кастомный аллокатор и выходная переменная. Буфер с кодом можно освободить сразу после создания шейдерного модуля. Не забудьте вернуть созданный шейдерный модуль:
Шейдерный модуль всего лишь тонкая обертка для шейдерного байт-кода, загруженного из файла, и объявленных в нем функций. Компиляция и линковка байт-кода SPIR-V в машинный код не произойдет до тех пор, пока не будет создан графический конвейер. Это значит, что мы можем уничтожить шейдерные модули сразу после создания конвейера. Поэтому в функции createGraphicsPipeline сделаем их локальными переменными вместо членов класса:
Уничтожим их в конце функции с помощью двух вызовов vkDestroyShaderModule. Остальной код в этой главе будет вставлен перед следующими строками:
Связываем шейдеры и конвейер
Чтобы использовать шейдеры, нужно подключить их к конкретным стадиям конвейера. Для этого при создании конвейера будем использовать структуру VkPipelineShaderStageCreateInfo.
А теперь сделаем практически то же самое для фрагментного шейдера:
Наконец создадим массив, содержащий подготовленные нами структуры. Это понадобится нам, чтобы ссылаться на них при создании конвейера.
В этой главе мы рассмотрели только программируемые этапы конвейера. В следующей главе мы перейдем к непрограммируемым этапам.
Что такое 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 вы считаете более полезным для развития игры? Мы с нетерпением ждем ваших комментариев.