[elrepo] nvidia-x11-drv and GLVND

Tue Aug 23 09:28:55 EDT 2016

Hello,

Running the NIVDIA downloaded .run file with default options has installed the GLVND versions of the libraries since 364.12 but the nvidia-x11-drv installs the legacy versions currently. We build our own package here to enable it. I emailed Phil Perry about this yesterday and here is a copy of our conversation (he suggested rightly to move this to the mailing list for visibility).

This is the diff on the spec file to enable GLVND:

146d144
< %{__install} -p -m 0755 libGL.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/
181a180,181
> %{__install} -p -m 0755 libGL.so.1.0.0 $RPM_BUILD_ROOT%{nvidialibdir}/
> %{__install} -p -m 0755 libGLX.so.0 $RPM_BUILD_ROOT%{nvidialibdir}/
237,238c237,239
< %{__ln_s} libGL.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/libGL.so
< %{__ln_s} libGL.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/libGL.so.1
---
> %{__ln_s} libGL.so.1.0.0 $RPM_BUILD_ROOT%{nvidialibdir}/libGL.so
> %{__ln_s} libGL.so.1.0.0 $RPM_BUILD_ROOT%{nvidialibdir}/libGL.so.1
> %{__ln_s} libGLX.so.0 $RPM_BUILD_ROOT%{nvidialibdir}/libGLX.so

Harry Mallon.

---- copy of emails below ----

Harry Mallon

CODEX | Software Engineer

60 Poland Street | London | England | W1F 7NT

E harry at codexdigital.com<mailto:harry at codexdigital.com> | T +44 203 7000 989<callto:+44%20203%207000%20989>

Website<www.codexdigital.com> | Facebook<https://www.facebook.com/codexdigital> | Twitter<http://twitter.com/codexdigital>

[http://www.codexdigital.com/?action=asset&id=E55D8A6F-AF62-4978-8FF1-435A85AFADBF]<http://www.codexdigital.com>

On 22/08/16 22:14, Phil Perry wrote:

Answering some of my own questions (inline)

On 22/08/16 13:09, Harry Mallon wrote:
Hi Phil,

Sorry to email out of the blue. We are repackaging nvidia-x11-drv with
GLVND support here for CentOS7 based on the ELREPO version. Is there a
plan to make a derivative version available with this support by
default? We would be happy to look into helping out in any way
possible (we have a working spec which could be altered to make
conflicting derivatives nvidia-x11-drv and nvidia-x11-drv-glvnd maybe?).

Thanks for your time (and work on these RPMs),

Harry Mallon

Harry Mallon
CODEX | Software Engineer
60 Poland Street | London | England | W1F 7NT
E harry at codexdigital.com<mailto:harry at codexdigital.com> | T +44 203 7000 989

Hi Harry,

Many thanks for your email.

When nvidia first released the 361.xx series driver adding GLVND
support, my point of reference was this article:

https://devtalk.nvidia.com/default/topic/915640/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/

I think there were a few compatibility issues with the initial beta
releases where GLVND support was enabled by default, so for the 361.28
driver release they reverted to installing a non-GLVND driver by default.

At the time, and given the Enterprise nature of our supported platform,
we thought it best to also stick with the non-GLVND option. Our
rationale is always if someone wants cutting edge then they should
probably be running Fedora.

But time is moving on, and since you appear to have a need, this seems
like the ideal opportunity to consider a GLVND release.

So we need to figure out the best way to implement this. Long term, I
would very much like to minimise the amount of work, so don't want to be
shipping multiple package sets if I can help it.

Question - do you know if the nvidia installer is now enabling GLVND by
default? This will probably be a key factor for us - I don't consider we
should be shipping a GLVND enabled package by default before nvidia is.

Nvidia enabled GLVND by default in 364.12, but advise distros to hold off packaging just yet:

https://devtalk.nvidia.com/default/topic/925605/linux/nvidia-364-12-release-vulkan-glvnd-drm-kms-and-eglstreams/

"The GLVND implementation is maturing. We shipped it experimentally starting in 361.16, and enabled it by default in 364.12 (it can still be disabled at install time, if desired). There has been a lot of interest, feedback, and contributions from Mesa developers and distribution packagers. Thanks! Based on recent feedback, we're about to make an ABI-breaking change to GLVND, which will hopefully make future ABI compatibility easier to manage. Distros should probably hold off on packaging the upstream GLVND until after that ABI change has settled."

In the release notes for 367.18 beta I note:

* Updated the libglvnd snapshot included in the NVIDIA driver package to libglvnd commit b7d75429677eecc00c3701aaa4deac1304bc51ff. This contains a new revision of the libglvnd ABI. The driver is not compatible with a libglvnd older than commit c5bcda3b848fe52d6ae6ef25c917431c06d62d27.

So what are our options - we could ship both in parallel for a period,
and then phase out the old non-GLVND packages over time. Or we could
ship a separate GLVND enabled sub-package (nvidia-x11-drv-glvnd as you
suggest). I'd like to think that one through.

IIRC, from the nvidia document above, we already ship all the GLVND libs
except the libGL.so lib which ships in two versions, so presumably the
only change we need to make to the SPEC file would be to switch to the
GLVND enabled libGL.so lib?

and libGLX.so.0

If you have a working SPEC, or first hand
knowledge of what needs changing in our SPEC then that would be helpful.

Alternatively, we could try doing something clever, and ship both
versions of the libGL.so lib in the same package, with one enabled by
default (maybe through a symlink), and write a switcher app to allow
users to switch back and forth for testing etc by switching to the
appropriate libGL.so lib and rebooting. I'm thinking of something like
the util Red Hat uses to switch between Postfix or Sendmail MTAs - it
could be a simple command line script.

As a matter of policy, I always try to only roll out major changes like
this in a new version release, so I wouldn't look to push any changes
out in the current 367.xx series. But we can use that as a driver base
for developing and testing our ideas ready for the next major release.

The other thing I would prefer to do is to hold any discussions in
public on our mailing list so everyone from the community has the
opportunity to see what we are thinking / developing, offer their input
and maybe also help test. To that end, if you are not already registered
it would be useful if you could register here:

http://lists.elrepo.org/mailman/listinfo/elrepo

The list is fairly low traffic so hopefully you will not find it
obtrusive. If you are happy, I could copy my reply to the list once
you're subscribed to get the discussion started.

Regards,

Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elrepo.org/pipermail/elrepo/attachments/20160823/cf12ca36/attachment.html>