Three.js: ¿Habrá un renderizador basado en WebGPU?

Teóricamente, en un futuro lejano, pero como sabrá, el grupo de WebGPU todavía está hablando / alineándose activamente para formar las primeras propuestas / especificaciones / borradores. Pasarán años antes de que tengamos una especificación completa e implementaciones estandarizadas en funcionamiento.

Dicho esto, recomendaría participar / seguir en el desarrollo de WebGPU aquí: https://github.com/gpuweb/gpuweb/wiki y https://www.w3.org/community/gpu/

Si WebGPU resulta ser tan poderoso como todos esperamos, es probable que las bibliotecas como Three.js tengan que reescribirse desde cero para aprovecharlo al máximo.

@TimvanScherpenzeel
Sí estoy de acuerdo. Seré el futuro lejano.
¿Es imposible agregar el renderizador WebGPU en three.js sin reescribir el núcleo desde cero? ¿Deberíamos tener que reescribir todo el motor (API) en threejs desde cero? Creo que incluso si sale WebGPU, es muy probable que coexistan juntos (WebGL / WebGPU) por un tiempo. No creo que WebGPU acabaría con todo el ecosistema WebGL.
Sin embargo, supongo que WebGPU sería muy poderoso si lo admite de forma nativa y directa, a diferencia de que WebGL es una API indirecta del controlador gráfico;Y, Google y otros grandes actores lo quieren para un mejor rendimiento de DeepLearning y una experiencia gráfica de alto rendimiento en el navegador.

ThreeJS ya tiene muchos renderizadores diferentes: WebGLRenderer, WebGL2Renderer, CSS3DRenderer, SVGRenderer ... WebGPU se puede manejar de manera similar, cuando la API está lista. También es posible realizar cambios más profundos en la biblioteca con el tiempo.

Cerrando este problema por ahora, aunque estoy emocionado de que estas API de próxima generación también estén disponibles. :)

@donmccurdy
De hecho ... Three.js es tan flexible que puede implementar incluso WebGPU en el futuro, ¿verdad?

Según la propuesta de WebGPU, mencionaron a los desarrolladores de Three.js como uno de sus principales públicos objetivo.

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

Desarrolladores de marcos de JavaScript que están creando bibliotecas de GPU, destinadas a ser utilizadas en contenido web, pero que proporcionan una API de nivel superior y ocultan gran parte de los gráficos de bajo nivel y los detalles informáticos de sus usuarios. Por ejemplo, three.js.

Mi pregunta es que usan otro lenguaje de sombreado llamado WHLSL.
https://github.com/gpuweb/WHLSL

Mi pregunta es que usan otro lenguaje de sombreado llamado WHLSL.

"Cruzaremos ese puente cuando lleguemos a él".

Se anunció en Google I / O con soporte experimental en Chrome Canary para OSX disponible ahora:
https://www.youtube.com/watch?v=K2JzIUIHIhc

Babylon.js ha anunciado soporte completo para él cuando salga. Compruébalo aquí:
https://forum.babylonjs.com/t/webgpu-is-coming-to-babylon-js/3122

Espero que el equipo de ThreeJS siga el ejemplo.

No estoy seguro de por qué cerrar esto, ya que se mencionó el apoyo potencial. Por lógica, dejamos problemas abiertos para "rastrearlo". Si lo cierra, simplemente se olvida de ... a menos que haya otro problema para rastrearlo.

Puedo asegurarles que no lo olvidaremos ... 😁

Pero no soy un mantenedor. Personalmente, seguiré el primer marco que adopta webgpu. Y el punto no soy yo. Es el mensaje que ustedes dan para cerrar esto. Es como "Cosa genial, claro, pero no me importa. Puede aguantar en el limbo".

PD. Lo leí mal, pensé que era "Te puedo asegurar que no lo olvidarás"

@MichelDiz se abrió este problema para preguntar si planeamos admitir WebGPU. La pregunta ha sido respondida: absolutamente planeamos admitir WebGPU. Probablemente sea demasiado pronto para trabajar en eso, pero se abrirán nuevos temas cuando estemos listos para discutir esto.

@TimvanScherpenzeel ciertas partes que se abstraen de los usuarios tendrán que ser reescritas, pero sugerir que todo el asunto tendrá que ser "reescrito desde cero" es una exageración enorme. Las geometrías de zona de influencia tendrán el mismo formato. Al igual que WebGL, WebGPU también se basa en sombreadores GLSL -> WHLSL. Parece que el formato glTF que se ha convertido en estándar WebGL también será estándar WebGPU. Todas las API de Three.js más utilizadas permanecerán sin cambios en un 99%, mientras que el nuevo renderizador WebGPU estará bajo el capó y, con suerte, traerá un gran aumento de rendimiento y desbloqueará el potencial de renderizar grandes escenas a altos fps.

Hola a todos,
¡Muchas gracias por las actualizaciones de este!
Solo quería compartir mi perspectiva sobre características como esta. En nuestro caso, no siempre usamos WebGL para aplicaciones de consumo. Tenemos experiencias WebGL en las que visualizamos conjuntos de datos muy grandes donde los activos son ~ 1GB y se sirven localmente en hardware fijo donde podemos controlar los navegadores y sus indicadores para habilitar WebGPU. Entonces, incluso en modo experimental, definitivamente nos encantaría tener soporte para eso. Entiendo que somos la minoría, pero solo quería agregar esta vista en la conversación.

@sinokgr ¿Cómo ayuda WebGPU a mostrar activos de 1GB? Hasta donde tengo entendido, las estructuras de datos para los datos de geometría son las mismas que las de WebGL.

gracias por la respuesta @mrdoob . Para ser 100% honesto, no diré que entiendo lo suficiente las diferencias y la información que encuentro en línea es muy vaga (de acuerdo con mi investigación de todos modos). La sensación principal que tengo es de cosas que leí como el último mensaje de @DVLP que les gustó,

aportará un gran impulso al rendimiento y desbloqueará el potencial de renderizar grandes escenas a altos fps.

eso me hace pensar que vamos a ver al menos algunas mejoras. Esto podría ser, ¿qué tan rápido, por ejemplo, se cargarán estos activos, quizás mejores fps? No estoy seguro.

La carga inicial en la memoria normal seguirá siendo la misma, pero toda la API de la GPU será más rápida, por lo que desde el momento en que esté involucrada la GPU debería ser más rápida. Así es como veo de dónde vendrá el aumento de rendimiento:

1. Cargue el archivo del modelo en el navegador - misma velocidad
2. Analizar el modelo y cargar la geometría en un búfer de matriz, la misma velocidad
3. Cargue programas de GPU - más rápido
4. Cargue texturas: inicialmente a la misma velocidad pero más rápido cuando se entregan a la GPU
5. Transfiera geometría a la GPU - más rápido
6. Realice una serie de llamadas de dibujo para renderizar un marco, más rápido

Muchas gracias por la explicación @DVLP . Los puntos 5 y 6 me parecen muy interesantes ya que tenemos miles de objetos con muchos materiales.

Puede pasar mucho tiempo hasta que WebGPU sea ampliamente adoptado. Hasta entonces, puede acelerar todo el proceso utilizando instancias de malla
https://threejs.org/docs/#api/en/objects/InstancedMesh

Me temo que no podemos usar instancias, todos los objetos son únicos @DVLP

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