Has anyone noticed any unusual behavior in the uniform node?

I work with webgl and webgpu to have direct comparisons. This allows me to better isolate any anomalies because the functions in webgl and webgpu are analogous to each other.

Here I have a code function from my webgpu variant in which I notice unusual behavior in the uniform node that I can’t explain. “this.ifftStep” is the uniform node.

	let iterations = 6;//Math.log2(params.size);
 	let pingpong = false;

	for(let i = 0; i < iterations; i++){
		pingpong = !pingpong;

 		this.ifftStep.value = i;
		document.getElementById("testfield3").value = this.ifftStep.value;
		document.getElementById("testfield4").value = i;
		params.renderer.compute(pingpong ? this.computeHorizontalPing : this.computeHorizontalPong);
	for(let i = 0; i < iterations; i++){
		pingpong = !pingpong;

		this.ifftStep.value = i;
		params.renderer.compute(pingpong ? this.computeVerticalPing : this.computeVerticalPong);

The commented out lines of code are usually active. I only commented them out for debugging purposes, just as the testfields are only in there for debugging purposes.
The two testfields show 5 what I expect. In my webgl version there is also a five in the shader. I also implemented a debug method in the shader to be able to detect this. But here a 0 arrives in the shader. But if I replace the i in “this.ifftStep.value = i;” with a 5 so that it looks like this “this.ifftStep.value = 5;” Then in this webgpu variant there is also a 5 in the shader. So the uniform and the shader definitely work. The “this.ifftStep.value” is not used anywhere else in the code. Because if that were the case, manually setting 5 within the for loop wouldn’t change anything. It quickly became clear to me that the iteration values ​​could not be correct based on the result:

This correctly looks like this (from my webgl version):

I can’t explain why both test fields correctly display a 5 but the shader receive a 0. As mentioned, as soon as I replace the i in the for loop with 5, the 5 also arrives in the shader. What’s the difference whether the for loop or I enter a number?
There are no error messages in the console.
I can come up with a small CodePen example if any of the developers want it.


P.S. @sunag
I was really looking forward to r158 and tested it straight away. The result is different but unfortunately it still doesn’t look right. I also tested r158 with my for loop compute shader test. And then I immediately noticed that it was still behaving strangely. I still don’t see the color of the last iteration value i, but the color that belongs to i == 0.

I test this with an analogous example like this one you can see here on CodePen local on my computer. Because some things don’t work on CodePen.

But my testfields clearly show me the last iteration step.
If I replace i with the corresponding number I see the corresponding color. It looks like the uniforms are still not arriving correctly in the compute shader.

Now, I think this is related to a cache update that involves frame registration.
Can you try something like for now:

for( let i = 0; i < iterations; i++) {
	stepUniform.value = i;

	renderer.info.render.frame++; // force uniforms frame update

I will certainly be fixing this soon and you can remove this workaround.

1 Like

That’s it, then it looks like this:

IFFT waves generated with compute shaders. I could now transform any frequency image and create artificial mountains, for example. The IFFT generator is a universal tool.
Now I still have a lot of work to do, but it’s all harmless ordinry stuff on a lower level. The heart of all, the IFFT generator works now.
There were a lot of evolutionary steps in the webGPURenderer to make this possible but it’s nice to be able to see the progress in development.

1 Like