Встреча Khronos WebGL/WebGPU — это повторяющееся онлайн-мероприятие, на котором люди, работающие над этими API веб-графики, делятся обновлениями, за которыми следуют выступления сообщества.

Здесь я подытожил свои личные моменты и выводы из встречи на этой неделе.

Ссылка на запись:https://www.youtube.com/watch?v=Jl06sOvMnvU

Подробности о моих прошедших мероприятиях см. в разделах Апрель 2022 г., Январь 2022 г., Июль 2021 г..

Обновления WebGL

Кен Рассел, Khronos Group
Слайды

Некоторые из вещей, которыми Кен был очень рад поделиться:

Кен также поделился, что они очень близки к выпуску серверной части WebGL ANGLE/Metal. Это интересно, потому что это позволит приложениям WebGL по-прежнему полностью поддерживаться последним Metal API в MacOS и iOS.

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

В Вики OpenGL есть хорошее объяснение того, что такое провоцирующая вершина, см. также обсуждение этого в WebGL.

Обновления WebGPU

Келси Гилберт, Mozilla
Презентации (как указано выше)

  • v1.0 почти готов! В настоящее время нацелены на 1 квартал 2023 года. Ожидается выпуск примерно версии Chromium 113 (см. график выпуска) для Windows, ChromeOS и MacOS (а позже для Linux и Android)
  • Значительный прогресс в использовании WebGPU вне браузера: (1) Deno имеет встроенную поддержку WebGPU (2) Dawn, кросс-платформенная реализация WebGPU, на 99% соответствует номиналу. с Chromium» и имеет привязки к узлам

Келси призвал сообщество поддержать разработку WebGPU. Лучшие способы внести свой вклад прямо сейчас: (1) предоставить отзыв об API и общем использовании через GitHub или Матричный чат, она подчеркнула, что сейчас самое время, когда обратная связь будет наиболее эффективной и полезной (2) помощь написание испытания на соответствие.

ТриJS и WebGPU

Рикардо Кабельо, Google

Mrdoob рассказал о том, как ThreeJS работает над поддержкой WebGPU. Самое большое препятствие для того, чтобы сделать его полноценной заменой WebGL, заключается в том, что шейдеры WebGL должны быть написаны на GLSL, а шейдеры WebGPU — на WGSL.

Причина, по которой это проблема для ThreeJS, заключается в том, что многие разработчики используют material.onBeforeCompile для редактирования сгенерированного кода GLSL шейдера перед его компиляцией для создания пользовательских материалов. WebGPU был бы критическим изменением для этого, потому что вам нужно было бы переписать свои модификации в WGSL.

NodeMaterial спешит на помощь!» говорит Mrdoob. Вместо того, чтобы писать свои материалы на GLSL или WGSL или любом другом языке шейдеров, вы пишете их в этой системе узлов более высокого уровня, и движку будет легко сгенерировать правильный шейдер для средства визуализации/платформы.

Ниже приведен пример фрагмента кода (исходник) для этой демонстрации радужного материала.

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

https://threejs.org/examples/?q=nodes#webgl_nodes_playground

Mrdoob упомянул, что рассматривает MaterialX (https://materialx.org/) как открытый стандарт для представления таких материалов. Они пытались в целом согласовать то, как они проектируют материалы в ThreeJS, с этим стандартом, чтобы не изобретать все заново с нуля.

MaterialX уже имеет большую поддержку в различных движках и инструментах разработки, а ThreeJS теперь имеет для этого загрузчик. Это интересно, потому что это означает, что вы можете экспортировать свои модели из Blender, Maya и т. д. и заставить их точно так же выглядеть в Интернете с помощью ThreeJS.

Последним ресурсом, которым поделился Mrdoob, была NodeToy, интерактивная игровая площадка, где вы можете создавать, редактировать и обмениваться материалами с помощью редактора узлов. Он даже генерирует код ThreeJS или код GLSL для любого из материалов на сайте.

Mrdoob упомянул, что по-прежнему будет возможность писать свои собственные шейдеры, если вы хотите, но для большинства случаев использования NodeMaterial будет подходящим вариантом.

Техническое путешествие по Google Планета Земля

Джон Андерсон, Google

Джон рассказал об эволюции технической архитектуры Google Планета Земля на протяжении многих лет, начиная с этого удивительного краткого обзора, когда они впервые попытались запустить ее с помощью Emscripten и AsmJS:

Первоначально Google Планета Земля работала только в Chrome, запуская нативный код с PNaCL. По этой причине у них всегда была кнопка запустить earth.google.com вместо того, чтобы запускать прямо в приложение.

Переход на полностью версию WebAssembly произошел в 2020 году и позволил ей работать во всех браузерах. В 2021 году кнопку «запуск» убрали. Google Планета Земля теперь работает на общем средстве визуализации C++ в Интернете, Android и iOS.

Джон объяснил две действительно интересные оптимизации:

  1. Google Планета Земля использует JavaScript ‹canvas› для правильного рендеринга текста

Вместо того, чтобы пытаться включить в приложение WASM целый механизм шрифтов/текста, который был бы слишком большим и сложным в обслуживании, они полагаются на веб-браузер, который уже может это делать. Таким образом, для рендеринга текста приложение рисует текст на холсте JS, считывает его, а затем визуализирует внутри 3D-сцены Google Планета Земля.

2. Производительность во время выполнения была значительно улучшена благодаря прямому копированию из ‹холста› в текстуру WebGL.

То, что они изначально делали для рендеринга текста, было:

  • Рисовать на холсте
  • Прочитайте холст как байты, отправьте его в приложение WASM.
  • Приложение WASM создает текстуру WebGL с этими байтами и загружает ее в графический процессор.

Чтобы ускорить это, они:

  • Рисовать на холсте
  • Скопируйте данные изображения холста непосредственно в текстуру WebGL, дайте приложению WASM ссылку на эту текстуру.

Это уменьшило количество рывков FPS.

Пример такого прямого копирования в WebGPU см.: https://gpuweb.github.io/gpuweb/#dictdef-gpuimagecopyexternalimage

Вопросы и ответы

В конце было много интересных дискуссий на Q&A. Один из вопросов, который особенно запомнился мне, касалсяможем ли мы ожидать появления отладчика/инспектора "devtools" для WebGPU. Звучало так, будто ответ был положительным, и разработчики спецификаций WebGPU, и поставщики браузеров проявляют большой интерес к предоставлению хороших инструментов отладки.

Келси упомянул группы отладки и метки, которые сегодня являются одним из инструментов WebGPU, который позволяет вам маркировать части вашего конвейера, чтобы упростить отладку, когда что-то пойдет не так. Подробнее об этом можно прочитать здесь: https://gpuweb.github.io/gpuweb/explainer/#errors-errorscopes-labels

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

«Будущее светлое», сказал он. И я согласен!

Я надеюсь, что вы нашли это полезным! Вы можете найти меня в Твиттере или на моем сайте.

Вы можете подписаться на уведомления о будущих встречах WebGL/WebGPU здесь: https://www.khronos.org/news/subscribe/