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!
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
As you wish.
(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.
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
(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.