Bug 97291 - Incorrect packing of struct
Summary: Incorrect packing of struct
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: 11.2
Hardware: All Linux (All)
: medium major
Assignee: mesa-dev
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-11 09:02 UTC by Matias N. Goldberg
Modified: 2016-08-15 07:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Shaders with faulty and non faulty versions (4.55 KB, application/x-bzip)
2016-08-11 09:02 UTC, Matias N. Goldberg
Details

Description Matias N. Goldberg 2016-08-11 09:02:34 UTC
Created attachment 125694 [details]
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!
Comment 1 Matias N. Goldberg 2016-08-11 09:24:47 UTC
Bahahuoasudh!!!!

Just close it down.
I thought I was on latest version but I was not.

On Mesa 12.1 this issue has been fixed.

Our Compute samples refuse to run, which I guess that's expected.
Our Forward3D sample is also not working correctly (it should show hundreds of lights but those lights are gone), which was working correctly in Mesa 11.2

Tomorrow I'll take a look, but I am already seeing incorrect warnings in those shaders:
0:228(28): warning: `nNormal' used uninitialized
0:231(14): warning: `material' used uninitialized

Close this ticket I'll create a new one when my mind is fresh
Comment 2 Brian Paul 2016-08-11 14:23:11 UTC
As you wish.
Comment 3 Ilia Mirkin 2016-08-11 14:48:49 UTC
(In reply to Matias N. Goldberg from comment #1)
> Bahahuoasudh!!!!
> 
> Just close it down.
> I thought I was on latest version but I was not.
> 
> On Mesa 12.1 this issue has been fixed.
> 
> Our Compute samples refuse to run, which I guess that's expected.

Compute should work on most recent hardware now. See what's supported where and in which mesa version over at

https://people.freedesktop.org/~imirkin/glxinfo/

> Our Forward3D sample is also not working correctly (it should show hundreds
> of lights but those lights are gone), which was working correctly in Mesa
> 11.2
> 
> Tomorrow I'll take a look, but I am already seeing incorrect warnings in
> those shaders:
> 0:228(28): warning: `nNormal' used uninitialized
> 0:231(14): warning: `material' used uninitialized

Those warnings are broken... they don't handle inout arguments, among likely other things.
Comment 4 Matias N. Goldberg 2016-08-11 19:54:12 UTC
OK I'm fully re-powered and thinking straight now:

I've built Mesa from scratch. Tried commits git-edfc17a (current head of branch 12.0) and commit 17f1c49b9ad05af4f6482f6fa950e5dcc1a779d1 (current head of master branch)

In both, I don't have compute shaders. Googling around it appears for Southern Island radeon it could be buggy so it was turned off. Not 100% sure but I think that's what's happening.
Anyway, not a big deal on that. WIP. Move on.

Like I said our Forward3D demo was glitching and I didn't know why. I've investigated the problem and located it:
* glGetIntegerv w/ GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT is returning 4, should return 256 for my HW.
* glGetIntegerv w/ GL_TEXTURE_BUFFER_OFFSET_ALIGNMENT is returning 4, should return 256 for my HW.

This is clearly not a shader issue which is why I reported it in this ticket: https://bugs.freedesktop.org/show_bug.cgi?id=97305

Thanks for assistance, and I'm sorry for having bothered you earlier.
Cheers
Comment 5 Michel Dänzer 2016-08-15 07:27:42 UTC
(In reply to Matias N. Goldberg from comment #4)
> [...] I don't have compute shaders. Googling around it appears for
> Southern Island radeon it could be buggy so it was turned off.

No, it just requires kernel >= 4.7 on SI (and LLVM >= 3.9 in general).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.