WebGPU support

[alvarosabu]

Description

WebGPU Three.js r171 has been released and it’s a major milestone for WebGPU integration with third-party libraries such as React Three Fiber and bundlers like Vite or Next.js. We can now do this with zero configuration:

Three.js Vanilla Three.js

import * as THREE from 'three'
import { WebGPURenderer } from 'three/webgpu'
 
const renderer = new WebGPURenderer()

R3F

import { Canvas } from '@react-three/fiber'
import { WebGPURenderer } from 'three/webgpu'
 
<Canvas gl={canvas => new WebGPURenderer({ canvas })}>

Suggested solution

Enable a renderer prop to override the renderer, restricted to canvas-based WebGL/WebGPU renderers.

<script setup>
import { WebGPURenderer } from 'three/webgpu'
</script>

<template>
   <TresCanvas :renderer="WebGPURenderer" />
</template>

Alternative

No response

Additional context

No response

Validations

• I agree to follow this project's Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

[andretchen0]

I think the R3F/Svelte approach of ...

import { Canvas } from '@react-three/fiber'
import { WebGPURenderer } from 'three/webgpu'
 
<Canvas gl={canvas => new WebGPURenderer({ canvas })}>

... is preferable to the suggested API from above:

<script setup>
import { WebGPURenderer } from 'three/webgpu'
</script>

<template>
   <TresCanvas :renderer="WebGPURenderer" />
</template>

By accepting a callback like R3F/Svelte, we let users pass their own args to the constructor. That's really handy generally, but in the case of WebGPU in its current state, it's probably the cleanest approach for opening up its functionality.

WebGPU is undocumented and the current implementation accepts some parameters with no matching <TresCanvas /> props, e.g.: device, requiredLimits, trackTimestamp.

Sources:

• Latest Tres core props
• Latest THREE Renderer (undocumented) parameters
• Latest THREE WebGPURenderer (undocumented) parameters

[verekia]

Also worth mentioning that if you use a function prop, it should ideally be async so that renderer.init() can be awaited. If not awaited, it will initially wrongly report the WebGPUBackend in browsers that only support WebGL:

https://github.com/verekia/three-gpu-ecosystem-tests#testing-the-backend-type

Similarly, R3F shows a warning because it tries to render as WebGL first before the WebGPU renderer is loaded:

https://github.com/verekia/three-gpu-ecosystem-tests#r3f-render-called-before-backend-initialized-issue

Bottom-line: make sure you delay or make it possible to delay the first render until the WebGPURenderer has been fully initialized.

If async is too much refactoring, it would be good to at least have some workaround like the frameloop never state that's currently needed for R3F.