On 08/08/2016 09:52 AM, Jan Vesely wrote: > On Mon, 2016-08-08 at 08:54 -0700, Ian Romanick wrote: >> On 08/05/2016 07:05 PM, ⚛ wrote: >>> >>> On Sat, Aug 6, 2016 at 3:37 AM, Jan Vesely <jan.ves...@rutgers.edu> >>> wrote: >>>> >>>> On Sat, 2016-08-06 at 02:42 +0200, Jan Ziak 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. >>>> >>>> this is IMO micro-optimization in the wrong place. RTLD_NOW also >>>> guarantees that symbols were successfully resolved. Changing it >>>> to lazy >>>> may hide bugs by deferring failure to future point in the >>>> execution. >>> >>> Question 1: Are you suggesting to replace current RTLD_LAZY in all >>> locations with RTLD_NOW? >>> >>> Question 2: Exists there a reason for _not_ linking >>> radeonsi_dri.so, >>> swrastg_dri.so, etc, directly to Mesa's libGL.so? The Gallium >>> *_dri.so libraries are the same inode on the filesystem. >> >> This is an intentional feature. This allows libGL and *_dri.so to be >> installed from different versions. It also allows the possibility >> for a >> *_dri.so from outside the Mesa source tree. > > Just out of curiosity, what is the motivation for using different _dri > and mesa version? > Are there license restrictions that prevent distributing mesa with > custom _dri binaries?
So that you can update one without changing the other. It's also useful as a developer... I can have one libGL that I point at a variety of i965_dri.so builds for comparison testing, etc. We (I) originally implemented this feature so that non-Mesa drivers could use a single libGL. A couple (very uncommon) drivers used this feature, but it didn't gain much traction. Once glvnd is more widely deployed and has had more practical experience, it may be worth reevaluating how some of this is implemented. There's quite a bit of mechanism involved in, for example, the remap table stuff. Removing that would at least allow some code simplification / removal. > I know that virtualbox uses this approach, it breaks when guest distro > updates mesa packages (until vbox-additions catch up). > > regards, > Jan >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
