On Sat, 2016-08-06 at 07:24 -0700, Jason Ekstrand wrote: > On Aug 6, 2016 4:00 AM, "⚛" <0xe2.0x9a.0...@gmail.com> 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.co > > > m> > 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. > > Yes please. Regardless of whether or not we use RTLD_LAZY, I would > like > undefined symbols to produce a build error rather than a runtime > error you > need extra environment variables to debug.
this is done by using -Wl,--no-undefined (and afaik, it has been in use for some time now), no need to introduce local tool 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 > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Jan Vesely <jan.ves...@rutgers.edu>
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