WebGPURenderer: StorageTexture

[sunag]

Related issue: Closes #26749

Description

const storageTexture = new StorageTexture( width, height );

• Add StorageTexture
• Add webgpu_compute_texture_pingpong example

[Spiri0]

Ok, then I'll be patient and wait for r157.

[sunag]

@Spiri0 Can this example already help with your project?

[Spiri0]

Yes very, this is my topic:

https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://tore.tuhh.de/bitstream/11420/1439/1/GPGPU_FFT_Ocean_Simulation.pdf&ved=2ahUKEwj07qP5vbWBAxUx1AIHHdE9AO4QFnoECBgQAQ&usg=AOvVaw0_z-QXC4vcYeIYLsP5WBfM

With r156 I also created the butterfly texture (pages 26 and 40) and the init spectras. This works very well with the node system and wgslFn. For the butterfly texture I only had to write my own bit-reverse fn but these are minor obstacles. The textures look exactly like in the paper. The only thing I was missing was the textureStore functionality before r156. I could have done the pingpong mechanic thing more complicatedly with two separate shaders, but with the pingpong possibility it's cleaner. I have this IFFT ocean since may in WebGL2, but with lots of render targets. But now I want to do all of this with computer shaders. Phil Crowther inspired me to do this because he has been looking for a gpu IFFT ocean for a longer time. Once I've finished it, he can add it as a module in three.js.
Thanks to your comment with the textureNode and the uniforms, I now understand the node system quite well and I like it.

[mrdoob]

Is this how webgpu_compute_texture_pingpong is supposed to look like?

Screen.Recording.2023-09-20.at.4.31.26.PM.mov

[Spiri0]

This looks good. It looks similar to what I have already implemented in WebGL2 with renderTargets. You probably used the noise pattern that I saw in the r157 example, but that's a user matter. The mechanism certainly looks correct. To us it just looks like noise. However, for the Fourier mechanism, these are numerous different wavelengths that evolve over time. The thing with the StorageTexture was a great idea. I wonder if you or sunag are aware that you have essentially made the DataTexture, which generates the textures on the CPU side, superfluous with the StorageTexture. In any case, I only see advantages in the StorageTexture.
Being able to generate textures on gpu side with the compute shaders is an enormous milestone.

[mrdoob]

Improved the example to make it more visually appealing in d6c8dd0

[Spiri0]

The example turned out very well. Not because it happens to be what I need, but because it conveys the node system very well in conjunction with slightly more extensive but not too large WGSL shaders. It also teaches pretty much everything one need to use compute shaders with their full potential for texture generation. In my opinion, the 3 compute examples and the materials example are sufficient to learn nearly everything about the node system. I'm now really looking forward to the weekend to port my IFFT generator with r157 into my WebGPU variant.

[Spiri0]

Is writing here still correct to the topic? I don't want to create new issues unnecessarily. The pingpong mechanism works fine. I like the solution with the two compute initializations so that only the respective compute needs to be rendered. I have an idea for an extension of StorageTexture. I'm currently initializing this via an initialization compute.

import {wgslFn} from "../../../src/three-defs.js";

export const InitStorageTextureWGSL = wgslFn(`
   fn mainWGSL(
      writeTex: texture_storage_2d<rgba16float, write>,
      readTex: texture_2d<f32>,
      index: u32,
      size: f32
   ) -> void {
      var posX f32(index) % size;
      var posY f32(index) / size;
      var idx = vec2i(i32(posX), i32(posY));

      var tex textureLoad(readTex, idx, 0);
      textureStore(writeTex, idx, tex);
   }
`);

import {InitStorageTextureWGSL} from "../resources/shader/IFFT/initStorageTexture.js";

this.computeInitStorageTexture = InitStorageTextureWGSL({
   writeTex: textureStore(this.pingTexture),
   readTex: texture(this.hkt_Texture),
   index: instanceIndex,
   size: params.size
})

This is no effort but a method like ".setTexture(customTexture)" to initialize a storageTexture would be handy. A "setTexture()" method would be very practical for initializations in other classes to which textures are passed. But that's nothing urgent.

I have another topic that is really causing me problems and that would probably be something for a new issue. If I pass the iteration steps to a uniform in a for loop, they don't arrive correctly in the shader. I created a post about this in the forum:

https://discourse.threejs.org/t/has-anyone-noticed-any-unusual-behavior-in-the-uniform-node/56657

and made a CodePen example.

https://codepen.io/Spiri0/pen/QWzZVdZ?editors=0010

I really like the node system. I think you've created something great with it. I don't claim to fully understand it, but the behavior I'm seeing in my uniform is strange. The analog mechanism in webgl2 works as I expect.

[sunag]

I don't think we have implement the entire uniform mechanism for WebGPU compute, so it could be a uniform bug in specific to WebGPURenderer.compute(), I'll be checking that.

[Spiri0]

Seems like I can look forward to r158 then. There don't seem to be many people who are concerned with webgpu and the node system yet. But it's pretty elegant and saves code. It makes things easier. I tell myself that if interest in webgpu increases quickly, all of these points will already anticipate a lot.
I hope my codePen example is helpful and I'm curious to read what your analysis reveals. Mine surprised me and reassured me at the same time.
I can imagine my IFFT system as a module for three.js. This would then be easy to use for all possible frequency images so that users do not have to deal with the demanding IFFT mechanics themselves. I do this because I want a real ocean because for land I use real maps. But I could also easily create much more natural-looking artificial landscapes with my IFFT system than is possible with the usual noise functions.

[sunag]

I think the concerned is because the system of nodes and TSL is something very new for many, it is not documented and WebGPURenderer and TSL is a WIP, comparisons usually between WebGLRenderer and WebGPURenderer are about the strengths of WebGLRenderer that have been polished over many years, we are closing several issues per month and I believe it is a matter of time before everything is resolved and we have the best of both worlds, and certainly projects like yours speed up development, makes us think about different needs and solutions and it does all the deep testing work which there was no time to do it.

[Spiri0]

I think that might have been the last obstacle in my implementation. The pingpong routine in which I need the uniform for the current iteration step is the last step in the IFFT calculation. The progress in r156 and r157 was already clearly noticeable for me. I think this covers most of the cases that users will ever have to deal with when generating textures with compute shaders.

Not that I'm conjuring up the devil with my confidence, who will then confront me again with the next bug. But if that's the case, so be it.

[Spiri0]

In the forum I see that other people are also interested in the node system and that makes me happy. Since there is still some time until r158, I thought I would take a look at what could possibly cause problems. Instead of THREE.HalfFloatType I tested THREE.FloatType and rgba32float in the shader. rgba16float is enough for me but I just wanted to see if rgba32float also works. That doesn't work and warnings appear in the console that remind me of #26576. But that's more of a luxury problem because with rgba16float I can do a lot of things and everything that I can currently imagine.
I'm really looking forward to r158.