FFT shaders are probably misgenerating SPIR-V for memoryBarrierShared();

[hlavaatch]

I have tracked down the error messages that pops up upon starup under vulkan backend:

ERROR:<unknown>: [SC] Object: 0x0 | SPIR-V module not valid: MemoryBarrier: Vulkan specification requires Memory Semantics to have one of the following bits set: Acquire, Release, AcquireRelease or SequentiallyConsistent
ERROR:<unknown>: [SC] Object: 0x0 | SPIR-V module not valid: MemoryBarrier: Vulkan specification requires Memory Semantics to have one of the following bits set: Acquire, Release, AcquireRelease or SequentiallyConsistent

They originate from compilation of the FFT compute shaders, _fftcol.comp and _fftrow.comp and seem to be related to the shader's use of memoryBarrierShared() memory barrier.

I'm reading there have been some issues with glsl to spir-v compilers generating improper memory barrier instructions, and gfx-backend-vulkan seems to be using glsl-to-spirv crate to compile the shaders from glsl source code. I'll try to capture the genrated shaders and check their validity...

It might be worth checking the updated versions of the glsl-to-spirv, gfx uses 0.1 Continuing research at glsl-to-spirv...

[hlavaatch]

glsl-to-spirv 0.1.4 does not help

[hlavaatch]

Captured shader binaries, trying to figure out whats wrong with them... shaders.zip

[msiglreith]

Hmm, I'll check the generated spv with a newer glslang version later. Not sure if the GLSL/ES semantics match with SPIR-V here exactly. In the 'worst' case it should enfore seq consistent memory semantics.. If it works it would require an update to glsl-to-spirv.

[msiglreith]

Yeah looks like a new glsl-to-spirv version is needed

[hlavaatch]

Yep, they need to update their bundled glslangValidator I'll put together evidence and nag them ;)

[hlavaatch]

Done