[elrepo] Nvidia Driver Performance: El Repo vs. NVidia's .run file

[EBradley at williams-int.com]

Hi Phil,

Thanks for the follow-up! I've already created a quick little script
that will check the status of /usr/lib64/libGL.so.1 and if necessary,
delete and recreate it to point to /usr/lib64/nvidia/libGL.so.1, which
in turn is a symbolic link to /usr/lib64/nvidia/libGL.so.<version
number>. Pointing the symlink to /usr/lib64/nvidia/libGL.so.1 avoids
calling out specific version numbers in my script, which is always a
good thing.

Thanks again,


Evan

-----Original Message-----
From: Phil Perry [mailto:phil at elrepo.org] 
Sent: Tuesday, April 26, 2016 3:47 PM
To: elrepo at lists.elrepo.org
Subject: Re: [elrepo] Nvidia Driver Performance: El Repo vs. NVidia's
.run file

On 26/04/16 19:08, EBradley at williams-int.com wrote:
> Hi Manuel, Phil, and Steve,
>
> Thank you all for the replies! And let me also apologize for my email 
> client not following the thread structure in the list. I'll reply to 
> everyone in this message so as not to disrupt the flow any more than 
> necessary.
>
> Manuel:  I do now see why you requested the Xorg.0.logs and it appears

> that I took the long way around. I just wasn't sure if the libGL 
> discussion was going to take us in another direction rendering your 
> request moot, so I figured I'd post that info first.
>
> Phil:  Interesting, thanks for the info. Per your request, the ldd 
> command shows that the el repo drivers are functioning as intended for

> glxgears and the system in general:
>
> [224 root at system]ldd /usr/bin/glxgears | grep libGL
>          libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x0000003953800000)
>          libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 
> (0x0000003951600000)
>

As you note, all working correctly there.

> I did try the above on a few other applications (firefox, glchess,
> baobab) but either they weren't dynamic executables or didn't contain 
> any links to libGL.so.1. I also wasn't able to get a clear result from

> the above in regards to Ansys Mechanical as it isn't clear exactly how

> it's launched when the user double-clicks on a results cell. I tried a

> few binaries within the installation directory, but either they too 
> weren't dynamic executables or there's some other vendor-specific 
> voodoo at work as Ansys likes to launch their Windows .exe files on 
> Linux via mono. At any rate, I'm glad to see I was on the right track 
> and not really surprised to find that it's the fault of the
application.
> Unfortunately, I'm in the same boat as Steve in that it probably won't

> do much good for me to ask the developers of the app to fix the 
> linking issue. I'll probably have to decide if it's easier for me to 
> create a script that fixes the link after each kernel upgrade or go 
> back to the nvidia.com drivers and explore installing them with the 
> --dkms option so DKMS will recreate the kernel modules for the
newly-installed kernel.
> Since neither of those options are under the scope of this list, I'll 
> consider this issue resolved as far as el repo is concerned.
>

The package that installs the libGL library is mesa-libGL. So you'd only
need to reapply your fix in the event of this package being updated
(nothing to do with the kernel). It should be pretty obvious as your
users will no doubt report their application is broken again! Looking at
the changelog on my RHEL5 system (sorry, I don't have a RHEL6 install
with Xorg to hand), it's not a package that gets updated that
frequently.

Thus I would apply your workaround of manually creating the required
symlink and make a note you'll need to reply it after any updates to
mesa-libGL (most likely at any major point releases).

If the issue affects a lot of machines then look to a way to script /
automate that process.

> Steve:  Thanks for the post re: Puppet. I'll take a look at that as a 
> possible option going forward.
>
> Thanks again for the support on this issue and for the el repo project

> in general!
>
>
> Evan
>


WILLIAMS INTERNATIONAL                                  THE POWER OF VISION     

This email message and any attachment(s) are for the sole use of the intended
recipient(s) and may contain proprietary and/or confidential information which may
be privileged or otherwise protected from disclosure.

Any unauthorized review, use, disclosure or distribution is prohibited. If you are
not the intended recipient(s), please contact the sender by reply email and destroy
the original message and any copies of the message as well as any attachment(s)
to the original message.

This email message does not form a binding contract or contract amendment with
the sender, unless it clearly states in writing that it is a contract or contract amendment.