The glsl2 merge seems to have introduced a regression in the Raytraced Shadows demo from Humus, the shadows are no longer visible. I have only tried this on r300g, as the demo fails to run on i965 with "Variable indexing of shader outputs unsupported". http://www.humus.name/index.php?page=3D&ID=53
Variable indexing of shader outputs is not supported by r300 either. I believe this has something to do with missing loop unrolling that was part of the previous GLSL compiler.
Oh, in that case it's probably the same as bug 29654: It refuses to run with the same error on i965, and runs (but not correctly) on r300g. Will retry this stuff once loop unrolling lands.
I've been playing with this demo a bit today. With my loop unrolling branch, setting SPHERE_COUNT to 1 (in Main.h) works. Setting it to 2 or higher results in the whole box interior being shadowed. Using MESA_GLSL=dump, the IR generated looks correct, so I'm not sure what's going wrong. I'll keep digging.
Created attachment 38323 [details] Dump of shaders from Raytraced Shadows demo The problem appears to be improper placement of varying arrays. In the Mesa IR for linked fragment program 1 notice that INPUT[15] is used for both lightVec and sphereVec[1].
With the commit listed below and the reset of my glsl2-loops branch, this demo renders correctly with all 7 spheres. I will leave this bug open until glsl2-loops is merged to master. commit df869d916308759fbacb227f60b1b6eda73131e2 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Mon Aug 30 15:37:44 2010 -0700 linker: Handle varying arrays, matrices, and arrays of matrices Fixes piglit test case glsl-array-varying-01.
glsl2-loops branch is now merged, and this bug is fixed (at least on GM45 with i965_dri.so).
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.