Created attachment 105808 [details] Test case Looking at the IR dump, the compiler frontend generates (expression bvec2 ubo_load (constant uint (0)) (constant uint (8))) to load s2.bv.x. However, the GL API (correctly) believes that s2.bv is at offset 16. Deleting any field from S1 or S2 (or putting the contents of S2 directly in the UBO) masks the problem. It seems that some part of the compiler stack is not putting padding after s1 to align bv to a vec4 boundary.
This test passes on master and 10.4. It was fixed with all the UBO work I did earlier in the year, but I forgot to close the 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.