[Bug 97291] Incorrect packing of struct

[bugzilla-daemon at freedesktop.org]

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

            Bug ID: 97291
           Summary: Incorrect packing of struct
           Product: Mesa
           Version: 11.2
          Hardware: All
                OS: Linux (All)
            Status: NEW
          Severity: major
          Priority: medium
         Component: glsl-compiler
          Assignee: mesa-dev at lists.freedesktop.org
          Reporter: dark_sylinc at yahoo.com.ar
        QA Contact: intel-3d-bugs at lists.freedesktop.org

Created attachment 125694
  --> https://bugs.freedesktop.org/attachment.cgi?id=125694&action=edit
Shaders with faulty and non faulty versions

I'm the main developer of Ogre 2.1

Our shaders produce incorrect results on Mesa. (we always use std140)

I believe the problem is caused by incorrect packing of structs. It's 05:30 am
now so I couldn't double check yet.

I am attaching the Vertex shader and Pixel shader. The main and only difference
between the two is that one does shadow mapping, the other one doesn't.

The one doing shadow mapping just glitches. By glitches I mean colours are
washed out (as if lighting was really wrong), or just black.
This happens with all of our samples where shadow mapping is done.

I believe this is caused by our unusual struct definition:

struct ShadowReceiverData
{
        mat4 texViewProj;
        vec2 shadowDepthRange;
        vec4 invShadowMapSize;
};

struct Light
{
        vec3 position;
        vec3 diffuse;
        vec3 specular;

        vec3 attenuation;
        vec3 spotDirection;
        vec3 spotParams;
};
layout(binding = 0) uniform PassBuffer
{
        //Vertex shader (common to both receiver and casters)
        mat4 viewProj;

        //Vertex shader
        mat4 view;
        ShadowReceiverData shadowRcv[3]; //This is not in the "good" shader

        //Pixel shader
        mat3 invViewMatCubemap;

        float pssmSplitPoints0; //Not present in the "good" shader
        float pssmSplitPoints1; //Not present in the "good" shader
        float pssmSplitPoints2; //Not present in the "good" shader
        Light lights[1];

} pass;


glxinfo | grep 'version'
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 4.1
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.0
OpenGL core profile shading language version string: 4.10
OpenGL version string: 3.0 Mesa 11.2.0
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.2.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

OpenGL renderer string: Gallium 0.4 on AMD CAPE VERDE (DRM 2.43.0, LLVM 3.8.0)

I own a Radeon HD 7770 1GB.

May worth noting this bug also happens on SW rasterizer because the exact same
output can be seen on a virtual machine.

I'm attached the shaders, both under "Good" and "Bad" folder.

I'm guessing you're gonna need more information from me so let me know what I'm
missing. Ideally I would have time to track this down to the exact variable in
the wrong offset but I don't have the time (and it's 05:48am already!).

You probably should add our samples to your testing suite. A lot of them don't
work with Mesa and would help improve Mesa greatly.
Our code can be found at:
https://bitbucket.org/sinbad/ogre/src/dc52e186d53611b20d4f99d30266c56c29099ef7/?at=v2-1-pso
I can provide assistance compiling our samples. (or binary blobs if it's too
much hassle)

Just as an example, this is how our PbsSample is supposed to look:
http://imgur.com/7lCnZ6h
This is how Mesa renders it (incorrectly): http://imgur.com/SfOsBgY
This is how Mesa (correctly!) renders it when shadows are disabled (Note: In
the pbs sample there are 3 lights but when shadows are disabled Ogre will only
use 1 light): http://imgur.com/mS1i74Y

In other samples activating shadow mapping just results in zero. My best guess
is bad offset calculation.

Have fun!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160811/35fe2f1c/attachment.html>