Rob Clark <robdcl...@gmail.com> writes: > On Fri, Aug 5, 2016 at 8:42 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote: >> Mesa source code prior to this patch uses both RTLD_NOW and RTLD_LAZY. >> This patch removes all RTLD_NOW in favor of RTLD_LAZY. >> >> In comparison to early binding, lazy binding reduces CPU instruction count >> of small GL apps (e.g: glxinfo) by 6 million instructions. >> Larger apps won't notice the difference. > > tbh, I don't know the background of existing places that use RTLD_LAZY > instead of RTLD_NOW (but my experience w/ xserver using LAZY has not > been positive, so I think going the other direction seems like a good > idea).. But I'm not sure that optimizing for glxinfo is the best goal. > I know that at least for freedreno a lot of the startup time for small > real gl apps (ie. something that mostly matters for piglit runs) goes > to constructing regalloc interference graph.. maybe there is some way > to leverage what is being done for on-disk shader cache to cache some > of this up-front work and make a meaningful reduction in startup cost > for things that actually do a bit more than glxinfo. (Plus speeding > up piglit runs is actually a real world benefit..)
I do think that RTLD_LAZY makes sense, and there's no reason to waste the CPU time if we don't need it. If nothing else, we all run a lot of piglit processes that all create contexts. As far as "what if there are unresolved symbols or something?", I think if we have symbols not being covered by piglit even once, we've already lost. For your regalloc, have you looked at i965's direct q value calculation in brw_fs_reg_allocate.cpp? That might save you a ton of time. That said, I was skimming a paper recently that seemed to be saying that if you can assume a not-completely-general set of register classes, you can do the equivalent of the pq test without the giant table.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
