Comments 6
Спасибо, что поделились!
Я честно говоря совершенно не знал про шейдеры) но тем интереснее узнавать сферы применения
Kotlin
Здесь немного, что такое шейдер (GLSL): https://ru.m.wikipedia.org/wiki/OpenGL_Shading_Language
А здесь пример: https://mrdoob.com/#/139/glsl_sandbox
Полтора года назад чуваки из Unity во время ежегодной hack week приделали к движку поддержку шейдеров на C#: https://www.youtube.com/watch?v=hJZwaaXMfUA
Больше тему нигде никак не светили, и вроде бы она заглохла. Но с другой стороны, они сейчас пилят новую математическую библиотеку на C#, заточенную на совместимость с привычным синтаксисом HLSL (swizzling присутствует). На замечания, эй, народ, у вас naming guidelines совершенно не шарповские ― отмахиваются; говорят, делаем так, как все привыкли писать в шейдерах. Подозреваю, что-то намечается. Конвертер IL2CPP они уже сделали, могут и IL2HLSL сделать.
правда говорили больше не про шейдеры — графические, а про вычислительные.
Типа написал код на c# а юнити его скормил в GPU без всяких CUDA и прочего, по сути они так уже делают с Metal, транслируя код из HLSL Compute в Metal код
Воу, очень прикольно получилось. Похожие мысли приходили в голову, но я хотел на выходе иметь не строку с glsl кодом, а синтаксическое дерево, которое потом можно конвертировать либо в glsl, либо как-то отлаживать и тестировать на CPU.
В нашем проекте компиляция шейдеров может происходить в игровом цикле по требованию, и подобные выделения объектов порождают major вызовы GC, появляются лаги.
Подождите, но ведь шейдер можно при загрузке скомпилировать только один раз, и нагрузка от этого одного раза не должна быть большой. Вдобавок, телефон при загрузке шейдера всё равно будет сам его как-то парсить и компилировать для gpu.
Поэтому мы решили перенести сборку исходников шейдеров на этап компиляции с использованием обработчика аннотаций.
Если список шейдеров известен заранее, то их же можно грузить не в иговом цикле, а только один раз — при загрузке приложения.
Но у меня шейдеров не очень много, поэтому оказалось проще писать их в glsl файликах. Единсвенное синтаксическое улучшение — я реализовал синтаксис типа shader.uniformName=uniformValue для установки юниформ, но он без проверок на корректность.
Если список шейдеров известен заранее, то их же можно грузить не в иговом цикле, а только один раз — при загрузке приложения.
Хорошее замечание :) Общие для всех 3d сцен шейдеры мы и правда компилируем как только получен GL контекст. Однако список сгенерированных шейдеров значительно больше, чем список используемых для конкретной 3d сцены.
Для рендера статики в 3d сценах мы используем static batching (описание в unity).
Заранее мы генерируем исходники шейдеров для всех 1..32 размеров массивов sampler2D. Какой именно параметр количества выбрать для «батчинга» зависит от количества текстур сцены T и от максимального числа uniform'ов доступных для устройства U. Тогда в рендере отдельной части сцены в худшем случае будут участвовать 2 шейдера одного типа. Один будет иметь массив из U сэмплеров, а второй из T % U. Поскольку сцены подгружаются в runtime, мы не можем подобрать оба параметра заранее, делаем это налету.
Разработка GLSL шейдеров на Kotlin