Computer shaders cannot load textures that they have previously created themselves #26749
Comments
|
I created a much shorter example. https://codepen.io/Spiri0/pen/wvReJKR I have no idea why it doesn't work in CodePen, but I have the same code locally and use composer to control the textures. Basically, this is secondary because the error message in the console is independent of it. I have left out all unnecessary ballast in the example. When I want to use line 115 so that the shader should read in its previously created texture, the error message comes up. I have no idea how the bindings and locations are processed in the background, but based on the error message I suspect the problem is there. |
|
This seems confusing to me, using storageTexPing: textureStore(pingTexture),
storageTexPong: textureStore(pongTexture),
//
computePhase.computeNode.parameters.phase = pingPhase ? texture(pingTexture) : texture(pongTexture);There is a lot in this code that is not part of the issue, I would suggest if possible to make it more minimalist to facilitate interpretation. |
|
I have reduced this significantly. I also didn't like the scope of my example. Have you seen this yet? I deleted everything unnecessary: The interesting thing is that the computer shader understand textures from other computer shaders. It only seems to have a problem with the ones which it stored self before. |
Thanks! But still about the code, I don't think this is a bug, the same readTexPing: texture(pingTexture),
storeTexPong: textureStore(pongTexture), and change the uniforms values between the frames and ping/pong as I said here. |
|
I thought I would avoid exactly the conflict with reading and writing at the same time with my ping-pong logic. I initialize the pingtexture with a datatexture. In the shader, when the pingtexture is at the input, only the condition for saving the pongtexture is met. And vice versa. This then changes after every interval. In the further course, two more computer shaders need the ping or pong texture. You're talking about uniforms "changing the uniforms values" and "textureNode.value". I only know the parameters in the node system that I perceived as uniforms. I'll take a closer look at the whole thing, because if you're sure that I did something wrong, I don't want to keep you any further. That's a bit embarrassing for me. |
If you try to use the same texture to write/read in the same render-pass, like this code below, it's unlikely to work: someFn( {
storageTexPing: textureStore( pingTexture ),
storageTexPong: textureStore( pongTexture ),
//...
phase: texture( pingTexture ) // pingTexture already being used in the pass to write
} );Try something like this: const readTexNode = texture( pingTexture );
const writeTex = textureStore( pongTexture );
someFn( {
readTex : readTexNode,
writeTex : writeTexNode
} );
// frame update
readTexNode.value = frame % 2 === 0 ? pingTexture : pongTexture;
writeTexNode.value = frame % 2 === 0 ? pongTexture : pingTexture;
// compute ... |
|
Now I understand your argument with the textureNode and the uniforms. That's pretty elegant. I still tend to fall into the webgl way of thinking from time to time. I tested your recommendation and then updated the small CodePen example. https://codepen.io/Spiri0/pen/wvReJKR This has now become quite manageable. On my computer I can now see the uv test image in the pingTexture and the pongTexture. But I get a lot of warnings: I'm trying to find out what all the warnings are about. |
|
I didn't want to bother you any longer because I see there's enough to do and I could do the whole thing with two separate computer shaders. I admit I don't understand what the warning waterfall in the console is all about with the bindings. I can find very little or nothing about such topics on the web. I saw that in babylon.js the bindings are specifically reconfigured in the pingpong compute shader. This doesn't seem to be a trivial matter - swapping textures and textureStores. Looks like you have now done something that brings a solution with r157. If time permits, I would be happy if you could explain what the problem is or was. The better I understand what the causes are or were, the more precisely I can analyze it in advance if I come across something unusual again in order to save work for you. |
|
The implementation of the |
|
Will the StorageTexture class understand the other texel formats in compute shaders in addition to 8unorm? I'm thinking of 16float and 32float. Unfortunately, the 8unorm is a bit too low for some data textures, 16float would be very helpful. |
Description
If I write a compute shader that store textures, I can load and use those textures in another compute Shader.
But when I try to pass a texture to a compute shader that I previously created with the same shader, then I get these warnings and it doesn't work:
Reproduction steps
1.) Create a compute shader that stores a texture and reads a texture.
2.) In the first run, use an initial texture for the texture input of the compute shader.
3.) In the next run, pass the texture created by the compute shader itself to the texture input of the compute shader.
Unfortunately, in the CodePen example that I created, I only get a white image so far.
Since I can use a texture created by another computer shader, I suspect that it might have something to do with the bindings and locations.
The compute shaders are really great for IFFT (inverse fast Fourier transformations). IFFT requires computer shaders that can load their own previously created textures. Considering that the textureStorage function is brand new in 3js, it runs very satisfactorily.
Code
Live example
https://codepen.io/Spiri0/pen/abPwOoG
Screenshots
No response
Version
156
Device
Desktop
Browser
Chrome
OS
Windows
The text was updated successfully, but these errors were encountered: