On Wed, 04 Jan 2012 03:28:12 -0800, Kenneth Graunke <kenn...@whitecape.org> wrote: > On 01/03/2012 09:43 PM, Marek Olšák wrote: > > This ProgramStringNotify call causes excessive shader recompilations > > in the game Cogs (from some Humble Bundle). Approximately 25% of > > in-game CPU time is spent on translating shaders and register > > allocation. If the shaders were larger, it would be much worse. > > Moreover, I have realized calling ProgramStringNotify is not needed > > for st/mesa in this case at all (I just comment it out if I want > > higher frame rates), because it doesn't use the prog->SamplerUnits > > array when translating shaders. The array is only used when we set > > samplers, so setting _NEW_TEXTURE is sufficient. It seems that i965 > > could do the same thing. Another option would be to cache precompiled > > shaders, but that seems more complicated than doing what st/mesa does. > > > > Marek > > Yeah, I noticed that a while back too, but we never arrived at a > solution and it slipped off my radar. I agree completely, > ProgramStringNotify is completely overkill and bogus. > > We actually already rely on _NEW_TEXTURE for all shader programs. Since > the uniform code already flags _NEW_TEXTURE, we should be able to just > add the SamplerUnits array to the program key (specifically, > brw_sampler_prog_key_data), and that should take care of any state > dependent recompiles. Then we wouldn't need ProgramStringNotify at all. > > Right?
Well, since the data stored is part of the program, and when just changing programs _NEW_TEXTURE wouldn't get set, I think _NEW_PROGRAM is the flag you mean. That would make a ton of sense to me -- if you depend on SamplerUnits for your program handling, go look at it when _NEW_PROGRAM is flagged.
pgpUidtAmNDYx.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
