[Bug 104492] Compute Shader: Wrong alignment when assigning struct value to structured SSBO

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=104492

            Bug ID: 104492
           Summary: Compute Shader: Wrong alignment when assigning struct
                    value to structured SSBO
           Product: Mesa
           Version: 17.2
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel at lists.freedesktop.org
          Reporter: florian.will at googlemail.com
        QA Contact: dri-devel at lists.freedesktop.org

Created attachment 136547
  --> https://bugs.freedesktop.org/attachment.cgi?id=136547&action=edit
Code to reproduce this issue. Requires SDL2.

Hi,

I'm trying to get the Banshee 3D engine
<https://github.com/BearishSun/BansheeEngine> working on my hardware (HD 7870)
using Mesa radeonsi (amdgpu kernel module). I use 17.2.4-0ubuntu1~17.10.1 from
the Ubuntu artful-proposed archive.

It uses a compute shader that reads a texture cube and writes 6 sets of
coefficients into a shader storage buffer object. Details are not important as
I have isolated the (probably) incorrect driver behaviour and created a much
simpler program that triggers the same issue.

In short: Let's say we have a GLSL struct and access the SSBO through a
dynamically-sized array of that struct type using the std430 layout, like this:

struct ResultRecord
{
        float a[10];
        float b[10];
        float c[10];
        float weight;
};

layout(std430) buffer gOutput
{
        ResultRecord ssb[];
};

Then a simple assignment of a local variable of the same struct type to ssb[i]
writes the floats into incorrect buffer offsets, because b, c and "weight" are
placed as if the array elements in a, b and c were vec4-aligned instead of
float-aligned, tripling the size of a, b and c.

Code that triggers it is like this, which should hopefully be valid GLSL (and
makes more sense the way it is used in Banshee 3D):
ResultRecord result;
// ... populate result ...
ssb[gl_LocalInvocationIndex] = result;

The test program is available here and contains a (maybe too) detailed
explanation and three program variations that fix the issue:
https://gist.github.com/w-flo/b1a5791749eea5f36cb54628037ba2bf
But I'll also attach it to this bug report.


Looking at the RADEON_DUMP_SHADERS=1 output, I think that the bug is already
visible in the TGSI dump, as explained in the comment at the top of my
reproducer program. I'll attach the output (it's possibly based on an older
version of the reproducer).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180104/b9345b74/attachment-0001.html>