Пишете полную игру на WGSL?
Цель состоит в том, чтобы получить оптимальную производительность, когда все основные вычисления выполняются на графическом процессоре, сделать возможным масштабное моделирование в браузере, добиться чего-то вроде пудровая игрушка или более продвинутая.
И поскольку WebGPU поставляется на Chrome, это уже может быть возможно. Но до сих пор я никогда не занимался программированием шейдеров, поэтому меня немного пугала связанная с этим сложность, но просмотр некоторых руководств создает впечатление, что это достаточно просто, и вызывает у меня большой энтузиазм по поводу возможностей наличия логики и графики. из стороны в сторону на графическом процессоре, без необходимости возвращаться к центральному процессору.
Так что, возможно, я что-то упускаю из виду.
Что я смог найти, так это то, что шейдерные программы обычно очень маленькие. Так что, может быть, это даже не сделало бы все намного быстрее, даже если бы я по каким-то техническим причинам реализовал всю логику моделирования и пользовательского интерфейса внутри WGSL? (при условии, что я не совершу серьезных ошибок, которые, как я знаю, легко сделать)
Так почему же я не нахожу никого, кто уже что-то сделал?
Ограничен ли размер кода, или слишком много элементов потока управления блокируют производительность, или просто отсутствуют инструменты, чтобы сделать это правильно?
Наверняка есть чему поучиться, например:
Затем я обнаружил, что размер рабочей группы (количество операций для вычислить в одном пакете) устанавливается в коде таким же большим, как матрица сторона. Он работает нормально до тех пор, пока сторона матрицы не станет меньше числа ALU на GPU (арифметико-логическое устройство), что отражено в WebGPU API как свойство maxWorkingGroupSize. https://pixelscommander.com/javascript/webgpu-computations-performance-in-comparison-to-webgl/
Но даже если он не оптимизирован, он все равно должен превосходить js и wasm? Если нет, то почему?
Ответы 1
Короткий ответ, по-видимому, нет, это невозможно, потому что шейдеры вообще не могут работать в бесконечном цикле и будут считаться зависшими и уничтоженными ОС через несколько секунд, если они попытаются это сделать.
Таким образом, идея и цель их состоит в том, чтобы запускать их небольшими порциями за раз. Но если все сделано правильно, большая часть, если не вся тяжелая работа по моделированию действительно может выполняться на графическом процессоре (в виде кода WGSL) без необходимости пересылки большого количества данных туда и обратно между графическим процессором и процессором. Только нужные биты.
И были намеки, что WGSL оптимизирован для массового распараллеливания, но не для сложного ветвления конструкций if else, поэтому вся игровая логика в коде WGSL может привести к ухудшению производительности. Таким образом, небольшие модули WGSL, в которых данные моделирования, с которыми они работают, остаются в буфере на графическом процессоре, по-видимому, подходят для меня.