<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hello,
<div class=""><br class="">
</div>
<div class="">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).</div>
<div class=""><br class="">
</div>
<div class="">This is the diff on the spec file to enable GLVND:</div>
<div class=""><br class="">
</div>
<div class=""><font face="Menlo" class="">146d144<br class="">
< %{__install} -p -m 0755 libGL.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/<br class="">
181a180,181<br class="">
> %{__install} -p -m 0755 libGL.so.1.0.0 $RPM_BUILD_ROOT%{nvidialibdir}/<br class="">
> %{__install} -p -m 0755 libGLX.so.0 $RPM_BUILD_ROOT%{nvidialibdir}/<br class="">
237,238c237,239<br class="">
< %{__ln_s} libGL.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/libGL.so<br class="">
< %{__ln_s} libGL.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/libGL.so.1<br class="">
---<br class="">
> %{__ln_s} libGL.so.1.0.0 $RPM_BUILD_ROOT%{nvidialibdir}/libGL.so<br class="">
> %{__ln_s} libGL.so.1.0.0 $RPM_BUILD_ROOT%{nvidialibdir}/libGL.so.1<br class="">
> %{__ln_s} libGLX.so.0 $RPM_BUILD_ROOT%{nvidialibdir}/libGLX.so</font></div>
<div class=""><br class="">
</div>
<div class="">Harry Mallon.</div>
<div class=""><br class="">
</div>
<div class="">---- copy of emails below ----</div>
<div class=""><br class="">
<p id="c1-id-6" style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; COLOR: #000; PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px 0px 2px; LINE-HEIGHT: 12pt; PADDING-RIGHT: 0px">
Harry Mallon</p>
<p id="c1-id-7" style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; COLOR: #000; PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px 0px 10px; LINE-HEIGHT: 12pt; PADDING-RIGHT: 0px">
CODEX | Software Engineer</p>
<p id="c1-id-8" style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px 0px 2px; LINE-HEIGHT: 12pt; PADDING-RIGHT: 0px">
<span id="c1-id-9" style="COLOR: gray">60 Poland Street</span> | <span id="c1-id-10" style="COLOR: gray">
London</span> | <span id="c1-id-11" style="COLOR: gray">England </span>| <span id="c1-id-12" style="COLOR: gray">
W1F 7NT </span></p>
<p id="c1-id-14" style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; COLOR: gray; PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px 0px 4px; LINE-HEIGHT: 12pt; PADDING-RIGHT: 0px">
E <a id="c1-id-15" style="TEXT-DECORATION: none; COLOR: gray" href="mailto:harry@codexdigital.com">
harry@codexdigital.com</a> <span id="c1-id-16" style="COLOR: #000">|</span> T <a id="c1-id-17" style="TEXT-DECORATION: none; COLOR: gray" href="callto:+44 203 7000 989">
+44 203 7000 989</a> </p>
<p style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px 0px 2px; LINE-HEIGHT: 12pt; PADDING-RIGHT: 0px">
<a title="Visit our website" style="TEXT-DECORATION: none; COLOR: gray" href="www.codexdigital.com">Website</a> |
<a title="Find us on Facebook" style="TEXT-DECORATION: none; COLOR: gray" href="https://www.facebook.com/codexdigital">
Facebook</a> | <a title="Follow us on Twitter" style="TEXT-DECORATION: none; COLOR: gray" href="http://twitter.com/codexdigital">
Twitter</a></p>
<p id="c1-id-22" style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; MARGIN-TOP: 15px"><a id="c1-id-23" title="See us at IBC!" style="BORDER-TOP-STYLE: none; BORDER-BOTTOM-STYLE: none; BORDER-RIGHT-STYLE: none; OUTLINE-STYLE: none; BORDER-LEFT-STYLE: none" href="http://www.codexdigital.com"><img id="c1-id-24" style="BORDER-TOP-STYLE: none; BORDER-BOTTOM-STYLE: none; BORDER-RIGHT-STYLE: none; OUTLINE-STYLE: none; BORDER-LEFT-STYLE: none" alt="" src="http://www.codexdigital.com/?action=asset&id=E55D8A6F-AF62-4978-8FF1-435A85AFADBF"></a></p>
</div>
<div class="">On 22/08/16 22:14, Phil Perry wrote:<br class="">
<br class="">
Answering some of my own questions (inline)<br class="">
<br class="">
<blockquote type="cite" class="">On 22/08/16 13:09, Harry Mallon wrote:<br class="">
<blockquote type="cite" class="">Hi Phil,<br class="">
<br class="">
Sorry to email out of the blue. We are repackaging nvidia-x11-drv with<br class="">
GLVND support here for CentOS7 based on the ELREPO version. Is there a<br class="">
plan to make a derivative version available with this support by<br class="">
default? We would be happy to look into helping out in any way<br class="">
possible (we have a working spec which could be altered to make<br class="">
conflicting derivatives nvidia-x11-drv and nvidia-x11-drv-glvnd maybe?).<br class="">
<br class="">
Thanks for your time (and work on these RPMs),<br class="">
<br class="">
Harry Mallon<br class="">
<br class="">
Harry Mallon<br class="">
CODEX | Software Engineer<br class="">
60 Poland Street | London | England | W1F 7NT<br class="">
E <a href="mailto:harry@codexdigital.com" class="">harry@codexdigital.com</a> | T +44 203 7000 989<br class="">
<br class="">
</blockquote>
<br class="">
Hi Harry,<br class="">
<br class="">
Many thanks for your email.<br class="">
<br class="">
When nvidia first released the 361.xx series driver adding GLVND<br class="">
support, my point of reference was this article:<br class="">
<br class="">
<a href="https://devtalk.nvidia.com/default/topic/915640/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/" class="">https://devtalk.nvidia.com/default/topic/915640/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/</a><br class="">
<br class="">
<br class="">
I think there were a few compatibility issues with the initial beta<br class="">
releases where GLVND support was enabled by default, so for the 361.28<br class="">
driver release they reverted to installing a non-GLVND driver by default.<br class="">
<br class="">
At the time, and given the Enterprise nature of our supported platform,<br class="">
we thought it best to also stick with the non-GLVND option. Our<br class="">
rationale is always if someone wants cutting edge then they should<br class="">
probably be running Fedora.<br class="">
<br class="">
But time is moving on, and since you appear to have a need, this seems<br class="">
like the ideal opportunity to consider a GLVND release.<br class="">
<br class="">
So we need to figure out the best way to implement this. Long term, I<br class="">
would very much like to minimise the amount of work, so don't want to be<br class="">
shipping multiple package sets if I can help it.<br class="">
<br class="">
Question - do you know if the nvidia installer is now enabling GLVND by<br class="">
default? This will probably be a key factor for us - I don't consider we<br class="">
should be shipping a GLVND enabled package by default before nvidia is.<br class="">
<br class="">
</blockquote>
<br class="">
Nvidia enabled GLVND by default in 364.12, but advise distros to hold off packaging just yet:<br class="">
<br class="">
<a href="https://devtalk.nvidia.com/default/topic/925605/linux/nvidia-364-12-release-vulkan-glvnd-drm-kms-and-eglstreams/" class="">https://devtalk.nvidia.com/default/topic/925605/linux/nvidia-364-12-release-vulkan-glvnd-drm-kms-and-eglstreams/</a><br class="">
<br class="">
"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."<br class="">
<br class="">
In the release notes for 367.18 beta I note:<br class="">
<br class="">
* 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.<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">So what are our options - we could ship both in parallel for a period,<br class="">
and then phase out the old non-GLVND packages over time. Or we could<br class="">
ship a separate GLVND enabled sub-package (nvidia-x11-drv-glvnd as you<br class="">
suggest). I'd like to think that one through.<br class="">
<br class="">
IIRC, from the nvidia document above, we already ship all the GLVND libs<br class="">
except the libGL.so lib which ships in two versions, so presumably the<br class="">
only change we need to make to the SPEC file would be to switch to the<br class="">
GLVND enabled libGL.so lib?<br class="">
</blockquote>
<br class="">
and libGLX.so.0<br class="">
<br class="">
<blockquote type="cite" class="">If you have a working SPEC, or first hand<br class="">
knowledge of what needs changing in our SPEC then that would be helpful.<br class="">
<br class="">
Alternatively, we could try doing something clever, and ship both<br class="">
versions of the libGL.so lib in the same package, with one enabled by<br class="">
default (maybe through a symlink), and write a switcher app to allow<br class="">
users to switch back and forth for testing etc by switching to the<br class="">
appropriate libGL.so lib and rebooting. I'm thinking of something like<br class="">
the util Red Hat uses to switch between Postfix or Sendmail MTAs - it<br class="">
could be a simple command line script.<br class="">
<br class="">
As a matter of policy, I always try to only roll out major changes like<br class="">
this in a new version release, so I wouldn't look to push any changes<br class="">
out in the current 367.xx series. But we can use that as a driver base<br class="">
for developing and testing our ideas ready for the next major release.<br class="">
<br class="">
The other thing I would prefer to do is to hold any discussions in<br class="">
public on our mailing list so everyone from the community has the<br class="">
opportunity to see what we are thinking / developing, offer their input<br class="">
and maybe also help test. To that end, if you are not already registered<br class="">
it would be useful if you could register here:<br class="">
<br class="">
<a href="http://lists.elrepo.org/mailman/listinfo/elrepo" class="">http://lists.elrepo.org/mailman/listinfo/elrepo</a><br class="">
<br class="">
The list is fairly low traffic so hopefully you will not find it<br class="">
obtrusive. If you are happy, I could copy my reply to the list once<br class="">
you're subscribed to get the discussion started.<br class="">
<br class="">
<br class="">
Regards,<br class="">
<br class="">
Phil</blockquote>
</div>
</body>
</html>