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

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

Угу, это правда. Правда, я нашел и аргументацию о том, почему эту фичу не включили в Vulkan:
https://www.khronos.org/opengl/wiki/Shader_Compilation

That being said, while this power is available, it is best not to use it. It usually works, but because most OpenGL applications don't do this, it doesn't get as thoroughly tested as other parts of the OpenGL API. So you're likely to run into more driver bugs this way. Generally stick to having one shader object per shader stage.

Они выкинули из Vulkan эти интерфейсы, потому что подавляющее большинство разрабов не используют эту линковку.

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

Да. Но ты забываешь, что трансляция SPIRV в машинный код намного, намного проще, чем трансляция человекочитаемого текста в машинный код. По этой причине приложение с предварительно откомпилированным SPIRV грузит шейдеры в разы быстрее, чем GLSL - именно это является основным сценарием для Vulkan. И даже в рантайме там нет какой бы то ни было чудовищной потери производительности, если не считать отсутствующей возможности линковки.

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

Ладно, давай начнем с того, что в видеокартах предпочитают исполнять код без вызова функций. В них нет классического стэка вызовов, вместо этого локальные переменные выделяются статически, как в Фортране и Коболе. В HLSL формально есть вызовы функций, но фактически они все инлайнятся:
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-...
В SPIR-V можно задать для OpFunction опцию 0x2 «DontInline», но описание подчеркивает: «Strong request, to the extent possible, to not inline the function».

То есть, «раздельная компиляция» заканчивается где-то незадолго до генерации машинного кода, будь то в Вулкане или OpenGL, с инлайном функций, разворачиванием циклов и линеаризацией условного выполнения. Соответственно, какой тогда вообще смысл в «раздельной компиляции»? Чтобы не парсить лишний раз исходники? Да, для этого есть https://github.com/KhronosGroup/SPIRV-Tools#linker . Но машинные коды все равно придется перекомпилировать, с линкером и без него, в Vulkan и в OpenGL.

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

Как ты думаешь, кто делает девайсы Razer, Tesoro, Zowie? Формально первые две - США, третья - Тайвань, но фактически - это один и тот же Китай, и, вполне возможно, их делают на одном и том же заводе.

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

А проверяется легко - покажите мне отечественный игровой движок хоть 1 серьёзного уровня. Пускай даже уровня опенсорсного огра

Нет проблемы написать движок - есть проблема продать его. Высококвалифицированные крестовики в России стоят не сильно дешевле, чем в США. Кто и как будет впаривать продукт заказчикам, имеющим доступ к большому объему инвестиций и кредитов? В конце-концов, для хорошего кредитного рейтинга желательно сотрудничать только с фирмами из штатов и союзных государств. Потому, даже если 90% штата сидит в России, то все равно 10% должно сидеть за океаном и быть лицом, брендом, как это произошло с разрабами платежных систем.

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

SPIR-V является бинарным форматом. Например:
https://github.com/gfx-rs/wgpu-rs/blob/master/examples/hello-compute/shader.c...
Конечно, этот шейдер можно представлять в текстовом виде, но это уже будет не SPIR-V.

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

Плюсану. Для видюх SPIR-V - это примерно как байткод JVM или CLR. Конечно, на этапе генерации SPIR-V тоже возможны некоторые оптимизации.

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

Я писал о полноценном десктопном геймдеве, а не извращениях всяких

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

Я писал о полноценном десктопном геймдеве, а не извращениях всяких

Давайте я вас рассужу. Я в свою бытность студента на парах играл на N810 в дум, квейк, дюк нюкем. Игрофоны уже давным-давно доросли до того уровня, когда на них можно запускать что-то вроде CS 1.6 или Warcraft III. Факт прогрессирующей убогости софта для игрофонов находится в симфонии с общим упадком софтостроения, вызванного остановкой прогресса в аппаратном обеспечении. Нынче десктопный геймдев возвращается к спрайтовой графике, хотя еще лет 10-15 назад все повально стремились делать 3D графику, даже если она в итоге выглядит ужасно. Don't Starve, They Are Billions, Age of Empires 2, и еще тысячи других мелких и крупных недавних проектов жанров RPG и RTS сделаны именно на спарйтах. Более того, бурно процветает жанр инди игр, которые зачастую ни разу не инди и имеют геймплей посложнее какого-нибудь Mass Effect, а от инди там только примитивность графена.

Беглый просмотр rutracker показывает, что жанр шутанов уходит небытие, держась только на давно известных Фар Край/КаловДутие/Wolfenstein/Metro/Bioshock, а популярность набирают ролевки и симуляторы. Я недавно испытал шок, когда поставил какой-то топовый симулятор, и что бы вы думали там нужно делать? Ремонтировать дом! Убирать говно с пола, вешать телевизоры, чинить сантехнику. Это «полноценный десктопный геймдев»? Это полнейшее дно, я считаю. Неужели жизнь людей настолько уныла и скучна, что они развлекаются уходом за домом? Я играю в игры потому, что мне нужно что-то больше - мне не нужен симулятор, чтобы поставить смеситель, вынести мусор, или поменять анод в котле.

По этой причине я со всей ответственностью заявляю, что нынче почти не осталось никакого «полноценного десктопного геймдева», а десктопные игры ударными темпами догоняют игрофоны.

А чем принципиально в плане графики различаются шутеры и RPG (точнее, шутеры с элементами RPG)? Правильно, ничем.

Индюшатина позволяет с наименьшими затратами на художников и программистов движка выпустить игру, которая не просто окупится, но и денег принесёт. Тут проблема не в аппаратных ограничениях, КМК. Просто люди разработчики поняли, что графоний не важен, ведь что с ним, что без него суть игры не меняется и графики хватит такой, чтобы глаза не резало. А уж если её ещё и стильной сделать, то совсем хорошо.

А чем принципиально в плане графики различаются шутеры и RPG (точнее, шутеры с элементами RPG)? Правильно, ничем

Не знаю, при чем тут это к моему сообщению.

Индюшатина позволяет с наименьшими затратами на художников и программистов движка выпустить игру, которая не просто окупится, но и денег принесёт

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

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

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

Большинство игр похожи друг на друга. По сути, именно техникой исполнения они и отличаются, то есть, качеством программирования логики, искуственного интелекта, и исполнения графики. Чем лучше сделал - тем больше за продукт можно просить. По этой причине у фильмов/мультфильмов часто большие бюджеты - никому не придет в голову делать примитивную графику «суть не меняется», ведь для этого есть книжки. Но можно сделать отвратительный фильм с большим бюджетом и можно сделать провальную игру с большим бюджетом - ровно как и наоборот, можно с минимальными затратами снять хороший фильм (видеобложик, в конце-концов) или сделать хорошую игру. Инди проектов, может быть, и больше, но годноты среди них мало.

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

Чтобы не парсить лишний раз исходники? Да, для этого есть https://github.com/KhronosGroup/SPIRV-Tools#linker

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

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

Это ещё более менее. Обновление шейдеров будет значительно оптимальнее чем сейчас есть, станет +- как в MisakaRenderer, я полагаю.

куда присунуть вот эту вот текстуру

В буффер, конечно же! Через handle, который uvec2. Зачем вообще куда-либо биндить текстуры кому-нибудь может понадобиться? Это в OpenGL.

И на Vulkan тоже с этим всё неплохо. Толкаем её в один дескриптор сет с буфером, а биндинги, вроде как, обязаны быть уникальными лишь в пределах сета.

Bindless – не серебрянная пуля. В вулкане ± это делается через DescriptorSetIndexing. Но оно хорошо применимо, когда у тебя ограниченный набор текстур для большого количества дроуколлов. В дженерик сценации ты получишь больший выйгрыш за счёт UPDATE_AFTER_BIND с оптимальным количеством copy+write. А резолвинг copy+write становится нихренасебе задачей при использовании кучи слотов в одном биндинге. (Тут правда есть ещё куча нюансов типа «невидия не поддерживает UPDATE_AFTER_BIND для UBO», но это уже не про биндлесс)

Не работает. Этот «недоспирв» хрен получишь.

так ещё и записанные однажды, они могут использоваться многократно!

Миллениалы изобрели draw lists? Нет, молодцы конечно. Идея хорошая.

В OpenGL замечательная система шейдерных модулей… Совершенно не ясно, зачем было её херить :(

Чтобы криворуким писателям драйверов не надо было писать ещё и компилятор. Так получили блоб с IR, оттранслировали полторы функции в местный код и давай выполнять. Такой себе RISC от графических API.

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

Это разработчикам продуктов предлагается кушать что дают, а не полагаться на драйверные ништяки. А вот на разработчиков движков кладётся священная обязанность эти «семейства материалов» описать, закодить и отдебажить.

со spir-v они стандартизировали фронтенд компилятора и разгрузили проц

глубину и вовсе загнали в интервал от 0 до 1, вместо -1 до 1

это эффективнее использует точность float-ов

у него хоть feature parity с современным glsl 4.6 есть?

spirv-link

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

ARB assembly only provides shader model 2.0-level functionality. It has no support for many common features

понятно. уноси нафиг

Он (пока) не работает.

хм, у меня на примитивщине вроде слинковать vert.spv + frag.spv в один my.spv и потом его использовать работает

Миллениалы изобрели draw lists? Нет, молодцы конечно. Идея хорошая.

Идея то конечно хорошая, но вот только её реализация в OpenGL.. Попадают ли команды glUseProgram, glBindVertexArray, glBindBufferBase в список или выполняются на месте? Документация на современный OpenGL молчит по этому поводу, но в документации на древность есть кое-что интересное.

https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glNewList.xml

gl2.1

Certain commands are not compiled into the display list but are executed immediately, regardless of the display-list mode. These commands are glAreTexturesResident, glColorPointer, glDeleteLists, glDeleteTextures, glDisableClientState, glEdgeFlagPointer, glEnableClientState, glFeedbackBuffer, glFinish, glFlush, glGenLists, glGenTextures, glIndexPointer, glInterleavedArrays, glIsEnabled, glIsList, glIsTexture, glNormalPointer, glPopClientAttrib, glPixelStore, glPushClientAttrib, glReadPixels, glRenderMode, glSelectBuffer, glTexCoordPointer, glVertexPointer, and all of the glGet commands.

Similarly, glTexImage1D, glTexImage2D, and glTexImage3D are executed immediately and not compiled into the display list when their first argument is GL_PROXY_TEXTURE_1D, GL_PROXY_TEXTURE_1D, or GL_PROXY_TEXTURE_3D, respectively.

Ведут ли дисплейные списки себя сколь нибудь адекватно на современном OpenGL (4.5 Core Profile)?

А вот на разработчиков движков кладётся священная обязанность эти «семейства материалов» описать, закодить и отдебажить.

Ну т.е. ненавязчиво так продвигают концепцию шейдеров как части движка, а не программы (игры). А разработчикам програм / игорей дать в руки struct Material {/*...*/} / ползунки. Дно, если одним словом.

они стандартизировали фронтенд компилятора

В Khronos ЕМНИП входят и AMD, и NVIDIA, и Intel. Т.е. просто договориться соблюдать стандарт они не смогли, а придти к концепции «один язык – один компилятор» и блюсти её смогли. Окаай; корпорации странные, если так.

разгрузили проц

Чойта? Путь от GLSL кода до машинного кода короче не стал. Highly likely он стал только длиннее («GLSL -> машинный код» vs «GLSL -> SPIRV -> машинный код»)

А надо vert0.spv + vert1.spv + ... + vertN.spv в один vert.spv.

К тому же в каждом из verti.spv должны быть неразрешённые ссылки. Чем производить verti.spv, даже если в новой версии spirv-linker внезапно заработал как надо, вопрос дискуссионный.

Чойта

вынесли преобразование текст -> промежуточное представление в оффлайн

Highly likely он стал только длиннее

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

Ну т.е. ненавязчиво так продвигают концепцию шейдеров как части движка, а не программы (игры).

Вово, аля 64kbPBR крутилок хватит всем.

наверное так этот pbr в каком-нибудь CAD используют, что прям уж ух

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

Мододелы тебя прокляли =) То прямо в релизе можно было шейдер поправить, улучшить, да вообще весь визуал переделать на ходу причём. А то внесли промежуточный этап с тулчейном.

Я помню была игрушка где FXAA шейдерный был кривой, у меня лагало , в настройках выключить нельзя, но разработчик оставил glsl как отдельные файлы и не стал вшивать в код. Я просто gl_FragColor = texture2D(tex,ftexcoord); вставил и остальное стёр и вуаля, прямо во время игры только уровень перезагрузил. Попробуй тоже самое с вулканом.

сейчас тоже можно, тк компилятор можно спокойно дёргать из программы

Попробуй тоже самое с вулканом

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

Ну там то да. Оправданно наверное. Но мы тут про игры. Суть вообще в том что раньше (и сейчас конечно же) было интуитивно и красиво. Вот шейдер как интерфейс и всё. Всё остальное скрыто. И ради этого же и делали. Что бы интерфейс (язык GLSL/hlsl) «один», а максимально удобная и производительная реализация его работы уже пусть будет на плечах железнячников ибо только они знают как для них удобно. Сейчас тоже самое, но в процесс вставлен байт код который также как и исходный код надо разбирать, парсить и компилировать. Да технически проще. Но прям настолько что корпорации от построения AST GLSL с ума сходят? Да раньше была проблема нужно уметь несколько версий glsl нужно уметь ещё hlsl и всё это. Дааааа мы примали байт коооод! Юхуууу теперь нам не важны языки! Мы будем напрямую удобный нам байткод транслировать в наши исполняемые единицы для шейдерных блоков! Ага ушли от одной проблемы и пришли к другой. Теперь вместо языка у них байткод который каждый будет генерировать как угодно и если разбирая язык в AST у тебя целый контекст исходя из которого можно сделать много выводов что происходит в случае же байткода у тебя поток которых хрен так просто разберёшь. А если не разберёшь то как есть напрямую оттранслируешь со всеми вытекающими. Мутно всё это.

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

и ничего не упадёт?

Пока я смотрю гей порно у меня никогда не упадет!

Владимир

каждый будет генерировать

для этого есть стандартный компилятор

у тебя целый контекст

у тебя есть пруф, что в сгенерированном spir-v отсутствует что-то нужное, или это догадки? багтрекер ждёт тебя: https://github.com/KhronosGroup/

Мутно всё это

тебе натурально открыли код части драйверов, лол

Делириум перелогинься :D

у тебя есть пруф, что в сгенерированном spir-v отсутствует что-то нужное

Ну как сказать

https://www.khronos.org/registry/spir-v/specs/1.1/SPIRV.html (в начале examples)

можно спокойно дёргать

Не торопи. Щас кассету с гей порно вставлю и буду дергать.

Владимир

здорово, ты нашёл пример листинга spir-v. тебе осталось принести:

пруф, что в сгенерированном spir-v отсутствует что-то нужное

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

Байткод имеет форму, очень близкую к тому самому AST. Разница как раз в том, что самый геморный функционал - парсинг человекочитаемого языка, вынесен из драйверов. При этом представление можно свободно транспилировать как из GLSL/HLSL в SPIR-V, так и в обратную сторону. Цель создания вулкана как раз и заключалась в том, чтобы убрать лишние уровни абстракции, упрощая таким образом написание драйверов и работу с ними, пусть и ценой усложнения реализации конечных приложений..

попробовал - работает и так