primus breaks on fedora with mesa-13.0.3-6

[gsgatlin]

Hello.

Nvidia has created a new library called libglvnd https://github.com/NVIDIA/libglvnd

The purpose is "This is a work-in-progress implementation of the vendor-neutral dispatch layer for arbitrating OpenGL API calls between multiple vendors on a per-screen basis, as described by Andy Ritger's OpenGL ABI proposal"

Fedora is adding this to all fedora 25 machines in a few days. Mesa has been redone to support this new library.

It looks like they have implemented it in 4 patches to "mesa." I can post the patches if its important?

With these changes "VirtualGL" bridge continues to work but "primus" bridge no longer works.

Here is the output from command line:

https://paste.fedoraproject.org/541783/14858971/

(primusrun also does not work)

Does anyone have any clues on how to get around that? I have opened:

https://bugzilla.redhat.com/show_bug.cgi?id=1418103

Here are some logs: (Can't really see anything in them)
/var/log/messages
first run working with 13.0.3-5
https://paste.fedoraproject.org/541695/58843511/
second run failing with 13.0.3-6
https://paste.fedoraproject.org/541707/14858848/
/var/log/Xorg.8.log
first run working with 13.0.3-5
https://paste.fedoraproject.org/541709/88496314/
second run failing with 13.0.3-6
https://paste.fedoraproject.org/541712/85885065/

I'm sorry I don't have any ideas on how to fix this. I did notice

/usr/lib64/libGL.so.1: undefined symbol: _glapi_tls_Current

in the output on the commanbd line.

Please let me know if I can provide any further information or be of any help with this issue. Thanks.

[jwrdegoede]

The: "/usr/lib64/libGL.so.1: undefined symbol: _glapi_tls_Current" error is weird, what does:

rpm -qf /usr/lib64/libGL.so.1 say ? And does: ldd -r /usr/lib64/libGL.so.1 give the same error ?

On my system with libglvnd-0.2.999-7.gitdc16f8c.fc25 and mesa-libGL-13.0.3-6.fc25.x86_64 this gives:

[hans@shalem master]$ rpm -qf /usr/lib64/libGL.so.1
libglvnd-glx-0.2.999-7.gitdc16f8c.fc26.x86_64
[hans@shalem master]$ ldd -r /usr/lib64/libGL.so.1
linux-vdso.so.1 (0x00007ffc171ba000)
libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f87be9a9000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007f87be66a000)
libXext.so.6 => /lib64/libXext.so.6 (0x00007f87be458000)
libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f87be1a2000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f87bdf9e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f87bdd7e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f87bd9b8000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f87bd790000)
/lib64/ld-linux-x86-64.so.2 (0x00005558c3bd1000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007f87bd58c000)

Notice that ldd -r does not give the error you are seeing. I've a feeling you've somehow overwritten your libGL.so.1 with one from a different source.

[gsgatlin]

Hi. Here is the output from those commands.

[gsgatlin@y470c ~]$ rpm -qf /usr/lib64/libGL.so.1
libglvnd-glx-0.2.999-7.gitdc16f8c.fc25.x86_64
[gsgatlin@y470c ~]$ ldd -r /usr/lib64/libGL.so.1
linux-vdso.so.1 (0x00007fff04dbb000)
libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f481ce61000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007f481cb22000)
libXext.so.6 => /lib64/libXext.so.6 (0x00007f481c910000)
libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f481c65a000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f481c456000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f481c236000)
libc.so.6 => /lib64/libc.so.6 (0x00007f481be70000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f481bc48000)
/lib64/ld-linux-x86-64.so.2 (0x000055b3fb143000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007f481ba44000)

[jwrdegoede]

Hi,

On 02-02-17 15:47, gsgatlin wrote: Hi. Here is the output from those commands. ***@***.*** ~]$ rpm -qf /usr/lib64/libGL.so.1 libglvnd-glx-0.2.999-7.gitdc16f8c.fc25.x86_64 ***@***.*** ~]$ ldd -r /usr/lib64/libGL.so.1 linux-vdso.so.1 (0x00007fff04dbb000) libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f481ce61000) libX11.so.6 => /lib64/libX11.so.6 (0x00007f481cb22000) libXext.so.6 => /lib64/libXext.so.6 (0x00007f481c910000) libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f481c65a000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f481c456000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f481c236000) libc.so.6 => /lib64/libc.so.6 (0x00007f481be70000) libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f481bc48000) /lib64/ld-linux-x86-64.so.2 (0x000055b3fb143000) libXau.so.6 => /lib64/libXau.so.6 (0x00007f481ba44000)

Hmm, so you're not getting the error here, that is weird... I wonder what primus is doing causing this, I bet it is playing LD_LIBRARY_PATH tricks ... Regards, Hans

[gsgatlin]

Hello. Here is what the "primusrun" script looks like.

https://paste.fedoraproject.org/543062/14860483/

There is some manipulation of LD_LIBRARY_PATH

[jwrdegoede]

Hi,

On 02-02-17 16:15, gsgatlin wrote: Hello. Here is what the "primusrun" script looks like. https://paste.fedoraproject.org/543062/14860483/ There is some manipulation of LD_LIBRARY_PATH

Can you try commenting out the line setting the LD_LIBRARY_PATH, that should no longer be necessary on a glvnd enabled system. Regards, Hans

[jwrdegoede]

Hi,

On 02-02-17 16:15, gsgatlin wrote: Hello. Here is what the "primusrun" script looks like. https://paste.fedoraproject.org/543062/14860483/ There is some manipulation of LD_LIBRARY_PATH

Or maybe uncomment the line about mesa-drivers: # Mesa drivers need a few symbols to be visible # export PRIMUS_LOAD_GLOBAL=${PRIMUS_LOAD_GLOBAL:-'libglapi.so.0'} So try uncommenting the second line. Can someone give me (or point me to) a quick overview of how primus is supposed to work and what all the library paths being added to LD_LIBRARY_PATH contain (and what the purpose of the libraries overriden this way is) ? Regards, Hans

[gsgatlin]

Hello,

could this be what you needed for overview?

https://github.com/amonakov/primus/blob/master/technotes.md

Will try to uncomment the lines and test once I can get back to my office. Cheers.

[jwrdegoede]

Hi,

On 02-02-17 16:23, gsgatlin wrote: Hello, could this be what you needed for overview? https://github.com/amonakov/primus/blob/master/technotes.md

Ugh, from that doc: * simplicity/minimalism: * only GLX functions are overridden So it is overriding libGLX with its own custom implementation, yeah that is likely going to wreck havoc with libglvnd's libGL as that needs extra data passed by libglvnd's libGLX to figure out which libGL backend (e.g. mesa or nvidia's) to use. So this is definitely something into which the primus developers will need to look into. It may not be hard to fix this, but I don't even know where to begin. Regards, Hans

[gsgatlin]

If I comment the export LD_LIBRARY_PATH line it opens a window but it uses the wrong opengl. (INTEL)

If I comment out PRIMUS_libGL it segfaults.

But thanks a lot for taking a deep look into this. Perhaps some others will have some ideas. Cheers.

[gsgatlin]

check out

https://www.reddit.com/r/Fedora/comments/5sakeg/workaround_bumblebeenvidia_libglvnd/

[jwrdegoede]

Hi,

On 06-02-17 03:18, gsgatlin wrote: check out https://www.reddit.com/r/Fedora/comments/5sakeg/workaround_bumblebeenvidia_libglvnd/

Great, can someone document this at: https://fedoraproject.org/wiki/Bumblebee Please ? Regards, Hans

[gsgatlin]

Well, I need to test it and see if the primusrun script could be altered to work using his workaround. If it works would need to see if the "optirun" program could also be changed to work somehow. That will be harder since its written in C I think.

[gsgatlin]

But I will try to update the wiki one way or the other.

[gsgatlin]

Did not seem to work for me.

https://paste.fedoraproject.org/549972/48640003/

Oh well. Still open to any and all suggestions. Do not want to have to switch distros eventually.

[gsgatlin]

Alright. I did more experimentation.

The trick is that

__GLVND_DISALLOW_PATCHING=1

needs to be set AND the nvidia shim must be rebuilt/recompiled AFTER libglvnd has been added by mesa. This could be accomplished by running

bumblebee-nvidia --force

by hand as root. Or by waiting until the next kernel upgrade. So that information will need to be added to the wiki.

Things that need to be done.

patch primusrun in the primus rpm to include this variable. (It must be exported)
do a "pull request" to get it added upstream if @amonakov approves of it. I think this change could be beneficial to fedora or arch linux users who have libglvnd.

try to see if this can be set within "optirun" using the setenv() syscall.
If it can and if it works, do another pull request on that change as well.

I will be pretty busy today in meetings but hopefully it can be fixed later in the week.