[Mesa-dev] [PATCH] src: replace RTLD_NOW with RTLD_LAZY

[Ian Romanick]

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.vesely at 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
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160808/cecee789/attachment.sig>