On Sat, 2016-08-06 at 13:00 +0200, ⚛ wrote: > On Sat, Aug 6, 2016 at 4:34 AM, Rob Clark <robdcl...@gmail.com> > wrote: > > > > 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).. > We could add a verifier to the build process that tests the > foo_dri.so > libraries (as well as all other libs subject to dlopen by Mesa) for > undefined symbols: > > $ LD_PRELOAD=libGL.so ldd -d -r radeonsi_dri.so \ > | grep "^undefined" && echo "red alert!" > > This will ensure that Mesa does not break apps after replacing all > RTLD_NOWs with RTLD_LAZY. > > I am going to start writing a new patch verifying relevant *.so files > at buildtime.
This won't help at all. the linking process already includes no- undefined flag, so the build will fail at linking stage if symbols can't be resolved. RTLD_NOW detects bugs in deployment. IMO it's preferable if DE fails to start instead of crashing hours into work. sure I can set LD_BIND_NOW env var, but there are programs that have much stronger case for using lazy binding (like LO) that would be negatively affected. shaving 6M instructions does not seem like strong enough benefit to justify this. Jan > > > > > But I'm not sure that optimizing for glxinfo is the best goal. > I will turn my attention to manifestations of suboptimal Mesa GL in > other apps as soon as I am satisfied with glxinfo/glxgears (and after > the list of my patches at patchwork gets closer to zero). > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
