Support cross-compilation of typed-buffers

[nbentyNV]

GaussianBlur.ps.slang declares Buffer<float> weights;

To reproduce, run MultiPassPostProcess sample, load an image and check the GaussianBlur box

[tangent-vector-personal]

Can you confirm what the desired GLSL equivalent is?

I'm guessing HLSL Buffer maps to GLSL textureBuffer or imageBuffer, but it isn't clear which.

Also: can an HLSL Buffer<T> use an arbitrary type T (like a struct) or is that limited to StructuredBuffer?

[nbentyNV]

Buffer<T> == textureBuffer
RWBuffer<T> == imageBuffer.
Our internal shaders only use Buffer. The ShaderBuffers sample uses both, but I'll its shaders convert it to GLSL.
T can't be a struct, it's a subset of DXGI_FORMAT.

[tangent-vector-personal]

Thanks.
I assume that it follows that the right mapping for RWTexture2D is image2D. I've got some work to do in order to cover all this.

[nbentyNV]

ParticleSimulate.cs.slang uses AppendStructuredBuffer, RWStructuredBuffer and RWByteAddressBuffer.

Unfortunately, AppendStructuredBuffer requires UAV-counters which are not supported in Vulkan. The solution would be to create a typed-buffer for the counter and use atomic operations for it.

Raw-buffers have no GLSL equivalent, but we can mimic them using imageBuffer with r8 layout

[tangent-vector-personal]

Notes to self:

• Lowering Buffer<T> to textureBuffer (and b[i] to texelFetch) should work, and just puts a bit more emphasis on making sure that the hackSamplerForTexelFetch thing works.

• Mapping raw buffers to imageBuffer with r8 labor sounds reasonable (although "byte-address" buffers are actually more "uint32-address" buffers). The challenge is mapping all the intrinsic operations reasonably. Does GLSL support atomic son images?

• creating an additional buffer just to store an atomic counter is annoying in a lot of ways. I suppose it can't be helped, but this seems like it will be lower on the priority order.

[nbentyNV]

I'll disable the particle system for Vulkan for now