Why the GTK+ wayland backend can't be enabled in linux distros, at all

[Thiago Macieira]

On terça-feira, 27 de março de 2012 18.00.55, Pierre-Loup A. Griffais wrote:
> Hi Thiago,
> 
> Thanks for your interest in the NVIDIA driver; please allow me to try to
> clarify the situation. You're right that we're not building with -fPIC for
> performance reasons, but that only applies to the x86 platform. No text
> relocations should be present in our x86_64 libraries thanks to PIC being
> free on that platform.

Indeed, it had to be the case because there is no linker option to generate 
text relocations in position-independent code for x86-64. For x86, the absence 
of -fPIC means text relocations but still allows for position-independence.

Still, the OP did not say whether the issue was on x86 or not.

> There exists a utility called 'prelink' that can be used to pro-actively
> relocate shared objects on the system (or a single shared object to an
> arbitrary base address), removing the need for the loader to apply
> relocations if used properly. Prelinking libnvidia-glcore at a fixed, free
> address allows memory that would otherwise by dirtied by the loader when
> relocating to remain shared cleanly between processes.

Last I checked prelinking the NVidia GL libraries, there were two problems:

1) prelink refused to work on ELF modules with text relocations, which 
excluded the NVidia libs outright

2) even for modules that were prelinked, the pages weren't shared when loaded. 
Now this might be a problem in my measurement or because the binaries I tested 
with did not have pagefuls of GNU_RELRO.

Prelinking helps with load time processing, but not with reducing memory 
footprint.

> However, the linux ELF loader currently has a bug that causes the second
> type of relocation to be overwritten even if prelink had already
> initialized them to the correct value. This causes the memory in the
> relocation sections to get dirtied without anything being changed, which
> contradicts our goal.

That might explain my results too.

> Attached is a proof-of-concept patch which fixes this issue for the x86_64
> Linux ELF loader. By both applying this patch to the loader and prelinking
> libnvidia-glcore.so, distros can reduce the memory overhead of linking an
> application against the NVIDIA libGL to just a few kB:

Interesting. Those are very good results. Can you provide the same results 
when two applications are running? Our hope is that those 6544 kB of 
Private_Clean (which are sharable) become actually shared and move to 
Shared_Clean.

Has this patch been submitted to the glibc folks? They have just had a change 
of governance.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120327/d7a5255e/attachment.pgp>