Bug 82586 - UBO matrix in std140 struct does not work
Summary: UBO matrix in std140 struct does not work
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-13 21:54 UTC by pavol
Modified: 2014-08-17 12:27 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description pavol 2014-08-13 21:54:47 UTC
I am not sure if the problem is actually in my code, but I tested it on nVidia driver and it worked (but their compiler might have a fix for it internally).

Here is vertex shader:

#version 330

layout(location = 0) in vec4 position;

layout(std140) uniform Matrices {
    mat4 model;
    mat4 view;
    mat4 projection;
} matrices;

out gl_PerVertex {
    vec4 gl_Position;
};

/* interpolate to compute normal in fragment shader */
out vec3 v_position;

void main(void)
{
    v_position = vec3(matrices.view * matrices.model * position);
    gl_Position = matrices.projection * matrices.view * matrices.model * position;
}


If I use only one matrix from the uniform it works. I have printed UBOs values and they are just identity matrices.
Comment 1 Ian Romanick 2014-08-14 01:13:45 UTC
What is the failure mode?  A bunch of changes recently occurred in the GLSL compiler (especially in the linker) for UBO matrices.  What version of Mesa are you on?  Can you try a build of master?
Comment 2 pavol 2014-08-14 13:12:57 UTC
"What is the failure mode?"
Don't follow

"What version of Mesa are you on?"
https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers
Seem couple days old.

"Can you try a build of master?"
Can't I just wait for new build in PPA?
Comment 3 Ian Romanick 2014-08-14 16:46:14 UTC
(In reply to comment #2)
> "What is the failure mode?"
> Don't follow

You say it doesn't work.  That's pretty vague.  If it fails in some way, what is the mode of the failure?  (See also http://en.wikipedia.org/wiki/Failure_causes#Component_failure)

Are the member locations incorrect (query through the API)?  Is the row-major / column-major orientation of the matrices incorrect (query through the API)?  Is the generated code reading the wrong locations?  Does it crash in the driver?  Does your computer catch on fire?

Without any information about how it actually fails, it's pretty much impossible to fix.

> "What version of Mesa are you on?"
> https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers
> Seem couple days old.

When I check it now, it should have everything.  The other question: does this work on older Mesa?  Say... a 10.2 stable release?

> "Can you try a build of master?"
> Can't I just wait for new build in PPA?

You can... at some point there will probably be a patch for you to test, and that won't be in PPA.  You can probably wait to worry about it until such a patch exists.
Comment 4 pavol 2014-08-14 20:35:41 UTC
(In reply to comment #3)
> You say it doesn't work.  That's pretty vague.  If it fails in some way,
> what is the mode of the failure?  (See also
> http://en.wikipedia.org/wiki/Failure_causes#Component_failure)
It just does not display anything, hence either whole pipeline crashes (and OpenGL KHR_debug does not print it out) or the transform moves vertices outside clipping region (I might try transform feedback over weekend).

> Are the member locations incorrect (query through the API)?  Is the
> row-major / column-major orientation of the matrices incorrect (query
> through the API)?  Is the generated code reading the wrong locations?  Does
> it crash in the driver?  Does your computer catch on fire?
Locations are correct (at least if gl query returns them properly). I do not know, I do not read anything (or I do not follow). How do I know if it crashes in driver? No, though DPM is really bad.

> Without any information about how it actually fails, it's pretty much
> impossible to fix.

If I apply one of the matrices, it works, if I multiply two of them, it does not.

> When I check it now, it should have everything.  The other question: does
> this work on older Mesa?  Say... a 10.2 stable release?
Yes, it works on 10.2.5

> You can... at some point there will probably be a patch for you to test, and
> that won't be in PPA.  You can probably wait to worry about it until such a
> patch exists.

Ok, hope the process is seamless.
Comment 5 pavol 2014-08-15 07:17:29 UTC
I have got new mesa from PPA and problem seems to be gone. How can I find exact commit fixing this, please?
Comment 6 Roland Scheidegger 2014-08-15 15:13:55 UTC
(In reply to comment #5)
> I have got new mesa from PPA and problem seems to be gone. How can I find
> exact commit fixing this, please?

Just use git bisect. That of course requires you to build mesa yourself.
Comment 8 pavol 2014-08-16 20:34:53 UTC
I have tried to compile mesa, but all I get is GL 2.1

OpenGL version string: 2.1 Mesa 10.3.0-devel (git-9d9879a)

I just build master without any non-default flags. Can you help, please?
(I would like to bisect, and I reported other bug which I want to test)
Comment 9 Ilia Mirkin 2014-08-16 20:39:28 UTC
--enable-texture-float
Comment 10 pavol 2014-08-17 10:33:08 UTC
Thanks, I am not sure if I done it correctly, but bisect gave me this as first bad commit (if I understand it means the bug was introduced in it)

http://cgit.freedesktop.org/mesa/mesa/commit/?id=01bf8bb87565ed3677e43c6b6deeb90378d88647


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.