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

[Jan Vesely]

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?

I know that virtualbox uses this approach, it breaks when guest distro
updates mesa packages (until vbox-additions catch up).

regards,
Jan

> 
> > 
> > Question 3: Isn't the current status quo (i.e: not linking
> > radeonsi_dri.so directly to libGL.so) also a micro-optimization
> > that
> > can hide certain bugs?
> > 
> > Question 4: Is it planned for *_dri.so belonging to Gallium/DRI
> > _not_
> > to be mapped to the same inode on the filesystem in the future? If
> > there is no such plan, what was the original point of having
> > multiple
> > _dri.so files mapped to the same inode?
> > 
> > Thanks.
> > 
> 
-- 
Jan Vesely <jan.vesely at rutgers.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160808/c9ef78bc/attachment.sig>