On Tue, 08 Nov 2011 23:16:21 -0800, Kenneth Graunke <[email protected]> wrote: > Ian, > > I just tried running Cogs (from the Humble Indie Bundle 3) and > discovered a terrible regression: it continually keeps recompiling > fragment shader 19 over and over again. > > It looks like it was caused by commit 71990969 ("mesa: Rewrite the way > uniforms are tracked and handled"). > > Each time we try to use the shader, we look in the program cache, but > fail every time, and resort to compiling it. It turns out the > brw_wm_prog_key is entirely identical *except* for a field called > "program_string_id", which increases every time. > > Apparently this is set by brwProgramStringNotify (brw_program.c:141), > and is a monotonically increasing number that's supposed to uniquely > identify a particular shader. > > Commit 71990969 made _mesa_uniform() call ProgramStringNotify as part of > "extra magic necessary" to propagate sampler changes to the driver. > This causes the fragment program's ID to be set to a new/incremented > value. Which means we never find it in the cache again. > > The code you replaced didn't call ProgramStringNotify, and Cogs seems to > work equally well without it, so I'm not sure why it needs to be there. > > (I must admit, I have no idea why this ID is useful nor what > ProgramStringNotify actually does...)
The ID is a stand-in for "the code associated with this shader struct is different", which includes samplers being different. This avoids needing to hash the entire contents of the IR for looking up matches for this shader in our compiled shader cache.
pgpZGkLe1vtXY.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
