Vulkan API (вышел!) (540 стр)

disambiguation
> зачем мне Вулкан, отвечаю - для GUI
Это эпично. Атомной бомбой - да по воробью. :))
Впрочем, я бы и сам бы так сделал. :)

ImGui хорош для прототипирования интерфейса и тестирования.
Для солидного Gui все же лучше использовать Retained mode подход и тем же gapi все отрисовывать, да и ещё 3d интерфейс можно если будет потребность.

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

Вон помню Andrey кажется подсказывал что новичкам желательно разобраться в Основных техниках машинной графики и фиксированном графическом конвейере, взяв DX11, потом будет более легкий переход на программируемые вулкан / дэикс12.
Но лично сам поперся сразу в программируемый вулкан. Благо видосы есть, книги есть. Все в принципе можно изучить.

disambiguation
> Кстати, Суслик спрашивал зачем мне Вулкан, отвечаю - для GUI

disambiguation
> вот именно, поэтому поковыряв ваш вулкан я вдруг понял, что вместо основноного
> проекта я занмаюсь  какой-то нелепой борьбой с gapi ради рисования кнопочки или
> какой-то другой мелочи, объём кода растёт в геометрической прогрессии, причём
> полезного кода там процентов 10
В том то и дело что "платим" кодом настройки ради скорости.
Вулкан и задумывался чтобы программист графики понимал что делает видеокарта, отсюда и вытекают обширные "structure info" для функций, и самих функций до Hello Triangle нужно вызвать поболее чем было раньше на gapi с fixed pipeline.

Надо просто видеть преимущества и в чем эффективность.
Если смотрите в будущее и хотите напрямую использовать современные gapi от хронос груп или майкрософт то платите цену за "порог входа".
Во всех остальных случаях аля "побыстрее" для бизнес приложений Qt, C++ Builder, а для игр Godot.

phridrich
Когда портируешь свой мобильный движок на 150 дроколов на вулкан.

Так Vulkan ещё не сильно low-level, просто дали абстракции в виде command buffer, queues и барьеров. GNM для плойки намного более low-level.

lookid
> Когда портируешь свой мобильный движок на 150 дроколов на вулкан.
Забавно, но как раз для мобил от вулкана может быть очень много толка даже с 150 дроколами за счёт рендерпассов.

Я периодически смотрю как работают разные обертки над вулканом, уже придумал экспресс-тест, как отфильтровать совсем негодные:
- Аллокация памяти без кэширования.
- Загрузка данных из cpu в gpu через отдельные командный буфер и ожидание gpu после сабмита.
— Дополнительно: любое излишнее количество вызовов vkQueueSubmit, что сильно замедляет цп.
- Продублировать запись в буфер/текстуру и проверить вставится ли между ними барьер.
- Включить в слоях валидации проверку синхронизаций и запустить какой-нибудь сложный сэмпл.
- В рендердоке захватить кадр и посмотреть какие рендер пассы, какие барьеры, используется ли buffer dynamic offset, кэшируются ли дескрипторы и тд.

В итоге большинство оберток проваливают уже первые 3 теста, это печально.

/A\
> - Аллокация памяти без кэширования.
Без кэширования чего?

/A\
Что за аллокация памяти с кэшированием?

/A\
> Загрузка данных из cpu в gpu через отдельные командный буфер и ожидание gpu
> после сабмита.
Это например когда грузишь текстуры и геометрию с VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT ?
а ждать я так понимаю попозже или в самом конце, давая другую работу CPU/GPU?
> кэшируются ли дескрипторы и тд.
это минимизация vkUpdateDescriptorSets в кадре? Повторный вызов VkCmdBindVertexBuffers/
vkCmdBindIndexBuffer/VkCmdBindPipeline ?
>- Продублировать запись в буфер/текстуру и проверить вставится ли между ними барьер.
Ну это уже полноценная система должна быть. Очень высокоуровневое реализация. Не для оберток это, их цель упростить работу с Vulkan соблюдая простейшие рекомендации по оптимизациям.
К тесту можно добавить
- vkResetCommandPool + VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT
- Immutable Samplers

и многое другое.

prowkan
> Без кэширования чего?
Я про всякие аллокаторы типа VMA, которые выделяют кусок памяти и на нем уже размещают ресурсы.
Потому что постоянное выделение и освобождение памяти может снизить фпс до 10 на стороне цпу.

Andrey
> Это например когда грузишь текстуры и геометрию с VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT ?
да

> а ждать я так понимаю попозже или в самом конце, давая другую работу CPU/GPU?
Ну да, представь у тебя уже что-то тяжелое выполняется на гпу, а тут ты залил данные в буфер, и ждешь на цпу, когда же они скопируются.

> это минимизация vkUpdateDescriptorSets в кадре?
Ну вот в UE я видел очень большое количество дескрипторов и ResetDescriptorPool в начале кадра, что очень плохо для мобилок. При этом dynamic offset + кэширование дескрипторов дает неплохой выигрышь особенно в однопоточном коде.

> Повторный вызов VkCmdBindVertexBuffers/ vkCmdBindIndexBuffer/VkCmdBindPipeline ?
Это не так дорого и решается сортировкой в пользовательском коде, так что не критично.

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

> К тесту можно добавить
> - vkResetCommandPool + VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT
> - Immutable Samplers
А насколько они влияют на производительность?

А еще robustBufferAccess должен быть отключен в релизе, потому что это единственная фича, которая дает заметное снижение производительности.

/A\
>Ну вот в UE я видел очень большое количество дескрипторов и ResetDescriptorPool
это ваще жесть, vkResetDescriptorPool я даже не использую, вот поэтому не много игр на Vulkan на мобилках. До сих пор не написали эффективный рендер на UE4?
> А насколько они влияют на производительность?
vkResetCommandPool + VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT
это в примерах Khronos(ARM) можно глянуть, это вообще одна из первых рекомендаций, про это Арсений пишет

>Immutable Samplers
это и для Direct3D12 тоже как рекомендация, семплеры в шейдере компилируются, более оптимальный код на стороне драйвера при создании PSO. AMD рекомендует, так-же Арсений пишет

/A\
> А еще robustBufferAccess должен быть отключен в релизе, потому что это
> единственная фича, которая дает заметное снижение производительности.
да, это отключил. хорошая тузла об этом сказала

Andrey
> До сих пор не написали эффективный рендер на UE4?
тебе, конечно, виднее, шо делается в движках мирового класса