processing vulkan shaders что это значит

Что означает появление технологии Vulkan для пользователей

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

В общем представлении Vulkan должен принести улучшенный игровой и пользовательский опыт, а также более высокое качество игр, в том числе на Android. По сравнению с традиционными OpenGL и Direct3D, Vulkan предоставляет возможность реализовать многопоточность и более эффективно использовать центральный процессор. Технология изначально основана на разработке от AMD под названием Mantle, однако вскоре идея была подхвачена консорциумом Khronos Group, в который сегодня входит больше 100 членов по всему миру. Vulkan версии 1.0 был выпущен для Windows, Linux и Android. Особенно большое влияние Vulkan окажет именно на мобильную платформу, поскольку предоставит разработчикам прямой доступ к GPU для полного контроля над его работой. Можно ожидать не только повышение качества изображения, но и уменьшение энергопотребления при том же результате.

Что означает появление технологии Vulkan для пользователей

NVIDIA уже опубликовала необходимые образы для разработчиков, чтобы те могли адаптировать их к нынешним Android-планшетам с чипами NVIDIA, однако сегодня их доля на рынке мизерна. Среди Khronos Group мелькают имена известных производителей, в частности, Google, Samsung, Sony, Qualcomm, Huawei и некоторых других, однако как скоро они начнут внедрять Vulkan, сказать довольно сложно. Хочется верить, что Google сделает Vulkan приоритетной разработкой для Android, однако пока что об этом официально ничего не сообщается.

Источник

Processing vulkan shaders everytime #1859

Comments

safield commented Dec 22, 2020

Everytime I start dota2, it says «Processing Vulkan Shaders» which takes around 10 minutes to complete.

The best part of all of this is that my card does not even support vulkan, so why is it doing Vulkan specific stuff?

Also there is no export or copy button for system info AND it does not let me scroll while I select, so this is all I could grab for system info.

Operating System Version:
Ubuntu 20.04.1 LTS (64 bit)
Kernel Name: Linux
Kernel Version: 5.4.0-58-generic
X Server Vendor: The X.Org Foundation
X Server Release: 12008000
X Window Manager: KWin
Steam Runtime Version: steam-runtime_0.20201203.1
Video Card:
Driver: NVIDIA Corporation GeForce GTX 580/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 390.138
OpenGL Version: 4.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 60 Hz
VendorID: 0x10de
DeviceID: 0x1080
Revision Not Detected
Number of Monitors: 1
Number of Logical Video Cards: 2
Primary Display Resolution: 1920 x 1080

The text was updated successfully, but these errors were encountered:

kisak-valve commented Dec 22, 2020

Hello @safield, Vulkan shader pre-caching is handled by the Steam client, not Dota 2. Also, this issue is already being tracked at ValveSoftware/steam-for-linux#7306.

Closing as a duplicate.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Processing vulkan shaders что это значит

Vulkan — это замена OpenGL и будущее графики в Linux, которое означает лучший игровой процесс и улучшения производительности.

В таких играх, как DoTA 2, уже некоторое время используется Vulkan, а новые проекты, такие как DXVK, помогают пользователям Linux играть в свои любимые игры из Windows, как никогда раньше.

Настроить Vulkan довольно просто для любого дистрибутива, независимо от вашей видеокарты. Это руководство охватывает текущие версии Debian, Ubuntu, Fedora, OpenSUSE и Arch.

Уточнение

Установка Vulkan

ВЫ ЗНАЛИ?
Если вы хотите скомпилировать программу, основанную на Vulkan, вам потребуется дополнительно установить библиотеку разработки libvulkan-dev

Debian

AMD — вам необходимо выполнить следующие команды:

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

Ubuntu

Здесь дела обстоят немного лучше 🙂

AMD — лучше всего добавить в систему PPA-репозиторий с последними версиями драйверов Mesa и обновить ее. Для этого выполните следующие команды:

После этого установите пакеты Vulkan.

NVIDIA — тут также есть отличный PPA-репозиторий с проприетарными драйверами NVIDIA. Добавьте его в свою систему и обновите ее.

Теперь установите новые драйверы и сам Vulkan. Например:

*где 410 — это версия драйвера NVIDIA подходящая для вашей видеокарты и версии Ubuntu (304/340/384/390/410/415/418/430/440/450/455/460)

Fedora

NVIDIA — проприетарные драйверы доступны в репозитории RPMFusion. Добавьте его в свою систему:

И затем установите драйверы с Vulkan.

OpenSUSE

NVIDIA — перейдите к документации OpenSUSE и следуйте процедуре для вашей версии OpenSUSE. После установки драйверов, установите пакеты Vulkan.

Arch Linux

AMD — у вас уже установлены последние версии драйверов AMD Mesa, просто установите поддержку Vulkan.

NVIDIA — установите драйверы NVIDIA, они включают поддержку Vulkan.

Vulkan Info

DoTA 2

Есть еще один более практичный способ увидеть, как Vulkan работает в вашей системе. Вы можете установить и играть в DoTA 2. Это одна из первых игр для Linux, полностью поддерживающих Vulkan, и в нее можно играть бесплатно. Единственное, что вам нужно, это учетная запись Steam.

Сначала установите Steam в свою систему. Он доступен во всех вышеперечисленных дистрибутивах. Когда у вас есть Steam, вы можете достаточно легко установить DoTA 2.

Когда вы установите DoTA 2, вы заметите ряд новых режимов при их выборе на главной странице игры. Выберите Vulkan для поддержки и Steam начнет его скачивать.

Запустите DoTA 2 и откройте настройки. Измените графический API на Vulkan и перезапустите игру. Когда DoTA 2 снова запустится, он будет работать уже с Vulkan.

Тест производительности OpenGL против Vulkan

В этом параллельном сравнении показана разницу FPS (кадров в секунду) между OpenGL и Vulkan для Dota 2 в Linux. Эти тесты проводились на одном компьютере с использованием переключателя опций для переключения между двумя API. Тестирование проводилось при разрешении 1080p с ползунком качества, установленным на максимальное значение.

Hardware

Drivers

Dota 2

Results

Заключительные мысли

Теперь вы используете Vulkan на своем рабочем столе Linux. Если вы прошли через DoTA 2, у вас уже есть рабочая игра, в которой он используется. Все другие инструменты и программы на основе Vulkan теперь также открыты для вас, в том числе для использования с Wine и DXVK. Это открывает множество новых игр для вашей системы.

Поддержка Vulkan только улучшается. Все больше игр используют его, и другие утилиты Linux также расширяются. Wine даже разрабатывает поддержку DirextX 12 с Vulkan. Обновляйте свою систему и наслаждайтесь прогрессом.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Vulkan не имеет обратной совместимости с OpenGL.

СОДЕРЖАНИЕ

Функции

Предполагаемые преимущества Vulkan перед API-интерфейсами предыдущего поколения включают следующее.

Единый API

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

Кросс-платформенный

Более низкая загрузка ЦП

Снижение нагрузки на драйверы, снижение нагрузки на ЦП.

Многопоточность

Лучшее масштабирование на многоядерных процессорах. Direct3D 11 и OpenGL 4 изначально были разработаны для использования с одноядерными ЦП и получили расширения только для многоядерных. Даже когда разработчики приложений используют дополнения, API регулярно плохо масштабируется на многоядерных процессорах.

Предварительно скомпилированные шейдеры

Другие

OpenGL против Vulkan

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

AMD утверждает, что: «Vulkan поддерживает управление, близкое к металлическому, что обеспечивает более высокую производительность и лучшее качество изображения в Windows 7, Windows 8.1, Windows 10 и Linux. Ни один другой графический API не предлагает такую ​​мощную комбинацию совместимости с ОС, функций рендеринга, и эффективность оборудования «.

Версии

Вулкан 1.1

На SIGGRAPH 2016 Khronos объявил, что Vulkan получит поддержку автоматических функций нескольких графических процессоров, аналогично тому, что предлагает Direct3D 12. Поддержка нескольких графических процессоров, включенная в API, устраняет необходимость в SLI или Crossfire, для которых требуются графические карты. та же модель. Вместо этого API с несколькими графическими процессорами позволяет API разумно разделять рабочую нагрузку между двумя или более совершенно разными графическими процессорами. Например, встроенные графические процессоры, входящие в состав ЦП, можно использовать в сочетании с высокопроизводительным выделенным графическим процессором для небольшого повышения производительности.

7 марта 2018 года компания Khronos Group выпустила Vulkan 1.1. Это первое крупное обновление API стандартизировало несколько расширений, таких как multi-view, группы устройств, совместное использование между процессами и API, расширенные вычислительные функции, поддержка HLSL и поддержка YCbCr. В то же время он также обеспечил лучшую совместимость с DirectX 12, явную поддержку нескольких графических процессоров, поддержку трассировки лучей и заложил основу для следующего поколения графических процессоров. Помимо Vulkan 1.1, SPIR-V был обновлен до версии 1.3.

Вулкан 1.2

Планируемые функции

Выпуская OpenCL 2.2, Khronos Group объявила, что OpenCL по возможности объединится с Vulkan, чтобы обеспечить гибкость развертывания программного обеспечения OpenCL для обоих API. Теперь это было продемонстрировано Adobe Premiere Rush с использованием компилятора с открытым исходным кодом clspv для компиляции значительных объемов кода ядра OpenCL C для запуска в среде выполнения Vulkan для развертывания на Android.

История

По данным Управления по патентам и товарным знакам США, товарный знак Vulkan был зарегистрирован 19 февраля 2015 года.

Официальное имя Vulkan было объявлено на конференции Game Developers Conference 2015, хотя предположения и слухи, связанные с новым API, существовали и раньше, и он назывался « glNext ».

2015 г.

В начале 2015 года LunarG (при финансовой поддержке Valve ) разработала и продемонстрировала драйвер Linux для Intel, который обеспечил совместимость Vulkan с интегрированной графикой серии HD 4000, несмотря на то, что драйверы Mesa с открытым исходным кодом не были полностью совместимы с OpenGL 4.0 до конца этого года. По-прежнему существует возможность поддержки Sandy Bridge, поскольку он поддерживает вычисления через Direct3D11.

10 августа 2015 года Google объявил, что будущие версии Android будут поддерживать Vulkan. Android 7.x «Nougat» запустил поддержку Vulkan 22 августа 2016 года. Android 8.0 «Oreo» имеет полную поддержку.

18 декабря 2015 года Khronos Group объявила, что версия 1.0 спецификации Vulkan почти завершена и будет выпущена, когда появятся соответствующие драйверы.

2016 г.

Спецификация и пакет Vulkan SDK с открытым исходным кодом были выпущены 16 февраля 2016 года.

2018 г.

2019 г.

25 февраля 2019 года было объявлено, что рабочая группа Vulkan Safety Critical (SC) предоставит ускорение Vulkan GPU для отраслей, критически важных для безопасности.

2020 г.

15 января 2020 года был выпущен Vulkan 1.2.

24 ноября 2020 года Raspberry Pi Foundation объявил, что их драйвер для Raspberry Pi 4 совместим с Vulkan 1.0.

Поддержка от поставщиков

Первоначальные спецификации заявили, что Vulkan будет работать на оборудовании, которое в настоящее время поддерживает OpenGL ES 3.1 или OpenGL 4.x и выше. Поскольку для поддержки Vulkan требуются новые графические драйверы, это не обязательно означает, что на каждом существующем устройстве, поддерживающем OpenGL ES 3.1 или OpenGL 4.x, будут доступны драйверы Vulkan.

Intel, Nvidia и AMD

Все три основных производителя ПК бесплатно предоставляют реализации Vulkan API в виде драйверов для систем Linux и Windows. Vulkan 1.1 поддерживается новыми линиями оборудования, такими как Intel Skylake и выше, AMD GCN 2nd и выше и Nvidia Kepler и выше. AMD, Arm, Imagination Technologies, Intel, Nvidia и Qualcomm поддерживают актуальное оборудование со второй половины 2018 года с драйверами Vulkan 1.1. Mesa 18.1 поддерживает оборудование AMD и Intel с драйверами RADV и ANVIL. Актуальное состояние RADV и ANVIL в Mesa 3D см. В Mesamatrix.

Google Android

Многие устройства Android поддерживают спецификацию OpenGL ES. Примеры Android 7.0 Nougat (Vulkan 1.0). Android 9.0 Pie и Android 10 для Vulkan 1.1.

яблоко

По состоянию на 3 июня 2021 г. нативная поддержка API Vulkan на устройствах Apple отсутствует. Apple не объявила о поддержке iOS и macOS. Существует попытка обойти эту проблему с помощью библиотеки с открытым исходным кодом MoltenVK, которая обеспечивает реализацию Vulkan поверх графического API Metal на устройствах iOS и macOS. Однако у него есть некоторые ограничения.

Qualcomm

Графические процессоры серий Adreno 5xx (2018) и 6xx для мобильных платформ Qualcomm Snapdragon (Snapdragon 820 и т. Д.) Поддерживают Vulkan 1.0 через его Adreno GPU SDK. SDK основан на Android Studio IDE, и Android NDK необходим для использования всех его функций.

Источник

Осваиваемся с Vulkan

Примерно за пол-года вроде как разобрался с Vulkan.

Пишу сейчас рендерер плагин для своего графического движка

После OpenGL, для которого всё есть GLint либо GLuint, очень порадовала типизация. Также командные буферы – действительно крутая вещь – в них мало того, что можно писать из нескольких потоков (хотя и с ограничениями), так ещё и записанные однажды, они могут использоваться многократно! Возможность обеспечить более полную загрузку железа с меньшим временем на ожидание вертикальной синхронизации, например, через явное управление очередями тоже впечатляет.

В общем Vulkan в целом мне зашёл. Но есть несколько «но».

В общем будущее светло, но не безоблачно. Многопоточный рендеринг, кеширование сцен и возможность безбубенной многооконности, сияют, превращая ночь в день, а днём затмевая Солнце; а маячащая на горизонте возможность multi GPU через DMABUF звучит как гимн разума и изобретательности 😀 Но отношение Khronos к шейдерам, как минимум, настораживает..

Кто уже тоже успел повулканить? Что думаете о наступившем будущем?

В линуксе мало игр. В геймдеве мало линуксоидов…

А ты этим for fun занимаешься, или по работе?

Ну, это лучше, чем если бы было как на Android – куча всякого шлака без задумки, без сюжета, без графония..

В этой стране в принципе геймдев не существует как индустрия. На заокраинном мне видится ситуация так – линуксоидов очень небольшая часть из всех ПК-юзеров; из разработчиков линуксоидов значительно больше (в %), но всё ещё мало. В геймдеве – больше, чем среди в всех пользователей, но меньше, чем среди всех разработчиков.

Я не особо разбираюсь в графике, но почему SPIRV вдруг плохой? Он ведь создавался с одной целью, чтоб зоопарк шейдерных языков GLSL/Cg/HLSL компилировался в этот SPIRV и на стороне драйвера уже реализовывать компиляцию SPIRV в машинный код а не кучу компиляторов как это делалось раньше. Плюс можно любой язык спокойно в SPIRV компилировать.

Для прямоХ эти оси тоже другие, так что всё ок, всё везде разное 🙂

Ты наркоман или старообрядник?

Стадии компиляции/линковки разнесены. Компиляция – шейдерные модули; линковка – пайплайн.

Бинарники – добро. Парсинг текста в движке – кусок говна, который я никогда не понимал в опенгл.

а маячащая на горизонте возможность multi GPU

Уже вполне работает как и с DeviceGroup так и с внешними файл дескрипторами.

Но отношение Khronos к шейдерам, как минимум, настораживает..

Серьёзно, в вулкане шейдеры пофиксили, а не сломали.

Кто уже тоже успел повулканить? Что думаете о наступившем будущем?

По сравнению с GNM – переусложненное запутанное говно. По сравнению со всем остальным – восторг.

Потому, что в нём шейдерные стадии неделимы – «снаружи» Vulkan-а оказалась не только компиляция шейдеров, что было бы ещё терпимо, но и линковка тоже. С программой теперь предполагается поставлять не шейдерные модули, а целиком слинкованные и «скомпиленные» (в промежуточный байт код, который опять потом компилить надо ЛОЛ) стадии (вершинная стадия, геометрическая, фрагментная..).

А уж если у нас в программе / движке есть какая то процедурная генерация шейдеров – то совсем труба! В OpenGL можно иметь «динамические» шейдерные модули которые генерируются программой, а остальные просто загружены из файла и скомпилены один раз; таким при изменении модуля происходит перекомпиляция этого модуля и перелинковка шейдерной программы / стадии. В Vulkan же надо рекомпилить целиком стадию.

Также на OpenGL можно сделать API для GLSL шейдеров: поставлять с движком шейдерные модули и описание их публичного интерфейса в некой форме. Модули из API будет скомпилированы не более 1 раза (при их первом использовании). В glslang (а именно через это место у Vulkan поддерживается glsl) распарсенный шейдерный модуль может быть задействован не более, чем в 1 программе, копироваться не умеет – аллес; приходится парсить реализацию модуля столько раз, в скольких программах он используется.

В целом получается главный юзкейс, на который Khronos ориентировались – это когда шейдеры являются частью графического движка а для клиентского кода, есть только фиксированный конвеер. Прямо как в старые не добрые времена OpenGL 1.x. Только теперь конвеер зашит не в OpenGL, а в движке. Я же хочу дать пользователю шейдеры, из которых он сможет брать из движка данные и звать его API, когда нужно (модели освещения, вершины, нормали и проч.). Движок Kawaii3D ожидает от клиентского кода шейдеры в слегка модифицированном GLSL, рендерер плагины (на данный момент существуют MisakaRenderer и KurisuRenderer) достаточно легко получают из него чистый GLSL и работают уже с ним.

зоопарк шейдерных языков GLSL/Cg/HLSL компилировался в этот SPIRV

В OpenGL есть только GLSL. Зоопарка там нет. Не зачем его создавать. Дожили до того, что на расте шейдеры писать хотят.

Уже вполне работает как и с DeviceGroup так и с внешними файл дескрипторами.

В Vulkan работает, я в курсе. Я про поддержку этого добра в своём проекте (там пока только через DeviceGroup).

По сравнению с GNM – переусложненное запутанное говно

Я клиентскому коду возможность шейдеров вручил.

> В OpenGL есть только GLSL

Извините что вмешиваюсь в разговор серьёзных людей. Я просто поправлю, что, помимо языка GLSL, существует возможность писать шейдеры на ассемблере ARB assembly language (расширения vertex_program, fragment_program). https://ru.wikipedia.org/wiki/OpenGL#OpenGL_2.0 В Wine 5.0 даже добавили возможность выбирать, как именно будут транслироваться шейдеры из Direct3D в OpenGL: в GLSL или arb (vertex/fragment) (пруф в последнем пункте про Direct3D в новости про Wine 5.0)

Прориетарная апишка, с которой можно работать на всех уровнях абтракции начиная с «дх11 стайл – пишем код не приходя в сознание» и заканчивая ручным заполнением регистров видяшки. Где-то в середине, когда ты ставишь барьеры и кеш-флаши руками наступает дзен)

Я клиентскому коду возможность шейдеров вручил.

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

Клиентскому коду нужны материалы и модели

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

Задача движка – обрабатывать гейм-логику и быстро работать

Это игровой движок. Там по мимо графического движка ещё скрипты, звук, обработка ввода, сеть и много всего. Я, кст, не спеша пишу KawaiiWorlds на основе своего Kawaii3D. И это уже будет игровой движок.

Я просто поправлю, что, помимо языка GLSL, существует возможность разрабатывать спецэффекты на языках ассемблера (расширения vertex_program, fragment_program)

Речь про vertex_program и fragment_program? Это не та ли древняя технология, на смену которой пришёл GLSL? Извиняюсь, не очень хорошо знаю историю..

Потому, что в нём шейдерные стадии неделимы – «снаружи» Vulkan-а оказалась не только компиляция шейдеров, что было бы ещё терпимо, но и линковка тоже. С программой теперь предполагается поставлять не шейдерные модули, а целиком слинкованные и «скомпиленные» (в промежуточный байт код, который опять потом компилить надо ЛОЛ) стадии (вершинная стадия, геометрическая, фрагментная..).

А как же тогда работают трансляторы типа DXVK и MoltenGL?

Он поверх metal, вроде как

Самостоятельно компилит dxbc и dxso шейдеры.

Исправили древнюю ошибку OpenGL. Знаете как устроены числа с плавающей точкой? Между 0 и 0.5 намного больше представимых чисел, чем между 0.5 и 1. То есть точность z-буфера максимальна вблизи z=0. В OpenGL этот 0 болтается где-то среднем плане, где такая точность не нужна.

Упс. Мне казалось что реализацию opengl поверх вулкана тоже кто-то делал

Самостоятельно компилит dxbc и dxso шейдеры.

В смысле в нем свой собственный компилятор, или он все-таки как-то использует компилятор от видеодрайвера?

В смысле в нем свой собственный компилятор или он все-таки как-то использует компилятор от видеодрайвера?

Собственный компилятор для dxbc и для dxso.

Полученный SPIRV код уже непрозрачно для программиста компилируется драйвером (реализацией vulkan) в машинный код устройства.

Упс. Мне казалось что реализацию opengl поверх вулкана тоже кто-то делал

Да, есть такой проект. Zink Gallium Driver. Вот как он работает, вообще ХЗ 😀

> Он поверх metal, вроде как

Да. MoltenVK это Vulkan поверх Metal, а MoltenGL это OpenGL поверх Metal

Эх когда куплю поддерживающую эту Джамалунгму видеокарту, тоже начну пердолиться. Тоесть если я правильно понимаю, вот сейчас у меня на GL есть материал к которому можно просто приложить фрагментный и вершинный шейдера которые движок просто подхватит и слинкует и исполнит. А для поиска нужного эффекта можно играться прямо в live режиме просто пересобирая 1 маленький шейдерок для 1 маленького эффекта не трогаая тонну остальных. Правильно ли я понимаю что если я хочу внести изменения я должен буду погасить вулкан приложение, пересобрать все шейдеры и только потом увижу результат перезапустив мир по сути?

Тоесть если я правильно понимаю, вот сейчас у меня на GL есть материал к которому можно просто приложить фрагментный и вершинный шейдера которые движок просто подхватит и слинкует и исполнит. А для поиска нужного эффекта можно играться прямо в live режиме просто пересобирая 1 маленький шейдерок для 1 маленького эффекта не трогаая тонну остальных

Да, примерно так я планирую сделать в KawaiiWorlds.

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

Не обязательно. Приложение само может компилить твой шейдер в SPIRV. Мой Vulkan рендерер зависит в рантайме от glslang ради этого. Разница в том, что Vulkan приложение должно будет перекомпилить целиком стадию (внёс изменения, например, в вершинный шейдер – все вершинные шейдеры этого материала (точнее пайплайна) нужно будет пересобрать), что значительно сильнее ударит производительность. Если шейдеры меняет человек в live режиме в каком-нибудь редакторе, это нормально. Там можно хоть на целую секунду подвиснуть. Если же шейдер меняется программой, как реакция на некое событие, то жопь.

Про графический движок Kawaii3D стоит сказать, что он не содержит коллекции семейств материалов. Взамен он принимает от клиентского кода шейдерные программы на наречии GLSL. Renderer plugins получают из ядра движка информацию о зависимостях шейдерных модулей и код на чистом glsl и имеют с этим дело. Также ядро движка ничего не рендерит, не загружает и т.д. – всем этим заняты плагины.

Во-вторых и в главных – SPIRV. В OpenGL замечательная система шейдерных модулей, для которых компиляция отделена от линковки, которая позволяет приложению конструировать шейдерные программы (а в последних версиях OpenGL стадии) из функциональных взаимозаменяемых блоков. Совершенно не ясно, зачем было её херить 🙁 В Vulkan стадии стали неделимыми, так ещё и бинарными.

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

Ты перекомпилируешь проект при внесении изменений в исходники? Чем шейдеры должны отличаться?

По сравнению с GNM – переусложненное запутанное говно. По сравнению со всем остальным – восторг

Комитеты по другому не умеют.

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

А с DirectX 12 часом описание не сравнивал?

Во-первых непонятно зачем перекорёжили гомогенные координаты – ось y зачем-то направили вниз

Я бы вообще и горизонтальную ось изменил справа-налево. Чтобы разработчик понимал, что выбранная система координат 3D-пространства никак не связана с системой координат проекции камеры. И мапить одно в другое нужно всегда в том или ином виде. Шутка конечно про справа-налево, но думаю смысл понятен.

В OpenGL замечательная система шейдерных модулей, для которых компиляция отделена от линковки

В Vulkan точно так же, скомпилированные модули в SPIR-V, линковка в пайплайне, комбинировать модули друг с другом после компиляции как угодно.

Приложение само может компилить твой шейдер в SPIRV. Мой Vulkan рендерер зависит в рантайме от glslang ради этого.

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

Разница в том, что Vulkan приложение должно будет перекомпилить целиком стадию (внёс изменения, например, в вершинный шейдер – все вершинные шейдеры этого материала (точнее пайплайна) нужно будет пересобрать), что значительно сильнее ударит производительность. Если шейдеры меняет человек в live режиме в каком-нибудь редакторе, это нормально. Там можно хоть на целую секунду подвиснуть. Если же шейдер меняется программой, как реакция на некое событие, то жопь.

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

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

Там можно хоть на целую секунду подвиснуть.

Но почему-то те же IDE прекрасно работают с подсветкой синтаксиса и даже тяжелющими компиляторами C++ кода в реальном времени без подвисаний. Всё из-за добавления промежуточной стадии между пользовательским вводом и откликом парсера, когда новых данных от последнего ещё нет, но редактор продолжает нормально работать.

Я бы вообще и горизонтальную ось изменил справа-налево

Да хоть по диагонали! Хоть экранные координаты вместо гомогенных туда засунуть можно. Просто когда можно в шейдере на каждую вершину выполнять на 1 матричное умножение меньше, за счёт того, что матрица view_projection matrix на хосте расчитан, то хочется этим воспользоваться. В этом суть оптимизации.

скомпилированные модули в SPIR-V, линковка в пайплайне

The stage member of each element of pStages must be unique

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

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

Но почему-то те же IDE прекрасно работают с подсветкой синтаксиса и даже тяжелющими компиляторами C++ кода в реальном времени без подвисаний.

Вы когда IDE последний раз видели? У меня Qt Creator после запуска целую вечность (около 15 секунд – 15000000 микросекунд) работает в режиме блокнота – код не раскрашен, автодоп не работает, навигации по коду нет. Мне норм подождать 15 секунд, пока сессия в Qt Creator прогрузится, но в графическом движке поиметь фреймтайм в 15000000 почти равносильно катастрофе.

Не интересуюсь DirectX.

Entry point-ов может быть несколько

Но шейдерный модуль – только 1 на стадию.

шейдерный модуль может иметь несколько конфигураций с параметризованной компиляцией

Константы специализации? Они же именно что константы, да ещё и строго скалярные. Подходят для динамических массивов (не то чтобы для этого SSBO не подходили, ЛОЛ), для метапрограммирования (даже такого зачаточного, как у меня в движке уже есть) – нет.

Ты перекомпилируешь проект при внесении изменений в исходники? Чем шейдеры должны отличаться?

Ты перекомпилируешь игру при изменении скриптов? Чем шейдеры должны отличаться?

Эмм.. OpenGL как бы тоже компилирует шейдеры, а не интерпретирует их. Просто делает это эффективнее, чем glslang.

А как этот shaderc уговорить линковать несколько модулей в одну стадию? Уж лучше glslang, тот, пусть и неэффективно, но умеет в линковку.

не давать пользователям в руки шейдеры в принципе? Но это же дно-о-о. Мы так в 90-е – 00-е вернёмся, когда был только фиксированный графический конвейер – и всё. В 20-х у нас будет чуть больше моделей освещения/затенения, парочка интересных эффектов водной поверхности, огня и т.д. Но всё так же никакой гибкости.

когда куплю поддерживающую эту Джамалунгму видеокарту, тоже начну пердолиться

NVIDIA поддерживает начиная с Kepler, AMD с GCN 1.0, Intel с Ivy Bridge. Это что же за видюха такая, которая не поддерживает; как на такой играть – да чёрт с ним, с «играть», как на такой видео смотреть 0_0

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

The stage member of each element of pStages must be unique

Не нет, а да (-: Речь идёт про поле VkShaderStageFlagBits, которое обязано быть уникальным, то-есть при линковке нельзя, к примеру, использовать одновременно два фрагментных шейдера VK_SHADER_STAGE_FRAGMENT_BIT.

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

Вы когда IDE последний раз видели? У меня Qt Creator после запуска целую вечность (около 15 секунд – 15000000 микросекунд) работает в режиме блокнота – код не раскрашен, автодоп не работает, навигации по коду нет.

QtCreator — мой ежедневный рабочий инструмент. Я подобный пример и имел в виду и твой ответ только его подтверждает. Чудес не бывает, если парсеру синтаксиса нужно 15 секунд, то их так или иначе прийдётся дождаться. Вопрос только какое должно быть поведение редактора в это время. Если заблокировать UI не вариант, то нужно дать возможность навигации и редактирования неподсвеченного текста, что тот же QtCreator и делает.

Поведение конечно же будет меняться от программы к программе. В играх, к примеру, часто делают подгрузку потенциально скоро используемых ресурсов в фоне. Но если игра не угадала или не успела подгрузить, то могут временно показывать пустые локации, заглушки шейдеров, размытые текстуры с большим mip-level, и так далее. Если это не вариант, игра может в крайнем случае временно заблокироваться с плашкой «Loading…».

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

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

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

Ты перекомпилируешь игру при изменении скриптов? Чем шейдеры должны отличаться?

WC3, SC2, Unreal engine свои скрипты компилируют, если чо. Потому что производительность. И перекомпиляция скриптов не ведет к перекомпиляции всего движка. Вот если бы ты сказал «шейдеры 10 минут перекомпилируются, так невозможно работать», то я бы сказал «да, это никуда не годится, нужно срочно что-то с этим делать».

OpenGL как бы тоже компилирует шейдеры, а не интерпретирует их. Просто делает это эффективнее, чем glslang

Он их перекомпилирует по необходимости. Или все-таки есть инфа, что opengl таки какой-то магией делает трансляцию эффективнее?

А как этот shaderc уговорить линковать несколько модулей в одну стадию? Уж лучше glslang, тот, пусть и неэффективно, но умеет в линковку

В этой стране в принципе геймдев не существует как индустрия.

Ржал яки конь. Если ты не знаешь геймдевных компаний отечественных, то это вовсе не значит, что их нет.

Потому что производительность Вот если бы ты сказал «шейдеры 10 минут перекомпилируются, так невозможно работать», то я бы сказал «да, это никуда не годится, нужно срочно что-то с этим делать».

Он их перекомпилирует по необходимости. Или все-таки есть инфа, что opengl таки какой-то магией делает трансляцию эффективнее?

Во-первых – он перекомпилирует только тот модуль, который был изменён, а не целиком всю стадию.

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

Если даже настолько простые технологические решения, как раздельная компиляция, для вас магия, то я даже и не знаю что сказать.

Слабать мобильную дрочильню – не геймдев

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

Не меняют. Просто теперь движок должен учитывать, что экранные координаты бывают не только такие, как в OpenGL. Никакой катастрофы тут нет, просто небольшое усложнение кода.

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

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

То что называется компиляция в SPIRV это не обязательно означает прохождение таких-же стадий что и при компиляции в машинный код. Например можно написать компилятор Python/Ruby кода в GLSL текстовое представление, станет ли GLSL от этого хуже? При компиляции в SPIRV происходят алгоритмические оптимизации, которые актуальны для любой архитектуры и которые можно сделать единожды вместо-того чтоб надеяться что компилятор драйвера сделает именно эту оптимизацию.

Сам подумай что проще для разработчиков GPU писать кучу компиляторов GLSL/HLSL/Cg/etc. и поддерживать разные версии или всего один компилятор который компилирует SPIRV?
Аналогично для разработчиков игр, им приходится под Linux один язык использовать, под Windows другой. Это нихрена не удобно. В итоге все-равно все сводится к тому что создали/создадут компилятор условно «универсального шейдерного языка» или С/C++/etc. в GLSL/HLSL/Cg/etc.
Плюс надо учитывать что пользователи не часто обновляют драйвера и если у пользователя старые драйвера в котором у GLSL/HLSL/Cg/etc. компилятора еще нет какой-то оптимизации то разработчикам игры ничего не остается кроме как показать сообщение игроку про необходимость обновления драйвера. А что если оптимизации вообще не завезли? А никаким изменением исходного кода добиться этой оптимизации невозможно так как нет низкоуровневого доступа, именно такого какой дает SPIRV.
С помощью SPIRV разработчик может оптимизировать представление с помощью новых оптимизаций которые вот только вчера придумали так чтоб оно скомпилировалось в машинный код драйвером в максимально эффективный код в независимости от того насколько древний драйвер и насколько древний компилятор там.

Не нет, а да (-: Речь идёт про поле VkShaderStageFlagBits, которое обязано быть уникальным, то-есть при линковке нельзя, к примеру, использовать одновременно два фрагментных шейдера VK_SHADER_STAGE_FRAGMENT_BIT. При этом сами модули (VkShaderModule) могут быть загружены один раз и многократно использоваться в разных пайплайнах.

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

Это и есть линковка. Когда в одном шейдере у нас, например

И они линкуются в единую стадию.

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

А то, что стадии независимы, так это совсем другое.

Если нужно перекомпилить шейдер на лету, то хоть ты тресни, на это нужно потратить время

Да ладно 😀 Скажем в нашем примере поменяется только второй шейдер. Станет

В OpenGL эта задача никак не решалась, компиляторы GLSL, как правило, встроены прямо в драйвер и точно так же кушают процессорное время

Кушают его меньше, так как выполняют меньше работы.

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

Простой перенос может и улучшит. Вот только glslang это не компилятор шейдеров, перенесённый из драйвера. Это кривоватая его замена, заглушка в лучшем случае.

Тогда, в OpenGL мы только его и перекомпилим и слинкуем программу заново.

Я вот смотрю что написано в спецификации SPIRV 1.0: https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html
И там написано что можно вызывать функции из уже скомпилированных модулей, как ты это описал.

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

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

Нет. SPIRV – это именно что промежуточное представление. И у SPIRV есть собственная текстовая форма.

Аналогично для разработчиков игр, им приходится под Linux один язык использовать, под Windows другой. Это нихрена не удобно.

А зачем. OpenGL под Windows тоже есть.

в независимости от того насколько древний драйвер

Нет. Есть оптимизации, которые уместны при компилировании SPIRV в машинный код. Есть также неилюзорная возможность накосячить при компилировании SPIRV в машинный код. ACO/RADV от RADV отличается только компилятором. При этом производительность их отличается. Причём не только на этапе компилирования шейдеров. То же и с AMDVLK и amdgpu-pro

Нет. Есть оптимизации, которые уместны при компилировании SPIRV в машинный код.

Я в том смысле что есть бОльший контроль над оптимизацией при использовании SPIRV, так как он предоставляет больше возможностей. Я не спорю что от компилятора драйвера ничего не зависит, но это лучше чем было. Тут можно взять к примеру IR LLVM представление и clang как фронтенд. И тут clang может провести многие оптимизации которые увеличат конечную эффективность машинного кода.

SPIRV открывает двери новым языкам и абстракциям, теперь буквально можно на любом языке писать шейдеры лишь бы был компилятор в SPIRV. Конечно можно было бы и раньше в те-же GLSL/HLSL/Cg/etc. компилировать, но вот такой-же эффективности уже не было-бы.

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

ЯННП. В нормальных движках (UE4 например) исходник материала – это граф из математичестких нод, параметров (константы, геймплейные параметры (позиция игрока в мире, настройки FOVа), текстуры) и движковых сущностей (время, frame id, whatever), который компилируется в исходники шейдеров, которые потом отдаются компилятору шейдеров. И всё это сшивается в файл материала, с которым уже и работает движок в рантайме. И в рантайме ничего никуда компилировать не нужно. На гибкость тоже никто не жалуется.

Ты перекомпилируешь игру при изменении скриптов? Чем шейдеры должны отличаться?

Источник