On Mon, Aug 8, 2016 at 9:52 AM, Jan Vesely <jan.ves...@rutgers.edu> 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?
No idea if anyone actually does this, but in theory it allows the usage of the old DRI drivers (i810, mach64, mga, r128, savage, sis, tdfx, and unichrome) with a newer libGL. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
