Nearly day, I want to learn how to use ComputeShader, and have some trying with writing wgsl.
I find it is very hard to get error log when cs.Dispatch() working wrong.
It always log warning in the console. it is hard to find the error warning in 55 warning:
I write a very easy wgsl, It only clear a rt with a color:
I try to add a texture to cs:
something wrong (texture are type: TEXTURETYPE_UNSIGNED_BYTE, format RGBA)
As for WebGL, we don’t check at each step if an error occurred for performance sake. Even if we did it and were able to return an error string, you would get the same errors (generated by Chrome, not Babylon) than in the the console log, anyway.
The problem in your PG is that you declare a
cpuBase texture resource but don’t use it. In that case, the resource is not added to the bind group layout (it’s the WebGPU implementation in Chrome that is doing that, not Babylon). So, you should not declare it in the compute shader / not add it in the
ohhh, my mistake!
Did rawTexture3D not be supported in webGPU? Should I store 3d data in floatArray?
3D textures are supported in WebGPU (WebGPU Shading Language).
If you have a PG that does not work we can try to have a look.
how to use RTT like texture? I think I need show it in a plane to see that does code work well.
RawTexture3D is this:
it always throw error:
The problem in the first PG is that WebGPU does not support linear filtering of 32 bits float texture yet. So, when using 32 bits float textures, you must use the NEAREST filtering setting:
Alternatively, you can use 16 bits float texture, for which linear filtering is supported:
Linear filtering of 32 bits float textures should/will be added in WebGPU in a future extension (it’s also an extension in WebGL).
Regarding creating 3D textures with data, it’s a bug in the WebGPU implementation, it will be fixed by:
Thank you for your help!!! You are always excellent in graphic
Excuse me? I want to logical shift a u32 left/right:
But it throw: shiftLeft is unknown function:
What is going on?
You should use
>> instead, moving to
shiftRight is quite recent and is not implemented in Canary yet. It’s even possible that this change will never be implemented and the spec will be rolled back to use