Three.js: Будет ли рендерер на основе WebGPU?

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

Тем не менее, я бы рекомендовал принять участие / подписаться на разработку WebGPU здесь: https://github.com/gpuweb/gpuweb/wiki и https://www.w3.org/community/gpu/

Если WebGPU окажется столь же мощным, как мы все надеемся, его придется переписывать с нуля, чтобы использовать его в полной мере.

@TimvanScherpenzeel
Да, я согласен. Я буду далеким будущим.
Разве невозможно добавить рендерер WebGPU в three.js, не переписав ядро ​​с нуля? должны ли мы переписывать весь движок (API) на threejs с нуля? Я думаю, что даже если WebGPU выйдет, очень вероятно, что какое-то время они будут сосуществовать вместе (WebGL / WebGPU). Я не думаю, что WebGPU убьет всю экосистему WebGL.
Однако я предполагаю, что WebGPU был бы очень мощным, если бы он поддерживал изначально и напрямую, в отличие от того, что WebGL является косвенным API графического драйвера;И Google и другие крупные игроки хотят, чтобы это было лучше для производительности DeepLearning и высокой производительности графического интерфейса в браузере.

В ThreeJS уже есть много разных средств визуализации - WebGLRenderer, WebGL2Renderer, CSS3DRenderer, SVGRenderer ... WebGPU можно обрабатывать аналогичным образом, когда API готов. Со временем возможны более глубокие изменения в библиотеке.

На данный момент закрываю эту проблему, хотя я очень рад, что эти API следующего поколения также будут доступны. :)

@donmccurdy
В самом деле ... Three.js настолько гибок, что в будущем может реализовать даже WebGPU, верно?

Согласно предложению WebGPU, они упомянули разработчиков Three.js как одну из своих основных целевых аудиторий.

https://gpuweb.github.io/admin/cg-charter.html

Разработчики инфраструктуры JavaScript, которые создают библиотеки графического процессора, предназначенные для использования в веб-контенте, но предоставляющие высокоуровневый API и скрывающие большую часть низкоуровневой графики и деталей вычислений от своих пользователей. Например, three.js.

Мой вопрос в том, что они используют другой язык шейдеров под названием WHLSL.
https://github.com/gpuweb/WHLSL

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

«Мы перейдем этот мост, когда подойдем к нему».

Был анонсирован @ Google I / O с экспериментальной поддержкой в ​​Chrome Canary для OSX, доступной сейчас:
https://www.youtube.com/watch?v=K2JzIUIHIhc

Babylon.js объявил о своей полной поддержке, когда выйдет. Посмотрите здесь:
https://forum.babylonjs.com/t/webgpu-is-coming-to-babylon-js/3122

Я надеюсь, что команда ThreeJS последует примеру.

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

Уверяю вас, мы не забудем об этом ... 😁

Но я не сопровождающий. Лично я буду следить за первым фреймворком, который принимает webgpu. И дело не во мне. Это сообщение, которое вы, ребята, даете в заключение. Это похоже на «Крутая штука, конечно, но мне все равно. Она может держаться в подвешенном состоянии».

PS. Я прочитал неправильно, я подумал, что это «уверяю, вы не забудете об этом»

@MichelDiz этот вопрос был открыт, чтобы спросить, планируем ли мы поддерживать WebGPU. На вопрос дан ответ: мы действительно планируем поддерживать WebGPU. Наверное, сейчас рано над этим работать, но новые вопросы откроются, когда мы будем готовы это обсуждать.

@TimvanScherpenzeel необходимо будет переписать определенные части, которые абстрагированы от пользователей, но предполагать, что все это придется «переписать с нуля», - это сильное преувеличение. Геометрия буфера будет иметь одинаковый формат. Как и WebGL, WebGPU также основан на шейдерах GLSL -> WHLSL. Похоже, что формат glTF, который стал стандартом WebGL, также будет стандартом WebGPU. Все наиболее часто используемые API-интерфейсы Three.js останутся неизменными на 99%, в то время как новый модуль рендеринга WebGPU будет находиться под капотом и, надеюсь, значительно повысит производительность и раскроет потенциал рендеринга больших сцен с высокой частотой кадров.

Привет всем,
Большое спасибо за обновления по этому поводу!
Я просто хотел поделиться своим видением таких функций. В нашем случае мы не всегда используем WebGL для потребительских приложений. У нас действительно есть опыт WebGL, который позволяет визуализировать очень большие наборы данных, ресурсы которых составляют ~ 1 ГБ и обслуживаются локально на фиксированном оборудовании, где мы можем управлять браузерами и их флагами, чтобы включить WebGPU. Так что даже в экспериментальном режиме мы определенно хотели бы получить поддержку для этого. Я понимаю, что нас меньшинство, но я просто хотел добавить эту точку зрения в разговор.

@sinokgr Как WebGPU помогает отображать ресурсы размером 1 ГБ? Насколько я понимаю, структуры данных для геометрических данных такие же, как и в WebGL.

спасибо за ответ @mrdoob . Честно говоря, я не буду утверждать, что достаточно понимаю различия, и информация, которую я нахожу в Интернете, очень расплывчата (по крайней мере, согласно моим исследованиям). Главное чувство, которое я получаю, - это то, что я прочитал, например, последнее сообщение от @DVLP, которое вам понравилось,

значительно повысит производительность и раскроет потенциал рендеринга больших сцен с высокой частотой кадров.

это заставляет меня думать, что мы увидим хоть какие-то улучшения. Это может быть, например, как быстро эти активы загрузятся, может быть, лучше fps? Я не уверен.

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

1. Загрузить файл модели в браузер - та же скорость
2. Анализировать модель и загружать геометрию в буфер массива - одинаковая скорость
3. Загружайте программы на GPU - быстрее
4. Загрузка текстур - изначально такая же скорость, но быстрее при передаче на GPU
5. Передача геометрии на GPU - быстрее
6. Сделайте серию вызовов отрисовки для рендеринга кадра - быстрее

Большое спасибо за объяснение @DVLP . Пункты 5 и 6 кажутся мне очень интересными, поскольку у нас есть тысячи объектов с большим количеством материалов.

До широкого распространения WebGPU может пройти много времени. А пока вы можете ускорить все это с помощью создания экземпляров сетки.
https://threejs.org/docs/#api/en/objects/InstancedMesh

Боюсь, что мы не можем использовать инстансинг, все объекты уникальны @DVLP

https://github.com/mrdoob/three.js/pull/20254