I wrote a compute shader using Buffer type because i only need floats yet i get strange outputs. But it works fine for structured buffers but thats more for generics which i don’t need and is much slower than regular Buffer…
Does unity simply not support regular Buffer type?
What kind of odd issues were you having? RWBuffer<float> works fine for me. Even RWByteAddressBuffer rwbuffer; works well, using the optional ComputeBufferType parameter in new ComputerBuffer() creation of ComputeBufferType.Raw.
I was using RWBuffer the data was just random values not the actual values i set the buffer to in C#. When i changed it to structured buffer then it worked.
Hmmm…
I just double-checked the MS docs - it should work for anything, as long as this anything fits into 4x32-bit. So it should work with float4.
Can you please report a bug? We’ll take a look
I’ve been happily using Buffer and RWBuffer in compute shaders on my main NVidia based development PC (using Unity 2020.1.f3). When I run the same app on AMD hardware things are very broken.
I was just trying to debug using RenderDoc and I can see that in the simplest test where I write out something like uint4(1, 2, 3, 4) the buffer seems to end up containing uint4(1, 0, 0 ,0) …Basically the YZW fields are always clear.
Would the issue discussed above explain this? If so, is it going to be fixed? …I’d really rather not have to switch to Buffer unless I really have to!
I just submitted a bug report with a custom sample project.
To be clear: in my experience I can use multi component compute Buffer/RWBuffer types (e.g. uint4) when using an NVidia GPU but the same code fails on AMD hardware. Switching over to StructuredBuffer/RWStructuredBuffer works fine on both.
Regular Buffers in DirectX are the same as TexelBuffers in Vulkan. They’re basically 1D textures. The reason for this is historical, as back in DX10 days the HW didn’t really allow any other kind of random access to memory except via the texturing unit so they decided to call what are essentially 1D textures as Buffers.
StructuredBuffers become SSBO’s in Vulkan and are just raw memory loads in both Vulkan and DX. They definitely should not be slower than buffer in any decently modern HW (5 years old or so). Buffer is mostly if you need to use the sampling unit for things like format conversions etc.
Our API doesn’t really seem to support ComputeBuffers as buffers in anycase. As Buffers would require you to specify format, just like with textures, and our constructor doesn’t accept it. Nor do we have a ComputeBufferType that would allow it. As an example ComputeBufferType.Default explicitly states that it’s for StructuredBuffer Unity - Scripting API: ComputeBufferType.Default