[Mesa-dev] GLSL compiler produces different code for the same source

Tom Stellard tstellar at gmail.com
Sat Mar 31 03:46:56 PDT 2012


On Sat, Mar 31, 2012 at 06:25:08AM -0400, Tom Stellard wrote:
> On Sat, Mar 31, 2012 at 12:02:42AM -0700, Kenneth Graunke wrote:
> > On 03/30/2012 02:11 PM, Vadim Girlin wrote:
> > > Hi,
> > >
> > > I noticed that GLSL compiler sometimes produces different code for the
> > > same shader source, e.g.:
> > >
> > > Vertex shader source:
> > >
> > >> 	gl_Position = gl_Vertex;
> > >> 	gl_FrontColor = gl_Vertex;
> > >
> > > GLSL IR:
> > >
> > >>        (assign  (xyzw) (var_ref gl_Position)  (var_ref gl_Vertex) )
> > >>        (assign  (xyzw) (var_ref gl_FrontColor)  (var_ref gl_Vertex) )
> > >>        (assign  (xyzw) (var_ref gl_Position at 2)  (var_ref gl_Position) )
> > >>        (assign  (xyzw) (var_ref gl_FrontColor at 3)  (var_ref gl_FrontColor) )
> > >
> > > Another variant has another order of the last two assignments:
> > >
> > >>        (assign  (xyzw) (var_ref gl_FrontColor at 4)  (var_ref gl_FrontColor) )
> > >>        (assign  (xyzw) (var_ref gl_Position at 5)  (var_ref gl_Position) )
> > >
> > > Both variants are correct, but it makes the debugging harder - e.g. one
> > > of the variants uncovers the bug in my code, and it's hard to reproduce
> > > it. I guess we might want to remove the dependency on the moon phase
> > > etc, and maybe provide some way to control it for debugging.
> > >
> > > My knowledge of the GLSL compiler is still not good enough to fix it
> > > quickly, so I'd be grateful if somebody could help.
> > >
> > > There is the reduced test program in the attachment that demonstrates
> > > the problem. It compiles the shader every second, so running it with the
> > > following command line usually shows both variants during the first 10
> > > seconds:
> > >
> > >> MESA_GLSL=dump ./test | grep -A 20 linked
> > >
> > > Vadim
> > 
> > Weird...I have no idea why it would do that.
> > 
> > So far, I haven't been able to reproduce this locally, either with your 
> > test program, glslparsertest, or the standalone compiler.  Valgrind 
> > doesn't seem to have any complaints about uninitialized data, either...
> > 
> > Can anyone else reproduce this?
> 
> I was able to reproduce this with r300g.  Is it possible that one of the
> shader CAPS is causing this?

Or maybe the ordering of keys in a hash?

> 
> -Tom
> 
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list