System Environment: -------------------------- Arch: i386 Platform: huronriver Libdrm: (master)2.4.26-3-g2acaf160df584a5ef7b5c5b84819389948cd97ad Mesa: (master)f97acf40155a5d63a70ac6875df8128cb91d2369 Xserver: (master)xorg-server-1.11.0 Xf86_video_intel: (master)2.16.0-45-g6b1ed58d63e9ac80d7d028fa3036633436154816 Kernel_unstable: (drm-intel-next)c6a389f123b9f68d605bb7e0f9b32ec1e3e14132 Bug detailed description: ------------------------- It happens on pineview, ironlake and sandybridge. Oglc GLSLlinker(positive.variable.structWithoutDeclaringType) also fails due to the same commit. Bisect find 60df737ad57c20701b66d7cd3f63d1dc75745986 is the first bad commit. 60df737ad57c20701b66d7cd3f63d1dc75745986 Author: Eric Anholt <eric@anholt.net> Date: Wed Sep 7 12:04:57 2011 -0700 glsl: Don't do structure splitting until link time. We were splitting on each side of an unlinked program, and the two sides lost track of which variables they referenced, resulting in assertion failure during validation. Fixes piglit link-struct-uniform-usage. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reproduce steps: ---------------- 1. start X 2. ./oglconform -z -s -suite all -v 2 -D 115 -test GLSLlinker positive.variable.structInitialization
Created attachment 53032 [details] New piglit case to reproduce this regression Attached piglit shader_runner case could be used to reproduce this bug
Ian, can you review Shuang's piglit case?
I'm not 100% convinced that the test is valid. The GLSL spec is somewhat ambiguous in this area. The only text that I can find that speaks to this issue at all is on page 55 (page 60 of the PDF) of the 3.30 spec: "Structure types must be of the same declared structure." I honestly don't know what that means. Even though this is technically a regression, I'm decreasing the priority. I doubt any real application will ever intentionally encounter this.
I've just tried the case on one Nvidia card, it also fails. So I'm confused, since accoring to the test case document, this case is written against GLSL 1.10 rev 59. In section 4.2: "Shared globals are global variables declared with the same name in independently compiled units (shaders) of the same language (vertex or fragment) that are linked together to make a single program. Shared globals share the same namespace, and must be declared with the same type. They will share the same storage. Shared global arrays must have the same base type and the same size. Scalars must have exactly the same type name and type definition. Structures must have the same name, sequence of type names, and type definitions, and field names to be considered the same type. This rule applies recursively for nested or embedded types. All initializers for a shared global must have the same value, or a link error will result."
Just heard from Gordon that this case is invalid. Then this oglc case is also invalid. We need to mark it as invalid
(In reply to comment #4) > I've just tried the case on one Nvidia card, it also fails. So I'm confused, > since accoring to the test case document, this case is written against GLSL > 1.10 rev 59. In section 4.2: > "Shared globals are global variables declared with the same name in > independently compiled units (shaders) of the same language (vertex or > fragment) that are linked together to make a single program. Shared globals > share the same namespace, and must be declared with the same type. They will > share the same storage. Shared global arrays must have the same base type and > the same size. Scalars must have exactly the same type name and type > definition. Structures must have the same name, sequence of type names, and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In the test case, s1 has type st1 in one shader and type st2 in the other. It was an error that these shaders ever linked. :) > type definitions, and field names to be considered the same type. This rule > applies recursively for nested or embedded types. All initializers for a shared > global must have the same value, or a link error will result."
(In reply to comment #6) > (In reply to comment #4) > > I've just tried the case on one Nvidia card, it also fails. So I'm confused, > > since accoring to the test case document, this case is written against GLSL > > 1.10 rev 59. In section 4.2: > > "Shared globals are global variables declared with the same name in > > independently compiled units (shaders) of the same language (vertex or > > fragment) that are linked together to make a single program. Shared globals > > share the same namespace, and must be declared with the same type. They will > > share the same storage. Shared global arrays must have the same base type and > > the same size. Scalars must have exactly the same type name and type > > definition. Structures must have the same name, sequence of type names, and > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > In the test case, s1 has type st1 in one shader and type st2 in the other. It > was an error that these shaders ever linked. :) > > type definitions, and field names to be considered the same type. This rule > > applies recursively for nested or embedded types. All initializers for a shared > > global must have the same value, or a link error will result." Thanks for your explanation :)
*** Bug 44967 has been marked as a duplicate of this bug. ***
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.