Three.js: Will there be WebGPU based renderer?

Theoretically in the far future but as you may know the WebGPU group is still actively talking / aligning on forming first proposals / spec / drafts. It will be years before we will have a complete spec and working standardised implementations.

That said I would recommend getting involved / following in the WebGPU development here: https://github.com/gpuweb/gpuweb/wiki and https://www.w3.org/community/gpu/

If WebGPU turns out to be as powerful as we all hope it to be libraries like Three.js will likely have to be rewritten from scratch in order to take full advantage of it.

@TimvanScherpenzeel
Yes, I agree. I will be the far future.
Is it impossible to add WebGPU renderer in three.js without rewriting the core from scratch? should we have to rewritten the whole engine(API) in threejs from scratch? I think even if WebGPU comes out, it would be very likely to coexist together (WebGL/WebGPU) for a while. I don't think WebGPU would kill all WebGL ecosystem.
However, I assume that WebGPU would be very powerful if it supports natively & directly unlike that WebGL is indirect API of graphic driver;
And, Google and other big players want it for the better DeepLearning performance and high performance graphic experience in browser

ThreeJS has many different renderers already – WebGLRenderer, WebGL2Renderer, CSS3DRenderer, SVGRenderer... WebGPU can be handled similarly, when the API is ready. Deeper changes to the library are possible over time, too.

Closing this issue for now, although I'm excited for these next-gen APIs to be available as well. :)

@donmccurdy
Indeed.. Three.js is so flexible that can implement even WebGPU in the future, right?

According to the WebGPU proposal, They mentioned about Three.js deverlopers as one of their main target audiences.

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

JavaScript framework developers who are building GPU libraries, intended to be used in Web content, but providing a higher-level API and hiding much of the low-level graphics and compute details from their users. For example, three.js.

My Question is that They use another shader language called WHLSL.
https://github.com/gpuweb/WHLSL

My Question is that They use another shader language called WHLSL.

"We'll cross that bridge when we come to it."

Was announced @ Google I/O with experimental support in Chrome Canary for OSX available now:
https://www.youtube.com/watch?v=K2JzIUIHIhc

Babylon.js has announced full support for it when it comes out. Check it out here:
https://forum.babylonjs.com/t/webgpu-is-coming-to-babylon-js/3122

I hope ThreeJS team will follow the lead.

Not sure why close this as it was mentioned the potential support. By logic, we left issues open to "track" it. If you close it, you just forget about... unless there is other issue to track it.

I can assure you we won't forget about it... 😁

But I'm not a maintainer. Personally, I will follow the first framework that adopts webgpu. And the point isn't me. Is the message you guys give closing this. It is like "Cool thing, sure thing, but I don't care. It can hold there in the limbo".

PS. I read it wrong, I thought it was "I can assure you won't forget about it"

@MichelDiz this issue was opened to ask if we plan to support WebGPU. The question has been answered: we absolutely do plan to support WebGPU. It is probably too early now to work on that, but new issues will be opened when we are ready to discuss this.

@TimvanScherpenzeel certain parts that are abstracted away from the users will have to be rewritten but suggesting the whole thing will have to be "rewritten from scratch" is a massive overstatement. Buffer geometries will have the same format. Just like WebGL, WebGPU is also based on shaders GLSL -> WHLSL. It seems like glTF format that has become WebGL standard will also be WebGPU standard. All most-used Three.js APIs will stay 99% unchanged while the new WebGPU renderer will be under the hood and hopefully will bring large performance boost and unlock a potential of rendering big scenes at high fps.

Hi all,
many thanks for the updates on this one!
I just wanted to share my perspective on features like this. In our case, we don't always use WebGL for consumer applications. We do have WebGL experiences that we visualise very big datasets where the assets are ~1GB and served locally on fixed hardware where we can control the browsers and its flags to enable WebGPU. So even if in experimental mode, we could definitely love to have support for that. I understand that we are the minority, but I just wanted to add this view in the conversation.

@sinokgr How does WebGPU help on displaying 1GB assets? As far as I understand the data structures for geometry data are the same as WebGL.

thanks for the reply @mrdoob . To be 100% honest, I won't claim I understand enough the differences and the information I find online is very vague (according to my research anyway). The main feeling I'm getting is from stuff I read like the last message from @DVLP that you liked,

will bring large performance boost and unlock a potential of rendering big scenes at high fps.

that make me think that we're going to see at least some improvements. This might be, how fast for example these assets will load, better fps maybe? I'm not sure.

Initial loading to the regular memory will stay the same but the entire GPU API will be quicker so from the moment where the GPU is involved it should be faster. Here's how I see where the performance boost will be coming from:

1. Load model file to the browser - same speed
2. Parse model and load geometry to an array buffer - same speed
3. Load GPU programs - faster
4. Load textures - initially the same speed but faster when handing over to the GPU
5. Transfer geometry to the GPU - faster
6. Make a series of draw calls to render a frame - faster

Many thanks for the explanation @DVLP . Points 5 and 6 sound very interesting to me since we have thousands of objects with a lot of materials.

It may be a long time until WebGPU is widely adopted. Until then you can speed up the whole thing using mesh instancing
https://threejs.org/docs/#api/en/objects/InstancedMesh

I'm afraid we can't use instancing, all objects are unique @DVLP

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