Сам реквестирую что-то про применение сабжа на практике. Читать про устройство очередей, командных буферов и прочих пулов безусловно интересно, но не совсем ясно в каком виде все это добро эффективно применять ИРЛ. Разве что в исходниках готовых проектов копаться.
Это уж точно не для индей. Это если ты хочешь в Эпик устроиться уеч писать - делаешь демку для портфолио, и тебя зовут.
>точно не для индей
Vulkan сложнее ГЛ?
Да
Сложнее вообщем или при одинаковом результате требует большей квалификации
>Another alternative is to use an engine like Unreal Engine or Unity, which will be able to use Vulkan while exposing a much higher level API to you.
Всё, можно закрывать тренд.
Сравнение производительности с опенгл
https://www.youtube.com/watch?v=hvdAVsjrQRM
https://www.youtube.com/watch?v=hvdAVsjrQRM
У меня бомбит пукан от вулкана, как-то пробовал вкатиться, просидел часа 3, чтобы вывести сраный треугольник, насколько же многословное и муторное апи, нихуя не понятно.
Опенгл кор профиль - нужно в десять раз меньше кода, чтобы вывести этот треугольник, все намного логичнее и понятнее.
Так что согласен, что пукан не для инди, ты будешь два года писать рендер вместо игры. На том же опенгл гораздо быстрее это сделать, и для инди перфоманса хватит
Сравнение числа строк кода, которые нужно написать, для отображения треугольника
https://dtf.ru/flood/70897-sravnenie-chisla-strok-koda-kotorye-nuzhno-napisat-dlya-otobrazheniya-treugolnika
Вулкан это более низкоуровневое апи, он нужен для ААА проектов.
Говно, не нужно. Бессмысленная бюрократия с заполнением сотен параметров.
Производительно в два раза больше и графоний попиздаче.
Этим должны заниматься инженеры-гайковёрты, а не инди-кодерки.
Вулкан специально придумали, чтобы повысить планку входа.
Верните мне мой glBegin - glEnd!
Инди кодерки получат удобный фреймворк который напишут инженеры задроты.
Мне кажется достойная награда за еблю с api.
проблема вот в чем - есть вывод треугольника - но блядь нигде нет толкового минимального примера вывода нескольких треугольников в виде гайда.
да и вообще - какого мудозвона эти идиоты пишущие уроки по вулкану код собственно вывода треугольника размещают в том же месте где и код связи с контекстом? а Я потом сижу и офигиваю не понимая как разделить мух от котлет
да и вообще - какого мудозвона эти идиоты пишущие уроки по вулкану код собственно вывода треугольника размещают в том же месте где и код связи с контекстом? а Я потом сижу и офигиваю не понимая как разделить мух от котлет
Дальше вывода треугольника никто и не заходит, зачем запариваться?
Когда ты начнешь писать полноценный рендерер со всякими множественными проходами, анимацией, динамической геометрией и хитрым рендерингом ландшафта, то разница будет не такая большая, и вулкан даже может оказаться проще, потому что не нужно бороться с легаси костылями.
В принципе все эти сложные настройки будут спрятаны за тонами абстракций и можно будет сделать такой же краткий кода на на GL.
вот бы где-нибудь найти прям самый минимальный минимальный рендер движок-пример как этот ваш вулкан юзать
ну чтобы этот движ мог выводить модельку, несколько моделек, умел постобработку, рендер в текстуру..
и все это с учетом многопоточной архитектуры рендера (вот реально - новые гапи многопоточны - а как эту многопоточность для них делать?)
Но именно пример, а не либы типа bgfx где за тоннами абстракций ничерта не разобрать
ну чтобы этот движ мог выводить модельку, несколько моделек, умел постобработку, рендер в текстуру..
и все это с учетом многопоточной архитектуры рендера (вот реально - новые гапи многопоточны - а как эту многопоточность для них делать?)
Но именно пример, а не либы типа bgfx где за тоннами абстракций ничерта не разобрать
Проходите с миром дальше, гражданин.
В составе SDK есть кое-какие примеры. Но в реальном рендере будут как раз тонны абстракций.
да все эти примеры - вывод треугольника на экран. этого было достаточно во времена OpenGL 1.1, но эти примеры вообще никак не показывают как пользоваться вулканом
Это как если бы все книги по программированию заканчивались на hello world, а дальше сами как-нибудь
>>Но в реальном рендере будут как раз тонны абстракций.
Абстракции бывают разной сложности. Тем более что эти абстракции часто "пахнут" - содержат кучу устаревшего кода, говнокода и сломанной архитектуры накопившиеся за годы разработки и смену гапи с какого-нибудь DX9 (например bgfx)
Я вывел куб, и написал свою камеру. Хотя чесно говоря, рендер треугольника на вулкане это наверное наиболее унылое прохождения туториала, которое я когда либо делал.
А вообще, что вы разнылись то.
Вот же вывод целого дома из туториала с оп-поста
https://vulkan-tutorial.com/Loading_models
Алсо рекомендую смотреть Капулькина, интересный чел, шарящий в графике.
https://www.youtube.com/channel/UC-ezuDjNxEbCiba829s7gSQ
https://zeux.io/
Мимопроходил
OpenGL проектировался когда были другие архитектуры железа. Мультипроцессорность была только в теории, и считалась уделом суперкомпьютеров и ненужной для пользовательских ПК.
Можно привести аналогию: OpenGL == C++, Vulkan == асинхронный Assembler + hardware threads. Например, в C++ сейчас довольно много архитектурных косяков, которые пытаются решить новыми стандартами, объявляют какие вещи устаревшими, потому что они концептуально неверны и не подходят под современные реалии.
Но, при этом, вы можете всё то же самое написать на ассемблере, но нужно намного лучше понимать, как работает процессор и ОС, самому писать примитивы синхронизации, и т. п.
Для этих же целей и создавался вулкан. Для программирования на нём, нужно знать все тонкости железки, читать кучи пейперов от той же НВидии, исследовать, придумывать новые фичи для современных архитектур с нуля, которые изначально были придуманы в OpenGL, но для старого железа.
Т. е. на Вулкане нужно делать больше руками, больше оптимизировать. Вместо одного вызова функции OpenGL, на вулкане придётся несколько сотен строк написать. При этом, если вы не понимаете какой-то одной тонкости, вы сделаете менее эффективнее то, что изначально было хорошо реализовано в OpenGL. К тому же, OpenGL умеет выбрасывать ошибки, в случае, когда вы где-то накосячили. Вулкан же их не выбрасывает, он полагается на то, что вы уже знаете как этим пользоваться. Точно так же, как ассемблер просто меняет состояние регистров, у него нет понятия ошибки. Как интерпретировать эти регистры, зависит от того, насколько хорошо разработчик читал мануал к процессору.
В итоге, я бы ответил так:
Если вы будете заниматься графикой как наукой, дико задротить а-ля Кармак в студенчестве с его движками, что-то исследовать, писать какие-то гениальные алгоритмы, защищать на этом диссертации, публиковать их, рассказывать потом на конференции, как вы круто справились с какой-то насущной задачей, повысили производительность, то тогда учите Vulkan. Vulkan — это именно про графику как технологию, про производительность, про инжиниринг и архитектурный дизайн, а не про API и само программирование. С вулканом придётся больше сидеть с диаграммами, документациями и строить архитектуру, придумывать методы взаимодействия частей этой архитектуры, синхронизации состояний, нежели писать код.
Если же вы пишете простые прикладные вещи, которым нужно показать какую-то графику, то учите OpenGL. Здесь вы учите только API, соглашаясь с уже готовым, слегка устаревшим, архитектурным дизайном.
Если хотите писать игры не мирового класса, то учите готовые движки, Unity или Unreal. Они уже поддерживают за вас Vulkan, продумали за вас API и архитектуру.
Можно привести аналогию: OpenGL == C++, Vulkan == асинхронный Assembler + hardware threads. Например, в C++ сейчас довольно много архитектурных косяков, которые пытаются решить новыми стандартами, объявляют какие вещи устаревшими, потому что они концептуально неверны и не подходят под современные реалии.
Но, при этом, вы можете всё то же самое написать на ассемблере, но нужно намного лучше понимать, как работает процессор и ОС, самому писать примитивы синхронизации, и т. п.
Для этих же целей и создавался вулкан. Для программирования на нём, нужно знать все тонкости железки, читать кучи пейперов от той же НВидии, исследовать, придумывать новые фичи для современных архитектур с нуля, которые изначально были придуманы в OpenGL, но для старого железа.
Т. е. на Вулкане нужно делать больше руками, больше оптимизировать. Вместо одного вызова функции OpenGL, на вулкане придётся несколько сотен строк написать. При этом, если вы не понимаете какой-то одной тонкости, вы сделаете менее эффективнее то, что изначально было хорошо реализовано в OpenGL. К тому же, OpenGL умеет выбрасывать ошибки, в случае, когда вы где-то накосячили. Вулкан же их не выбрасывает, он полагается на то, что вы уже знаете как этим пользоваться. Точно так же, как ассемблер просто меняет состояние регистров, у него нет понятия ошибки. Как интерпретировать эти регистры, зависит от того, насколько хорошо разработчик читал мануал к процессору.
В итоге, я бы ответил так:
Если вы будете заниматься графикой как наукой, дико задротить а-ля Кармак в студенчестве с его движками, что-то исследовать, писать какие-то гениальные алгоритмы, защищать на этом диссертации, публиковать их, рассказывать потом на конференции, как вы круто справились с какой-то насущной задачей, повысили производительность, то тогда учите Vulkan. Vulkan — это именно про графику как технологию, про производительность, про инжиниринг и архитектурный дизайн, а не про API и само программирование. С вулканом придётся больше сидеть с диаграммами, документациями и строить архитектуру, придумывать методы взаимодействия частей этой архитектуры, синхронизации состояний, нежели писать код.
Если же вы пишете простые прикладные вещи, которым нужно показать какую-то графику, то учите OpenGL. Здесь вы учите только API, соглашаясь с уже готовым, слегка устаревшим, архитектурным дизайном.
Если хотите писать игры не мирового класса, то учите готовые движки, Unity или Unreal. Они уже поддерживают за вас Vulkan, продумали за вас API и архитектуру.
на самом деле нет, всё не так. Люди ковыряющие Direct3D 11 на серьезном уровне уже все тоже самое делали что теперь дает вулкан, и также делали руками.
И когда говорят что на вулкане треугольник выводится в мульон строк, а на огл в пару - то вообще-то сравнивают с ОГЛ 1.0 с его glBegin/glEnd (которые никто уже давно не использует).
Кроме того из этого мульона строк, 90% строк - инициализация контекста вулкана. А количество строк для вывода треугольника столько же сколько для OGL 4.3/D3D11
Зачем вообще вулкан настолько мистифицируют? это не ассемблер и даже не рядом. Как раз наоборот. OpenGL - это Си. Vulkan - это java. Вулкан дает больше, он гибче, но в нем больше теории и нужно другое мышление.
Или даже другой пример - шейдеры. когда-то был fixed-pipeline который делал всё за тебя: освещение, тени, постэффекты, даже матрицы и трансформации - все это делала сама видеокарта. Потом ввели шейдеры и убрали fixed-pipeline, заставив программистов самостоятельно писать свое освещение, тени, постэффекты, матрицы.
Стало ли сложнее? первоначально да, тогда тоже ругались. Но теперь нет - сейчас любой художник через какой-нибудь визуальный редактор пишет шейдеры
Собственно сложность текущего вулкана:
- вулкан требует другого мышления (из просмотренного мною кода в гитхабах большинство не могут в туже многопоточность, потому что все еще мыслят в терминах OGL/DX, и почти никто не понял фишки физ/лог устройств)
- сейчас нет внятной теоретической документации объясняющей новую терминологию - теже очереди например
низкоуровневость и многАкода - это не сложно. Кому от этого сложно - вы не программисты
Игры то пилишь? Показувай.
>Люди ковыряющие Direct3D 11 на серьезном уровне уже все тоже самое делали что теперь дает вулкан
Ну-ка расскажи как они обошли неявное управление памятью драйверами D3D 11?
ну во-первых менеджер памяти в вулкане не обязательно писать.
во-вторых в D3D11 был blob (тобишь кусок сырых данных отправленный в видеокарту)
SaschaWillems на гитхабе. В свое время отсосал бы этому чуваку за его примеры.
Почему vulkan не поддерживает 24 битные текстуры? По крайней мере зеленые девайсы посылают нахуй c VK_FORMAT_R8G8B8_... и VK_FORMAT_B8G8R8_...
Не, я конечно могу брать и 32, но это же не логично - четверть памяти получается мертвый груз.
Не, я конечно могу брать и 32, но это же не логично - четверть памяти получается мертвый груз.
>https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkDescriptorImageInfo.html
>imageView must not be 2D or 2D array image view created from a 3D image
Эта глистопараша еще и не может 2д слой из 3д текстуры забиндить в 2д семплер. То, во что человеческие апи типа ГЛ'а давно умеют. Какой-то кроносопетух https://github.com/KhronosGroup/Vulkan-Docs/issues/1033 предлагает "а почему бы тебе не истользовать 3д вью". Охуенная идея, когда у тебя 100500 шейдеров.
>imageView must not be 2D or 2D array image view created from a 3D image
Эта глистопараша еще и не может 2д слой из 3д текстуры забиндить в 2д семплер. То, во что человеческие апи типа ГЛ'а давно умеют. Какой-то кроносопетух https://github.com/KhronosGroup/Vulkan-Docs/issues/1033 предлагает "а почему бы тебе не истользовать 3д вью". Охуенная идея, когда у тебя 100500 шейдеров.
Я в этих всех штуках не разбираюсь, так что нубский вопрос. Это нужно чисто для графических нужд, или с помощью вулкана можно произвольные вычисления на GPU производить?
Если не можешь, то попробуй это использовать как-то с пользой. Запихни в Альфа канал шонибудь, чтоб память не проебывать
Можно, гугли vulkan compute pipelines
Моё почтение.
Знаю что можно собрать hlsl в spir-v, компильнуть его и загнать в вулкан или опенгл. А spir-v собранный из glsl исходников можно как-то заюзать в 12 директе?
Как же раздражают форматы примеров/уроков где пол кода скрывают оболочками прямо сразу. При этом делая универсальную оболочку под все случаи жизни.
решил поизучать Sascha Willems. Открываю первый пример triangle, думаю писать по аналогии свое, чтобы быстрее запомнить что как делается, одновременно думая над своей архитектурой....
Нахуя оно там наследуется от VulkanExampleBase, в котором дохрена всего понапихано вплоть до работы с imgui? И ладно бы если бы там было базовое про окошки, клаву-мышь, там еще и дохрена всего работающего с вулканом - блядь, я же как раз пришел его изучать, нахрена он все скрыл в этом классе?
Я просто хочу сам написать вывод треугольника. Но вместо этого я должен ковыряться в левом коде и думать, а надо мне эта камера, а эти бенчмарки, а гуи, а хуи?
Бесит...
Почему нельзя делать по нормальному?
решил поизучать Sascha Willems. Открываю первый пример triangle, думаю писать по аналогии свое, чтобы быстрее запомнить что как делается, одновременно думая над своей архитектурой....
Нахуя оно там наследуется от VulkanExampleBase, в котором дохрена всего понапихано вплоть до работы с imgui? И ладно бы если бы там было базовое про окошки, клаву-мышь, там еще и дохрена всего работающего с вулканом - блядь, я же как раз пришел его изучать, нахрена он все скрыл в этом классе?
Я просто хочу сам написать вывод треугольника. Но вместо этого я должен ковыряться в левом коде и думать, а надо мне эта камера, а эти бенчмарки, а гуи, а хуи?
Бесит...
Почему нельзя делать по нормальному?
Тут так, как ты хочешь.
https://vulkan-tutorial.com/Introduction
У Sascha Willems скорее примеры того, как делать какие-то конкретные штуки, чем туториалы.
тут тоже хуйня, все в один класс ебошат, потом сидишь и не понимаешь как переделать под себя, например вывести несколько мешей
Есть где-нибудь пример вывода нескольких разных мешей не обвешанный гиганскими фреймворками?
Просто реально сложно понять как это сделать. Все туторы про вывод одной модели. Гугл ищет вместо этого инстансинг, что тоже не то.
А то тут читал vulkan-tutorial - там вроде писали что нельзя просто так взять и вывести много моделей без правильного управления памятью. От этого стало еще сложнее думать как эту хрень сделать
Просто реально сложно понять как это сделать. Все туторы про вывод одной модели. Гугл ищет вместо этого инстансинг, что тоже не то.
А то тут читал vulkan-tutorial - там вроде писали что нельзя просто так взять и вывести много моделей без правильного управления памятью. От этого стало еще сложнее думать как эту хрень сделать
> нельзя просто так взять и вывести много моделей без правильного управления памятью
Всё так. Нельзя взять и вывести модель. Нужно правильно навешивать текстуры, шейдеры, мапы всяческие, правильно их обрабатывать для рендера и правильно хранить. Ну и плюс соблюдать общие пайплайны рендера - форвард/деференд/форвард+/форвардкластер/деференд кластер. Потом нужно навешивать куллинг (это когда ты не рендеришь то, что не нужно рендерить, пикрелейтед) и постпроцессинг.
Если захотел анимацию - нужно еще и анимацию правильно хранить и как-то впихнуть её.
> От этого стало еще сложнее думать как эту хрень сделать
Никак нахуй. Фреймоврков или библиотек подобного рода нет нахуй, чтобы они были отдельно от движка. Вообще нет. Может есть, но я не нашел.
Такие дела.
>Фреймоврков или библиотек подобного рода нет нахуй,
Есть vulkan memory allocator, если ты про память. Избавляет от низкоуровневой мозгоебли с пулами и аллокациями. Очень годная штука, её используют даже в некоторых ААА проектах (не скажу каких).
Не, я говорю про сам рендер, как его строить в каком формате бинарном хранить данные вершин, например, кватернионами или матрицами, как передавать анимации вершин, как совмещать тени, свет, как это всё объеденят и выводить на экран. Или как строить пбр-модель, все эти функции франеля, блядь, чего нахуй, как их в рендер-то хапихнуть? Че ебать че делать-то ыыыааа пёрд
На аллокаторы похуй вообще, есть тысячи хайлвл библиотек. И вообще 300 мегабайт хватит всем.
Допустим, я хочу разрабатывать ААА игры, и как нужно выучить Vulkan, и какую демку запилить, чтоб можно было смело идти на собес?
Нужно сделать свой 3d рендер, опенсорс. Рендер должен быть на bgfx построен и использовать entt. Иметь реализацию какого-нибудь кластерного рендера.
Справишься? После этого в рокстаргейм возьму сразу же.
Разве bgfx уже не рендер?
Бля, чуваку который сделает самую простую демку выводящую пару моделек с разными шейдерами на экран можно будет поставить памятник героя.
Это пиздец, сейчас все делятся на вида:
- нубы, которые сами нихрена не знают
- нубы, которые еще и зачем-то пытаются учить других, переписывая в сто пятсотый раз урок вывода треугольника (а дальше никто из них не может... серьезно - гуглю уроки - у всех блядь все заканчивается на выводе одного треугольника... ну блядь, выведи хотя бы два треугольника - уже хоть какая-то польза)
- сумрачные кардиналы, которые уже все поняли и разобрались, пишут серьезные вещи на пукане, но не собираются ни с кем делится знаниями.
Это ведь реально проблема - не понятно как блядь надо вывести две-три модельки на экран. Потому что по дефолту влобное решение - говно, упрешься в 4096 лимит чего-то там и всё.
Но никто блядь не хочет показать как надо делать. ни Sascha (может у него где-то и есть, но обвещано говно-фреймворком), ни другие.
Сначала думал что я дурак, но погуглил - а этой темой весь реддит завален, и никто ни в одной теме толком не ответил (обсудают тот лимит, пишут что-то непонятное, но по теме никто не отвечает)
У меня уж третий день бомбит, от этой хуйни
Это пиздец, сейчас все делятся на вида:
- нубы, которые сами нихрена не знают
- нубы, которые еще и зачем-то пытаются учить других, переписывая в сто пятсотый раз урок вывода треугольника (а дальше никто из них не может... серьезно - гуглю уроки - у всех блядь все заканчивается на выводе одного треугольника... ну блядь, выведи хотя бы два треугольника - уже хоть какая-то польза)
- сумрачные кардиналы, которые уже все поняли и разобрались, пишут серьезные вещи на пукане, но не собираются ни с кем делится знаниями.
Это ведь реально проблема - не понятно как блядь надо вывести две-три модельки на экран. Потому что по дефолту влобное решение - говно, упрешься в 4096 лимит чего-то там и всё.
Но никто блядь не хочет показать как надо делать. ни Sascha (может у него где-то и есть, но обвещано говно-фреймворком), ни другие.
Сначала думал что я дурак, но погуглил - а этой темой весь реддит завален, и никто ни в одной теме толком не ответил (обсудают тот лимит, пишут что-то непонятное, но по теме никто не отвечает)
У меня уж третий день бомбит, от этой хуйни
Нет.
> сумрачные кардиналы, которые уже все поняли и разобрались, пишут серьезные вещи на пукане, но не собираются ни с кем делится знаниями.
Ну есть книжечки в которых описано. Можешь их почитать, структуру рендера.
> У меня уж третий день бомбит, от этой хуйни
Тебе нужна во-первых виртуальная камера. Во-вторых, мир и мировое пространство (которое на самом деле прост объекты с матрицей "мира"). С этими знаниями ты выведешь свои ссаные модели треугольников на экран. Проблемы начнутся позже.
>Ну есть книжечки в которых описано. Можешь их почитать, структуру рендера.
Ты про общие книги по рендеру? Так я не про общую теорию, а про реализацию базовых вещей конкретно на пукане. (книги-то написаны под OGL/DX архитектуру)
Ранее я работал с D3D11/OGL (на начальном уровне, хотя для инди достаточно) - там вообще таких проблем не было, сел и выводи сколько хочешь моделей на экран и используй сколько хочешь шейдеров, и меняй сколько хочешь стейты.
Все книжки по пукану около треугольника и крутся, ну или куба. Например в книге с красной обложкой как раз оно, обзорно рассматривается GAPI, потом выводят куб, и выводят инстансингом несколько кубов (это не то). Больше ничего не увидел.
Как я уже написал - я просто не могу понять как правильно вывести две модели, например дерево и волка, с разными текстурами, и разными шейдерами. Вот такой пример хочу. Вот просто застрял на этом
>Тебе нужна во-первых виртуальная камера. Во-вторых, мир и мировое пространство
Да это вообще не то. Я говорю как в вулкане правильно сделать Draw Call с разными мешами/текстурами/шейдером
> Ты про общие книги по рендеру? Так я не про общую теорию, а про реализацию базовых вещей конкретно на пукане. (книги-то написаны под OGL/DX архитектуру)
Так общие вещи везде одинаковые, что по пукану, что по жлу. Книжечки уровня "сделаем игродвжиок снуля" подойдут и для пукана. Оптимизации ищи в документации, например.
> с разными текстурами, и разными шейдерами.
> Draw Call с разными мешами/текстурами/шейдером
Это полноценный рендер, с управлением памятью, с правильно настроенным рендером материалов и вот это всё. Такое есть либо в игровых движках, либо в рендер-либах, которые к пукану имеют посредственное отношение. Отдельно ничего подобного нет (скорее всего, можешь поискать конечно, не забудь скинуть в тред находки).
Можешь найти какой-нибудь движок (с выбранным тобой пайплайном) и посмотреть у него, да, за тебя всё сделали.
Вопщем-то вариантов не много.
Про есть? Подскажите если я все мапы запихаю (диффуз, нормалы, спекулар, пбр ассеты) в ARRAY у меня теоретически повысится texHitRate в кэш? Или это зависит от железа и нужно профайлить шейдер?
>Нет.
>Cross-platform, graphics API agnostic, “Bring Your Own Engine/Framework” style rendering library.
Да они пиздят. Там кросскомпилятор шейдеров прост прикручен и всё. Никакого рендера там нет. Рендер это когда ты отдаешь модельку, а рендер выдает картинку. А там придется всё это вручную делать.
В чём тогда профиты, кроме этой самой кросскомпиляции?
Кросскомпиляция большущий профит тащемта.
Там еще какие-то порядки рендера есть какие-то, но я в душе не ебу что это, почему и зачем.
>большущий профит
Какой?
>Там еще какие-то порядки рендера есть какие-то, но я в душе не ебу что это, почему и зачем.
Наверное, для того, чтобы несколько прозрачных поверностей работали адекватно.
> Какой?
Большой. Работать будет на говне. Почти как пукан, но хуже. Хотя и для вулкана у него есть пробросы какие-то пиздатые.
> Наверное, для того, чтобы несколько прозрачных поверностей работали адекватно.
Не, это уже хайлвл графон, я ниправильна сказал.
Там какие-то другие порядки скорее всего, не порядки рендера, а порядки хуй знает, матрицы? Текстуры? Буферы? Короче не знаю я и изучать не хочу, сложно слишком и бессмысленно без мидл/хай-лвл обёртки над этим всем.
Во блядь, я прозрел... Я понял что вот эти большие полотна, которые ранее у меня вызывали проблемы с понимаем как с этим работать... Так вот, эти полотна текста, это все тоже самое что в D3D11 я писал device->CreateResource(). Просто в D3D11 - от меня скрыли эти детали, а тут надо их писать...
Не знаю зачем это написал, но реально это озарение, сразу стало легче дальше работать, мозг сразу переключился к пониманию как теперь из этого что-то делать.
Не знаю зачем это написал, но реально это озарение, сразу стало легче дальше работать, мозг сразу переключился к пониманию как теперь из этого что-то делать.
етот код... все кажется что хакают вконтактик
Вот за такое говно надо пиздить головой об асфальт. Собственно из-за этого дауна с его vulkan-tutorial.com и возникает проблемы с пониманием как делать
Потому что блядь этот урод поместил создание командного буфера в инициализацию, совсем не объяснив как надо делать правильно. А без этого знания невозможно идти дальше в вулкане (собственно почему все и тормозят на треугольнике перепечатав его говнокодище и не зная что делать)
Короче аноны, не читайте эту хуйню с vulkan-tutorial.com - это пример того как НЕ НАДО писать уроки.
Лучше всеже читать спеку.
Смотреть как Капулькин страдает на стримах(https://www.youtube.com/playlist?list=PL0JVLUVCkk-l7CWCn3-cdftR0oajugYvd)
Ну и вот я нашел няшу (https://github.com/diharaw/dwSampleFramework где прям по минимуму-минимуму вулканчик)
Потому что блядь этот урод поместил создание командного буфера в инициализацию, совсем не объяснив как надо делать правильно. А без этого знания невозможно идти дальше в вулкане (собственно почему все и тормозят на треугольнике перепечатав его говнокодище и не зная что делать)
Короче аноны, не читайте эту хуйню с vulkan-tutorial.com - это пример того как НЕ НАДО писать уроки.
Лучше всеже читать спеку.
Смотреть как Капулькин страдает на стримах(https://www.youtube.com/playlist?list=PL0JVLUVCkk-l7CWCn3-cdftR0oajugYvd)
Ну и вот я нашел няшу (https://github.com/diharaw/dwSampleFramework где прям по минимуму-минимуму вулканчик)
>Потому что блядь этот урод поместил создание командного буфера в инициализацию, совсем не объяснив как надо делать правильно.
А как правильно, лел? Аллок/деаллок после каждого сабмита? Реюз комманд буферов нормальная практика. Это обычно это 3д массив из буферов (для каждого фреймбуфера, для каждого сабмита, для каждого потока). Пулов по 1 на каждый поток. Ждешь фенсу с предыдущего сабмита и пишешь опять. На, кури https://developer.nvidia.com/blog/vulkan-dos-donts/
>А как правильно, лел?
Так в том и дело что там не показано как правильно.
>Аллок/деаллок после каждого сабмита? Реюз комманд буферов нормальная практика.
Возникает куча вопросов:
- нужно ли создавать новые командные буферы
- если нет, а нужно использовать тот же самый - как перезаливать буфер вершин/индексов/текстуры?
- как быть если количество DrawIndexed меняется - сейчас мы видим 10 моделей, а повернем камеру и будет уже 10к моделей.
- как делать если надо чтобы разные модели разными шейдерами обрабатывались, да еще и разные стейты юзались (скайбоксы например)?
Идея создать командый список, залить в него все команды и юзать была давно, такая фича была даже в каких-то древних версиях OGL 1. Только на практике легче без этого делать, поэтому все это остается только в теории на бумаге и в таких вот бесполезных туториалах
>А как правильно, лел?
Вот я сейчас открыл исходники Unreal Engine 4. Там никто командные буферы не создает во время запуска игры. Там есть и аллокации (через менеджер командных буферов, конечно там все по умному, но факт что они создают новые и удаляют старые), и команды буфера заполняются в рендере, а не непонятно где.
Так что еще раз повторю - уроки на vulkan-tutorial.com - хуйня, так делать нельзя
Там уроки по вулкану, а не по организации рендерера (это отдельная наука)
При чем тут организация рендера, если работа с командными буферами - это часть вулкана? И новичку надо знать что и как с ними делать (и что не делать)
То есть как минимум нужно было написать как выполнять сброс командного буфера и переписывание его новыми командами
Проблема туториалов по вулкану в том что вулкан не для хеллоуворлдов предназначен, а что бы в кишочки движка его было удобно шприцевать с зеро оверхедом.
То есть по хорошему туториал по вулкану должен быть не по вулкану а огромной нудятиной по архитектуре движка.
Зачем? Не нужно учить никаким архитектурам или движкам. Уроки по вулкану должны учить пользоваться вулканом. И учить на типовых задачах с которыми столкнутся все начинающие, чтобы они сразу могли начинать работать над своими проектами, добивая специфичные места уже спекой (спеку сложно читать не имея опыта работы с вулканом)
>>Проблема туториалов
Только в том что ими никто не хочет заниматься. Я хз почему так.
>вулкан не для хеллоуворлдов предназначен
Вулкан - это уже настоящее и изучать его нужно всем рендер-программистам. Альтернатив нет и не будет.
OpenGL 4/Direct3D11 уйдут также как в свое время ушли Direct3D9/OpenGL 2. Когда выпиливали FFP - людям тоже было трудно переосмысливать, но куча уроков помогли безболезненно это пережить многим.
>Проблема туториалов по вулкану в том что вулкан не для хеллоуворлдов предназначен
Я ради любопытства погуглил как пишут вывод треугольника на D3D12. Ведь D3D12 работает по тем же принципам что и вулкан. И что я вижу - автор нормально показал как ОБНОВЛЯТЬ командный буфер.
Почему автор vulkan-tutorial.com написал какую-то херню ?
Он записал обновление командного буфера в том же месте где и его аллокацию, при инициализации. Из-за чего многие просто не понимают что делать дальше - как выводить разную геометрию, как менять содержимое, как переключать стейты/шейдеры.
Может быть опытным прозженным прогерам и так было понятно(например Sascha Willems делает точно такую же херню, но его примеры хотя бы не позиционируются как уроки)
Но для новичков vulkan-tutorial.com написан ужасно (и когда я гуглил возникшие у меня вопросы, я обнаружил что реддит ими переполнен (то есть не я один такой дурак). Тогда как уроки по D3D12 полностью отвечают на все эти вопросы, да они даже не возникают)
>Вулкан - это уже настоящее и изучать его нужно всем рендер-программистам
Настоящее - это использование готовых движков.
Рендер программисты - это очередь в полторы YOBA конторы, 0.75 из которых - YOBAгейдев, а еще 0.75 всякая голивудщина вроде диснея и инженерщина вроде автодеска.
> OpenGL 4/Direct3D11 уйдут также как в свое время ушли Direct3D9/OpenGL 2. Когда выпиливали FFP - людям тоже было трудно переосмысливать, но куча уроков помогли безболезненно это пережить многим.
Как и Direct3D9/OpenGL 2 - лет через 10. Хуан вот из годотетреда наоборот срочно запиливает глес2 вместо глес3.
>Настоящее - это использование готовых движков.
Не всех устраивают готовые движки. Мне например совершенно не нравится писать код игры на C# - не люблю этот язык. И тем более не нравится писать на питоне или луа.
Я программист, для меня важно удобство написания кода. Так что лучше я немножко помучаюсь со своей оберткой, но в итоге буду писать в комфортных для меня условиях. Плюс мне нравится рендер-программирование и я хочу набивать в нем опыт
>Не всех устраивают готовые движки.
Всех.
> Мне например совершенно не нравится писать код игры на C# - не люблю этот язык.
Мамкины борщи тоже вкусные, да.
> Я мамкин программист-байтолюб
Поправил тебя. Алсо, да, удобство написания кода как раз в движках.
В байтоебле тебе нужно изобретать железо из руды, обходить сотни неочевидных граблей, в том числе и баги в актуальных и не актуальных драйверах, изобретать самому вслед за серьезными, высокооплачиваемыми дядями, каждый из которых поумнее тебя будет, архитектуру рендера, короче догонять рыночек на самопальном велосипеде.
> Плюс мне нравится рендер-программирование и я хочу набивать в нем опыт
Этот рынок - полторы конторы, каждая из которых сложилась в 80х-начале нулевых, как уже выше было сказано.
>Всех.
Нет. Тысячи разработчиков пилят свои игры на своих движках.
Например вот такие игры (https://store.steampowered.com/app/371970/Barony/?l=russian) можно делать на любом движке. Но автор сделал на своем коде (там даже движка нет, прям сразу писал)
>Алсо, да, удобство написания кода как раз в движках.
Удобство написания кода напрямую связано с синтаксисом (а еще с IDE). Если язык неприятен - никакого удобства не будет.
>В байтоебле
при чем тут байтоебство? На это вообще похуй. Ни за какими оптимизациями не гонюсь
>в том числе и баги в актуальных и не актуальных драйверах
Миф и заблуждение. Даже студенческие laba1 подделки запускаются без проблем у всех. Времена драйвероебства прошли лет десять назад
>каждый из которых поумнее тебя будет, архитектуру рендера, короче догонять рыночек на самопальном велосипеде.
ЗАЧЕМ? Вот этот момент всегда поражал в ваших аргументах. Серьезные дядьки пилят серьезные ААА-проекты с миллиардными бюджетами. Нахрена их догонять инди? Что я должен у этих серьезнхы дядек догонять чтобы сделать свой условный Barony из ссылки выше?
Вечно несете какой-то бред. Для маленьких инди проектов не нужны ААА-движки. И не нужны знания разработки ААА-движков.
>Этот рынок - полторы конторы, каждая из которых сложилась в 80х-начале нулевых, как уже выше было сказано
Ты сейчас описал весь русский геймдев. Он как слег в 2008 году, так до сих пор на том же месте и валяется.
А в западном геймдеве полно вакансий на рендер-программистов. В конце концов даже хотя бы шейдеры писать для еба движков
>А в западном геймдеве полно вакансий на рендер-программистов.
Как в такое вкатываться?
Да никак, пиздит он. В очередь 2000 чел на место.
Или карьерой из фрилансера-сыча-скриптуна.
>В очередь 2000 чел на место.
Ты так пишешь, как будто позиция ассетотаскателя мобильных три в ряд охуеть как свободна. Везде конкуренция.
>2000 чел
Да и где ты 2к взял? У нас в стране даже десятка не наберется (остальные на уровне того пбр шизика из движкотреда)
>Как в такое вкатываться?
Ну ясен пень научится делать рендер движки. Без этого никак.
Ну и еще не быть сычем, а научиться продавать себя - создать бложик в котором писать охуенные теоретические статьи, писать стримы, коммитить в UE4 и подобное.
Ты просто фантазируешь дохуя, ни дня в гейдеве не проработав.
Чтобы вкатиться в компании, люди целые рендеры и научные статьи пишут, с воксельным освещением, своей реализацией GI или cone trace, которая на три процента эффективнее существующих алгоритмов. И даже их не берут, хотя они в своих йоба-библиотеках на гите пишут объявы о том что свободны и готовы поработать, лишь бы взяли.
Да насрать. Вообще не знаю зачем начали эту тему обсуждать. Так-то я писал:
>>Плюс мне нравится рендер-программирование и я хочу набивать в нем опыт
Чисто для себя. Просто как хобби. Как и игры. Я работаю на дядю в совершенно другой области
> и я хочу набивать в нем опыт
Для начала тебе стоит перестать фантазировать о том, в чем не разбираешься. Избавит от ошибок.
Ты о чем? Давай по пунктам о моих "фантазиях" в которых я не разбираюсь.
То что до сих пор пишут свои движки? Все игры которые мне интересны и в моих вишлистах - все они на своих движках.
То что я увлекаюсь технологиями рендера? Но я увлекаюсь. Это не сегодня мне в голову стукнуло, и даже не вчера.
Или про работу рендер программиста? Ну опять же, люди, которых я уважаю, работают рендер программистами (даже на gamedev.ru такие есть). Остальные мне не интересны - какая мне там разница кто там без работы сидит?.
Да меня и самого как-то в Saber Interactive звали на работу над движком (конечно не рендером, а ядром движка на с++, но знаний на собесе не хватило). Да и рендеринг - он не только про игры и движки, есть много смежных областей.
Так в чем я там не прав?
> Все игры которые мне интересны
Нихуя себе, ты вместо каких-то объективных факторов "свой интерес" приплетаешь. Это уже шиза и манямирок.
> Так в чем я там не прав?
В том что ты свой манямирок на реальность проецируешь. Перестань это делать.
>"свой интерес" приплетаешь.
Почему это меня должны волновать чужие интересы для выбора СВОЕГО хобби? Я говорю о СЕБЕ, и СВОИХ причинах почему я захотел изучать вулкан.
>Это уже шиза и манямирок.
Знаешь, скорее у тебя. Это ты тут непонятно что выдумал, обвиняешь непонятно в чем. Ты сразу начал с каких-то необоснованных наездов
>В том что ты свой манямирок на реальность проецируешь.
Моя реальность меня устраивает. Тебе-то какое дело до нее?
> Перестань это делать.
С чего это я должен перестать? Кто ТЫ такой чтобы мне указывать что делать или не делать в моем личном хобби? Реально у тебя какая-то шиза, ты наезжаешь на меня пытаясь меня обвинить в моих увлечениях - тут либо шиза, либо зависть неудачника. Иначе я просто не понимаю.
Я нигде ни слова не написал "пишите все свои движки, готовые не используйте". Я также не писал что все пишут на своих движках. Я писал что некоторые (тысячи - это капля в море)
> Почему это меня должны волновать чужие интересы
Потому что мы тут про реальность говорим, а не про твой манямирок.
> СВОЕГО хобби? Я говорю о СЕБЕ, и СВОИХ
Тогда зачем-то пизданул про что все выбирают создание своих движков, про то вакансий на рендер полно? Это не так.
Говоришь про что-то своё - окей, ладно. Но лезть со своим манямирком в другие темы не стоит.
>687548
>Тогда зачем-то пизданул про что все выбирают создание своих движков
Где? Покажи мне это место.
Твоя шиза прогрессирует.
>в другие темы не стоит.
В какие другие шиз? Ты сам-то нахрена в эту тему залез? Тут тема про велосипеды. Про движки в другом месте
>Тогда зачем-то пизданул про что все выбирают создание своих движков
Где? Покажи мне это место.
Твоя шиза прогрессирует.
>в другие темы не стоит.
В какие другие шиз? Ты сам-то нахрена в эту тему залез? Тут тема про велосипеды. Про движки в другом месте
Пойду лучше код пилить...
Эх. 576 строк написал только для обертки над vkInstance
Эх. 576 строк написал только для обертки над vkInstance
Например, на реддите один человек похвастался велосипедным движком (примитивным). Ему в комментах пишут:
>This is awesome! I’ve recently begun working at a company that makes a AAA engine, on the rendering side of things, for my day job. I along with many of my coworkers started out by doing projects like this.
https://www.reddit.com/r/gamedev/comments/i2z6ir/my_progess_in_creating_a_3d_game_engine/
>This is awesome! I’ve recently begun working at a company that makes a AAA engine, on the rendering side of things, for my day job. I along with many of my coworkers started out by doing projects like this.
https://www.reddit.com/r/gamedev/comments/i2z6ir/my_progess_in_creating_a_3d_game_engine/
Ну вот, а чел выше пишет что рендер прогеры никому не нужны
>Direct3D9
Внезапно, ничего не мешает написать на d3d9 игру сегодня и успешно ее выпустить.
Для какого-нибудь майнкрафта или факторио хватит без проблем
I am not pursuing a goal to make yet another Unreal/Unity killer and I understand that the engine is very far from such large projects. My project is more like educational one, from which I can learn new things, work with different libraries, practice my programming skills and just have fun.
Правда посередине, как обычно. Нужны, но мало.
Ничто не мешает поискать на линкедине вакансии по слову "вулкан". Все крупные компании вроде гугла и амазона, игровые студии, юнити и эпик геймз набирают программистов рендера. Плюс еще куча контор поскромнее, которые занимаются всякими роботами, симуляторами и медицинской визуализацией. Плюс оборонка.
Но также верно и то, что таких вакансий хорошо если будет 1% от обычных вакансий программиста на С++.
игру можно написать хоть на d3d4-d3d8 - это не значит что оно еще актуально для изучения.
Вообще он упустил момент - это хобби.
Просто есть люди которым лишь бы грести бабло - они да, возмут готовый двиг, накупят ассетов, запрягут скриптера за дошик. Такие да, покрутят пальцем у виска при слове "пиши движок".
А есть люди, которым это просто по кайфу. Нет цели на этом заработать. Как вот этот студент. Ведь он тоже мог взять юнити и делать свои три в ряд или устроится в конторку. А он пилит движок для себя.
Также и я - это хобби.
Смотря какая цель. Если устроиться программистом в Юбисофт, то нужно изучать что-то современное, если выпустить свою игру то есть смысл заюзать что-то попроще. Я бы сказал для инди d3d11 это самое оно, может практически все что и вулкан, и намного проще в использовании.
>если будет 1% от обычных вакансий программиста на С++.
Но опять же, если говорить в эту сторону. Мало вакансий, но мало и толковых специалистов.
Например каждый студент может за месяц освоить юнити и пойди работать в контору - высокая конкуренция из-за низкой планки вхождения, низкие зарплаты.
А рендеринг уже не так прост - уже требуется время и интеллект выше хлебушка
Ну это теоретика, да.
Я тоже занимаюсь ради хобби.
Чтобы менять сферу деятельности (энтерпрайз->геймдев) я уже староват, да и в зарплате просаживаться неохота. А велосипедить движки по вечерам весело.
Насколько вообще реально сменить сферу? Как будут смотреть, если им нужен опыт работы на крестах, а у меня опыт на питоне в вебе?
> Где? Покажи мне это место.
Ты че ебанутый? Вот фантазировал про хуйню какую-то, про то над чем работают рендер-программесты, что их тысячи, что движки неудобны, что драйвера работают без проблем.
Ты блядь 90% всей этой хуйни придумал, понимаешь? Иди почитай про проблемы gles2. Прочитай про проблемы драйверов интел, которые могут буферы скидывать.
Сука откуда вы лезете со своим манямирком, шизики ебаные.
>Ты че ебанутый?
Походу ты. Где я писал
>>что все выбирают создание своих движков
???
>что их тысячи, что движки неудобны
Блядь, ты просто даун который не может понять что у всех разные вкусы.
>Иди почитай про проблемы gles2. Прочитай про проблемы драйверов интел, которые могут буферы скидывать.
Ты бы еще про DX8 вякнул. Мы вообще-то в треде вулкана
Вот тебе пример даже приводили - обычный студент, ему скорее всего 16 лет (только поступил в институт на первый курс. А уже пишет движок. Где у него проблемы с драйверами, интелами и т.д.? Их нет.
Я сам прогаю под intel видеокарту - нет никаких проблем. Кстати под нее даже гуру вулкана (Арсений Капулькин) вначале прогал прямо на стриме. Что-то у него тоже никаких проблем не было. И его код тоже работает у всех. Никакой вуду магии он не делал.
>Сука откуда вы лезете со своим манямирком, шизики ебаные.
Иди нахуй обратно в свой загон годота/юнити/что там еще, ты сюда зачем лезешь? Это тред движкогоспод. Тут никому не интересно читать твою шизу.
Мы тебе мешаем пользоваться движком? Не мешаем. Вам там даже модера в тред завезли чтобы все было лампово и с цветочками и без хейта.
Так нахуя ты сюда лезешь и начинаешь демотировать? Тебя вообще как ебет кто и что хочет писать?
Этот тред о вулкане, а не о твоем любимом движке - иди нахуй отсюда.
Пиздец как меня бесят такие хуесосы. Когда нам завезут модера чтобы он нахуй разогнал их в их загончики?
> Где у него проблемы с драйверами, интелами и т.д.? Их нет.
Вся суть шизика.
Берет и отвечает за других людей, лол, даже не спрашивает их, просто проецирует свои желания.
> Я сам прогаю под intel видеокарту - нет никаких проблем.
Зачем ты проецируешь свой манямирок на объективную реальность? То что ты нигде не тестировал своё говно нигде - не значит что проблем нет. у меня были на телефонах сосунга и амд
> Это тред движкогоспод.
Это тред вулкана, шизоид, какие движкогоспода? Вулкан это не движок, если что. Серьезно, не движок. Вулкан это апи, графическое.
>Это тред вулкана, шизоид, какие движкогоспода? Вулкан это не движок, если что. Серьезно, не движок. Вулкан это апи, графическое.
Если это тред вулкана - нахуя ты сюда лезешь со своими движками
>>Настоящее - это использование готовых движков.
Короче, иди нахуй
Это анонимная борда, а не твой вконтактик, шиз, не думай что тут кроме тебя и собеседника никого нет.
Что сделать чтобы оно перестало ругаться на этот vma
Это не ошибка (код комплируется) - просто ложные срабатывания парсера
Это не ошибка (код комплируется) - просто ложные срабатывания парсера
>ложные срабатывания парсера
Это не проблема вулкана, тебе с этим в треды VS или C++.
Это проблема с которой могут сталкиваться другие вулканисты. Вулкан, это инструмент для решения определенных задач, а не нечто в вакууме.
И это все таки проблема использования вулкана - это происходит из-за макроса VK_DEFINE_HANDLE - который вообще-то описан спекой вулкана (я тебе даже специально страничку спеки вулкана открыл) - то есть это не что-то сторонее а часть спецификациии вулкана
Ну и во-вторых, vk_mem_alloc довольно популярна, может кто-то уже решал проблему.
Возможно я где-то не прописал какой-то макрос когда я подключал vk_mem_alloc или что-то подобное. Потому что в чужих проектах вроде парсер не ломается (да он и не ломается на всяких vkInstance которые также с этим макросом)
твое IDE не видит хедеры или там парсер не того диалекта cpp (урезанный или недосвежий или хедеры явно линуксоиды писали а в IDE виндовый вариант итп) и не понимает какую нибудь локальную срань при парсинге где-то выше из-за чего конец файла отваливается
короче отруби эту подсветку и живи без нее
Через shaderc или glslang можно получить список in\out параметров, ubo, ssbo, пуш-константы и т.д? Или опять придется рядом с шейдерами класть мета информацию?
Сап, двач! поделись мнением:
какие навыки уровня must have должен иметь начинающий программист графики на VulkanAPI/Directx12?
например, в какие техники рендеринга нужно уметь.
разве уровня курса https://learnopengl.com/
достаточно?
что должно содержать портфолио, какого уровня должна быть работа?
Я не особо специалист но считаю что вулкан выигрывает именно по потому что даёт возможность велосипедить очень тонко под нужную тебе задачу. Это прекрасно на самом деле, но думаю что с кривыми руками из вулкана можно сделать еще хуже перфоманс чем на OpenGl
Алсо, кто нибудь знает более-менее живое русскоязычное сообщество (в телеге допустим или дискордке) вулканщиков?
https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-preface.html
Vulkan-tutorial реально убого сделан, вот этот гайд от интела гораздо лучше и собственно по нему я и смастерил это детище в 1200 строк: https://github.com/MomoDeve/vulkan-learning/ - оно рисует не треугольник, а целый квад с текстурой (!). Хз че вы там не осилили, имхо совершенно очевидно куда двигаться дальше, если уже был опыт с другими граф апи.
Кстати приятно что мое двигло тут вспомнили, пост на реддите хорошо хайпанул
Vulkan-tutorial реально убого сделан, вот этот гайд от интела гораздо лучше и собственно по нему я и смастерил это детище в 1200 строк: https://github.com/MomoDeve/vulkan-learning/ - оно рисует не треугольник, а целый квад с текстурой (!). Хз че вы там не осилили, имхо совершенно очевидно куда двигаться дальше, если уже был опыт с другими граф апи.
Кстати приятно что мое двигло тут вспомнили, пост на реддите хорошо хайпанул
>реально убого сделан
Да вообще какая-то хуйня с изучением вулкана - говно в Vulkan-tutorial. Говно у Саджи или как там его. Ощущение что специально наняли самых говнокодеров для документации и обучения
А те кто могут нормально - выводят треугольник и ничего больше... Блядь, да покажите как правильно вывести два разных треугольника со всеми этими командными буферами, пушами и т.д.
Ну и еще эта позиция - вулкан не для нубов, он для тех кто уже работал с гапи... Так это тоже хуйня - так как его мозг забит старыми методиками, он скорее всего не сможет сразу поменять мышление (синдром утенка и все дела)... Что также заметно, когда "опытные" пытаются использовать вулкан как какой-нибудь DX11 или там OGL или не дай бог DX9
При том что реально там ничего сложного нет. Мне в свое время помог китаец BobLChen (https://github.com/BobLChen/VulkanDemos)... хотя и тут ложка дегтя - китаец наворовал кучу кода из UE4 методом копипаста, использовать его решения (особенно его фреймворк) не стоит - чревато. Но изучать более-менее неплохо
с подливой
Вай Вай вай
олды помнят
В идеале свой рендер-движок напиши, c PBR, deferred/clustered rendering'ом. Трассировщик путей, хотя бы софтварный, тоже лишним не будет. Вот на все эти вопросы знать ответ: https://habr.com/ru/post/351698/
Уметь работать с компут шейдерами, шарить за архитектуру гпу. Знать тот же Vulkan или DX12
в дополнение к шапке
https://github.com/vinjn/awesome-vulkan
https://github.com/vinjn/awesome-vulkan
У меня есть графическая очередь в которую, как водится, уже накидано сабмитов на кадр вперед. Мне вот прям щас нужно сделать пару диспатчей как можно быстрее. Если у компьют очереди будет приоритет выше чем у графической, гпу бросит рендер и выполнит мои диспатчи при первой возможности? Я прав?
Двачую полностью, настроить инстанс, свапчейн и девайс еще куда не шло, но все остальное, мда. Вместо того что бы показать как надо в 99% делать, автор гнался за производительностью и создавал комбаффер всего раз запись баферов у него тоже идет с самого начала, а что делать когда нужно посередине цикла сделать.
Я уж разобрался потом что пересоздавание или резет и перезапись комбафера можна поместить перед сабмитом цикле перерисовки, но вот что делать с перезаливкой мешей пока не совсем ясно, предполагаю что нужны пайплайн мемори барьеры как в пример от интел
https://github.com/blighli/IntroductionToVulkan/blob/master/Project/Tutorials/07/Tutorial07.cpp
Хочу заюзать вот эту штуку https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_enhanced_layouts.txt чтобы не ебать мозги с выравниванием на устройстве, а мапить память сразу на хост структуру в C++ коде. Есть подводные? По перформансу не ебнет?
Инфа по теме:
Базис - https://habr.com/ru/post/283490/
Sascha Willems, куда же без него. Уроки по теме - https://github.com/SaschaWillems/Vulkan
Хеллоу-ворлд треугольник + некоторые основы - https://vulkan-tutorial.com/Introduction
Тот же самый код, но на Си - https://github.com/johnnyw/hello-triangle-vk/blob/master/hello-triangle.c
Ещё один треугольник - https://www.gamedev.net/tutorials/programming/graphics/vulkan-101-tutorial-r4408/
Ещё немного кода, может служить примером - https://github.com/cheako/cheako-vulkan
Несколько свежих лекций на русском - https://www.youtube.com/watch?v=zyoKSa4irMU[РАСКРЫТЬ]
Урок-недоделка также на русском - https://github.com/faserg1/VulkanTest
Был ещё сайтец "vulkanapi.ru" с большим количеством уроков, но к 19 году автор забил хуй, хостинг не оплачен, сайт лежит. В вебархивах присутствует частично схороненная версия.
Книжечку с пикчи искать на торрентах, есть на русском.
Наверняка что-то забыл, позже дополню.