System Environment: -------------------------- Mesa:(7.11)21364bd09d6133f5da12986678fa995fa0aea7e4 Bug detailed description: ------------------------- Fail to retrieve the correct number of active attribute with glGetProgramiv with GL_ACTIVE_ATTRIBUTES. The vertext shader is as following: static const char vs_source[] = "attribute float myAttribVar; \n" "attribute float maxAttribVal; \n" "void main() \n" "{ \n" " gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; \n" " gl_FrontColor.x = myAttribVar / maxAttribVal; \n" " gl_FrontColor.y = 0.0; \n" " gl_FrontColor.z = 0.0; \n" " gl_FrontColor.w = 1.0; \n" "} \n"; And I assume to retrieve 3 active attributes: myAttribVar, maxAttribVal and gl_Vertex with the line glGetProgramiv(prog, GL_ACTIVE_ATTRIBUTES, &count); But the actual value is 2. Reproduce steps: ------------------------- Build and run the attachment, a piglit case.
Created attachment 53740 [details] Piglit case to test retrieving the number of active attribute.
It looks like the built-in attribute gl_vertex not counted by GL_ACTIVE_ATTRIBUTES, similar to bug#32403. This one is for attribute, and that one is for uniform.
This problem only exists in 7.11,correct? This should have been fixed on master by a fairly long (12 patches) and intrusive patch sequence that ended at commit 35613af. Since this sequence was fairly intrusive and this is a minor bug, I'm not in favor of cherry picking the commits over to the stable branch. Unless there's a strong objection, I'd like to close this as WONTFIX.
(In reply to comment #3) > This problem only exists in 7.11,correct? > The issue still exists in master branch. > This should have been fixed on master by a fairly long (12 patches) and > intrusive patch sequence that ended at commit 35613af. Since this sequence was I have tested the latest commit on master branch (94cd9d6be8980f28fdb6b7a8526814802a90f25d) which contains the patches you mentioned (35613af) > fairly intrusive and this is a minor bug, I'm not in favor of cherry picking > the commits over to the stable branch. > > Unless there's a strong objection, I'd like to close this as WONTFIX.
(In reply to comment #4) > (In reply to comment #3) > > This problem only exists in 7.11,correct? > > > The issue still exists in master branch. > > > This should have been fixed on master by a fairly long (12 patches) and > > intrusive patch sequence that ended at commit 35613af. Since this sequence was > > I have tested the latest commit on master branch > (94cd9d6be8980f28fdb6b7a8526814802a90f25d) which contains the patches you > mentioned (35613af) Ah, it is still broken there. I just posted a patch to the mesa-dev mailing list that should fix this: http://marc.info/?l=mesa3d-dev&m=132199856806663&w=2 > > fairly intrusive and this is a minor bug, I'm not in favor of cherry picking > > the commits over to the stable branch. > > > > Unless there's a strong objection, I'd like to close this as WONTFIX.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > This problem only exists in 7.11,correct? > > > > > The issue still exists in master branch. > > > > > This should have been fixed on master by a fairly long (12 patches) and > > > intrusive patch sequence that ended at commit 35613af. Since this sequence was > > > > I have tested the latest commit on master branch > > (94cd9d6be8980f28fdb6b7a8526814802a90f25d) which contains the patches you > > mentioned (35613af) > > Ah, it is still broken there. I just posted a patch to the mesa-dev mailing > list that should fix this: > > http://marc.info/?l=mesa3d-dev&m=132199856806663&w=2 > > > > fairly intrusive and this is a minor bug, I'm not in favor of cherry picking > > > the commits over to the stable branch. > > > > > > Unless there's a strong objection, I'd like to close this as WONTFIX. Rerun the case with the patch, and the patch works well.
Fixed on master by the following commit. The rationale for not backporting this to 7.11 explained in comment #3 still applies. commit e6c314f7d2ed99714376fec6b7509a55535fa3ff Author: Ian Romanick <ian.d.romanick@intel.com> Date: Mon Nov 21 20:47:57 2011 -0800 mesa: Allow generic attributes for glGetActiveAttrib and GL_ACTIVE_ATTRIBUTE Page 77 (page 91 of the PDF) says about glGetActiveAttrib: "The returned attribute name can be the name of a generic attribute or a conventional attribute (which begin with the prefix "gl_", see the OpenGL Shading Language specification for a complete list)." Page 261 (page 275 of the PDF) says about glGetProgramiv: "If pname is ACTIVE_ATTRIBUTES, the number of active attributes in program is returned." It doesn't say anything about built-in vs. user-defined attributes. From the language around glGetActiveAttrib and the lack of an exclusion of built-in attributes, which exists other places (e.g., around glBindAttribLocation), we can infer that GL_ACTIVE_ATTRIBUTES should include the active attribute count. It should also be included in the values returned by glGetActiveAttrib. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43138 Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Tested-by: Yi Sun <yi.sun@intel.com>
The commit is on the master. Verified it.
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.