K
Ещё я слышал что есть какой-то SPIR, но без подробностей
Size: a a a
2020 October 20
VK
Есть ли какой-нибудь язык для шейдеров, который бы не зависел или имел минимальную зависимость от драйвера? Например, если писать на GLSL, на одном ПК шейдер выплёвывает пару варнингов и дальше работает нормально, а на другом - отваливается и ничего не рисует
GLSL очень осторожно)
AP
вообще мне кажется чуть ли не у каждого движка сейчас есть шейдерный препроцессор, который как-то меняет код в зависимости от плафтормы и настроек
VK
И DXIL (и DXBC, который сейчас уже переводится в DXIL), и SPIR-V сильно зависят от косяков драйвера, всё равно, которые регулярно добавляют в обновлениях
K
И как в таком случае быть уверенным, что шейдерный код скомпилируется на всех видеокартах одинаково?
VK
И как в таком случае быть уверенным, что шейдерный код скомпилируется на всех видеокартах одинаково?
Никак, твои полномочия тут уже всё
K
То есть, у меня дома есть два ноута. Если код нормально отработает на них - то это уже лучше, чем на одном. Но всё ещё не гарантирует, что он будет одинаково работать вообще везде
K
Как, например, какой-нибудь юнити решает эту проблему?
K
У них там что, для каждой видеокарты свои настройки транслятора?
VK
То есть, у меня дома есть два ноута. Если код нормально отработает на них - то это уже лучше, чем на одном. Но всё ещё не гарантирует, что он будет одинаково работать вообще везде
Есть стандарты и спецификации, и валидный байткод, который тебе выдаёт какой-нибудь glslang, DXC или FXC, должен по идее работать везде так, как он написан. Но есть и тупо баги, из-за которых может начаться лютый ад, либо вообще игра будет вылетать при создании pipeline state object
VK
У них там что, для каждой видеокарты свои настройки транслятора?
Это не нужно, просто тестируется на разном железе, и пишется такой вариант, который везде работает
K
Есть стандарты и спецификации, и валидный байткод, который тебе выдаёт какой-нибудь glslang, DXC или FXC, должен по идее работать везде так, как он написан. Но есть и тупо баги, из-за которых может начаться лютый ад, либо вообще игра будет вылетать при создании pipeline state object
Насколько я понимаю - дело не всегда доходит до байткода, потому что именно компилер ругается на неиспользуемые переменные
VK
Насколько я понимаю - дело не всегда доходит до байткода, потому что именно компилер ругается на неиспользуемые переменные
HLSL или GLSL в DXBC, DXIL или в SPIR-V компилируются офлайн, на неиспользуемые переменные будет ругаться только конкретный компилятор, которым ты компилируешь в байткод
K
HLSL или GLSL в DXBC, DXIL или в SPIR-V компилируются офлайн, на неиспользуемые переменные будет ругаться только конкретный компилятор, которым ты компилируешь в байткод
Я компилирую просто вызовом glCompileShader
VK
Я компилирую просто вызовом glCompileShader
В случае с GLSL в OpenGL, конечно, поскольку драйверу приходится компилировать из текстового языка, у него есть гораздо больше шансов где-нибудь накосячить, чем с байткодом. В частности, он может проигнорировать ту ситуацию (либо для скорости, либо просто потому что её не учли), в которой другой компилятор честно выдаст предупреждение/ошибку. Тут нужно писать код шейдера прежде всего нормально по правилам
K
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glShaderBinary.xhtml
О, что-то интересное. Но, к сожалению, только с GL 4.1
О, что-то интересное. Но, к сожалению, только с GL 4.1
K
https://www.khronos.org/registry/OpenGL-Refpages/es3.0/html/glShaderBinary.xhtml
А ES умеет аж с 2.0, интересно почему так
А ES умеет аж с 2.0, интересно почему так
VK
Насколько я понимаю - дело не всегда доходит до байткода, потому что именно компилер ругается на неиспользуемые переменные
У Nvidia, например, компилятор GLSL, вроде как, допускает кое-какой синтаксис, который невалиден в стандартном GLSL, но допустим в Cg, потому что у них компилятор прежде всего написан для Cg, но с поддержкой GLSL
VK
Поэтому надо писать как минимум по стандарту (и если нужно, валидировать GLSL какими-то внешними прогами, например, glslang, которым можно и компилировать в SPIR-V, и просто валидировать)
VK
А потом уже делать костыли для багов, которые всплывают в драйверах