Bug 67548

Summary:	glGetAttribLocation seems to be broken
Product:	Mesa	Reporter:	Neil Roberts <nroberts>
Component:	glsl-compiler	Assignee:	Ian Romanick <idr>
Status:	RESOLVED NOTOURBUG	QA Contact:
Severity:	normal
Priority:	medium	CC:	ullysses.a.eoff
Version:	unspecified
Hardware:	Other
OS:	All
See Also:	https://bugs.freedesktop.org/show_bug.cgi?id=66292
Whiteboard:
i915 platform:		i915 features:
Attachments:	Test case

Description Neil Roberts 2013-07-30 16:49:32 UTC

With Mesa 9.1.5 Cogl has started failing most of the conformance tests when using the GLSL backend. I have bisected it down to this commit in Mesa:

http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.1&id=e8af0576a5cf3cb0bf49d02449042489291c5b2c

I think the problem has something to do with glGetAttribLocation returning the wrong values.

I am attaching a standalone test case which uses three attributes and calls glGetAttribLocation on all of them. One of the attributes is the vertex position, and the other two are colours. The ‘color’ attribute is red for the vertices on the left and green for the vertices on the right. The ‘other_color’ attribute is set to a constant blue colour. These two attributes are added together to get the final colour.

Before that commit in Mesa, the rectangle has a gradient from magenta to cyan as you would expect. After that commit it is just red to green as if the other_color attribute isn't being added.

If you reorder the attributes it also fixes it.

Comment 1 Neil Roberts 2013-07-30 16:50:15 UTC

Created attachment 83311 [details]
Test case

Comment 2 Ian Romanick 2013-07-30 19:12:36 UTC

I think this doesn't actually have anything to do with the bisected change.  I think this is a pre-existing bug.  Note the output before the change:

[idr@mumford-wire ~]$ ./a.out 
glGetAttribLocation("pos") = 1
glGetAttribLocation("color") = 0
glGetAttribLocation("other_color") = 2

and the output after the change:

[idr@mumford-wire ~]$ mesa installed ./a.out 
glGetAttribLocation("pos") = 1
glGetAttribLocation("color") = 2
glGetAttribLocation("other_color") = 0

This matches my expectations of the shader: other_color is listed first, then pos, then color.  Of the bunch, only other_color doesn't have an array associated.  In desktop GL, attribute 0 is special... it's the attribute that provokes the vertex for normal drawing commands.  I suspect a single vertex gets provoked when glVertexAttrib4f is called, but nothing happens in glDrawArrays.

To confirm this, I added the following line before the call to glLinkProgram.  With that change, the test fails on Mesa 9.1.4 (which does not include e8af057).

  glBindAttribLocation(glsl_program, 0, "other_color");

I'm also not 100% sure this is Mesa's bug.  I'll need to dig through the GL specs.  I'm somewhat sure the spec used to say this behavior was intended, but I always have trouble remembering the exact rules.

Does this test work (with my change) on other implementations?  What output does it produce?

Comment 3 Tapani Pälli 2013-07-31 05:26:10 UTC

the issue and symptoms here matches with bug #66292

Comment 4 Robert Bragg 2013-07-31 09:19:56 UTC

This reminds me of a bug I filed last year relating to broken attribute locations: https://bugs.freedesktop.org/show_bug.cgi?id=55503

I wonder if there is any interaction with this issue.

Comment 5 Ian Romanick 2013-08-09 19:13:17 UTC

We tried the experiment from comment #2 on NVIDIA and AMD.  On NVIDIA, it draws as it would on OpenGL ES.  On AMD, nothing is drawn.  Since no vertices should be provoked, I actually think AMD's behavior is technically correct.

Comment 6 Ian Romanick 2013-08-15 22:03:14 UTC

I'm going to leave this bug open for now, but I'm going to take it off the release tracker.  I'm mostly convinced that Cogl is relying on ES behavior that is different in desktop GL.  I want to be completely convinced before closing the bug.

Comment 7 Robert Bragg 2013-08-16 22:46:31 UTC

(In reply to comment #6)
> I'm going to leave this bug open for now, but I'm going to take it off the
> release tracker.  I'm mostly convinced that Cogl is relying on ES behavior
> that is different in desktop GL.  I want to be completely convinced before
> closing the bug.

I can confirm that Cogl wasn't binding the position attribute to generic attribute location 0 and doing so fixes our current conformance test failures.

For reference the relevant part of the GL 3.0 spec that covers these semantics is Section 2.7 "Vertex Specification" pg 27

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.