WebGPURenderer: Initial commit.

[Mugen87]

This PR introduces a very basic implementation of a new renderer targeting WebGPU.

The new renderer only provides three basic shaders (mesh, points lines) but already some building blocks for handling geometries, UBOs and textures. Compared to WebGLRenderer the API of WebGPURenderer is very limited and most engine features are not supported yet. However, I think it's a good starting point for further developments and for interested WebGPU devs^^.

I've invested no time in a material system up to now since I've planned to suggest the usage of node based materials right from the beginning.

[Mugen87]

I'm also planning to invest a certain amount of my future development time in enhancing this renderer. Over time, more and more features will be added which will make WebGPURenderer usable in more scenarios.

@mrdoob is it okay if I commit smaller changes and bug fixes related to WebGPURenderer directly to dev? I mean as long as it stays experimental 😇 ?

[mrdoob]

Excellent!!

@mrdoob is it okay if I commit smaller changes and bug fixes related to WebGPURenderer directly to dev? I mean as long as it stays experimental 😇 ?

Sounds good! 👌

[mrdoob]

Thanks!!

[Mugen87]

Yay! WebGPU is coming!!!

[mrdoob]

Exciting! Yes, using NodeMaterial directly sounds great.
We'll have to figure out how to produce WGSL from it at some point though.

/cc @sunag @martinRenou

[Mugen87]

FYI: The current GLSL 4.5 shaders in WebGPURenderer are meant as a temporal solution so it's possible to implement the internals of the renderer. However, we definitely want WGSL. It would be great if NodeMaterial could support this. A small version of MeshBasicMaterial (similar to what I have implemented) would be a good start!

I can of course help with the integration of a node material system since writing shaders for WebGPU is quite different to WebGL. E.g. using UBOs is a must.

Besides, the renderer already expects the uniform data of a material as an array of WebGPUBinding objects. When the renderer has the shader source code and the WebGPUBinding array, it should have all information to create the renderer pipeline object (which is in some sense the WebGLProgram pendant).

[takahirox]

Regarding decode image and send data to WebGPU texture. Does anyone know whether WebGPU plans to directly take image or not? If it doesn't and we need to keep doing that manually, maybe we would ideally better to offload image decoding from main thread to workers (and make _createTexture() async function?). It would be future optimization, we don't need to do now.

[sunag]

I think that can start in jsm/renderers/webgpu/nodes/ a basic version of NodeMaterial?

[Mugen87]

Does anyone know whether WebGPU plans to directly take image or not?

Would be good to know. Unfortunately, I couldn't fine something in the spec or elsewhere.

[takahirox]

Unfortunately, I couldn't fine something in the spec or elsewhere.

Yeah, it seems we need to decode by ourselves for now.

[takahirox]

If I'm right, it's 48 here?

In my webgpu renderer experience, I found matrix3 seems being 4columns x 3rows in WebGPU memory and fourth columns seem ignored.

https://github.com/takahirox/THREE.WebGPURenderer/blob/master/src/renderers/WebGPURenderer.js#L1066-L1077

[Mugen87]

I did not had a chance to test this so far (the shaders do no use a normal matrix yet^^). I have similar code like you in my WebGL2/UBO PR but I wanted to verify first if a sizing of 48 is still required.

[takahirox]

Mine uses normal matrix so it seems to take actually 48 bytes (at least in my demos). But yeah verification should be first. I didn't find the mention about sizing of 48 yet neither.

[mrdoob]

Does anyone know whether WebGPU plans to directly take image or not?

They say we have to use ImageBitmap and copyImageBitmapToTexture.

[takahirox]

Does anyone know whether WebGPU plans to directly take image or not?

They say we have to use ImageBitmap and copyImageBitmapToTexture.

Thanks, I had missed that function. createImageBitmap() (which creates ImageBitmap from image and other resources) should mostly run off main thread then we see less main thread blocking. Good to know that.