Bug#783770: Fwd: [Patch] Shall we update CUDA to 7.0.28 ? (#783770)
Hi doko, FYI CUDA 7.0.28-1 is currently queued in NEW. https://tracker.debian.org/pkg/nvidia-cuda-toolkit I plan to help updating cuda to 7.5 immediately after uploaded CUDA 7.0, because in my former simple cuda compiler tests, CUDA 7.0 still doesn't work well with GCC-5. (not working with gcc >> 4.10) CUDA 7.5 unblocks one of my ITP BUG and resolves its FTBFS. In a word I want to get CUDA 7.5 into Debian as soon as possible. So doko, if your work on GCC depends on a specific CUDA version (e.g. 7.0.*), please consider waiting for CUDA 7.5 . I think we'd better have a discussion with anbe, because I'm not familiar with nvidia packages upload schedule. To anbe: How do you think about this? Is it possible to bump CUDA version so fast? It seems that the nvidia driver blocks CUDA as its dependency, but, well, I can also offer help on corresponding packages if in need. Thank you all :-) On Thu, 2015-12-03 at 04:31 +0100, Matthias Klose wrote: > > any update on this? I'm interested to rely on this for some recent GCC > offloading technologies. > > Matthias >
Bug#783770: Fwd: [Patch] Shall we update CUDA to 7.0.28 ? (#783770)
On 2015-11-14 05:18, Andreas Beckmann wrote: > Therefore I've uploaded the current experimental cuda toolkit version to > sid, which will be uninstallable without a driver from experimental, but > that should clean in about a week once the current driver series > hopefully migrates to testing without any new bugs :-) and I can push it > to jessie-backports. Once that has happened, Went smoothly to testing, backports was uploaded, but is still queued. > sid will receive newer > drivers :-) Right, but first the new minor release for CVE-2015-7869 :-( (And I need to get this again back to oldstable ...) > So far I haven't tested it at all beyond building the package. Initial testing shows that the packaged CUDA 7.0 works for a project that no longer compiled wth 6.5 ... Andreas
Bug#783770: Fwd: [Patch] Shall we update CUDA to 7.0.28 ? (#783770)
Hi, On Sat, 2015-11-14 at 05:18 +0100, Andreas Beckmann wrote: > [ dropping debian-devel@ ] > > Thanks for your patches. > I've started integrating them into svn :-) Thank you for accepting them :-) > Therefore I've uploaded the current experimental cuda toolkit version to > sid, which will be uninstallable without a driver from experimental, but > that should clean in about a week once the current driver series > hopefully migrates to testing without any new bugs :-) and I can push it > to jessie-backports. Once that has happened, sid will receive newer > drivers :-) OK, I'll start importing CUDA 7.5 then. > most of your todo list is solved: Thank you for solving them ;-) > + * [more or less done] update get-orig-source in d/rules > + * [todo] update watch / watch.in I noticed that the watch.in from the current svn trunk works correctly. > + * [todo] check the compatible gcc version > +- d/rules: 's/__GNUC_MINOR__ > 8/__GNUC_MINOR__ > 9/' > + * [todo] check --list-missing for missing docs. According to my observation, nvcc 7.0.27 (from CUDA 7.0.28) refuses to work with gcc >= 4.10 , and it really works with gcc-4.9 . > also check whether we needed anything uninstalled from these directories: > usr/share/gdb/ > usr/extras/Debugger/ Following is copied from CUDA 7.0's release notes: (http://developer.download.nvidia.com/compute/cuda/7_0/Prod/doc/CUDA_Toolkit_Release_Notes.pdf) ``` CUDA-GDB Sources CUDA-GDB sources are available as follows: ‣ For CUDA Toolkit 7.0 and newer, in the installation directory extras/. The directory is created by default during the toolkit installation unless the .rpm/.deb package installers are used. In this case, the cuda-gdb-src package must be manually installed. ‣ For CUDA Toolkit 6.5, 6.0, and 5.5, at https://github.com/NVIDIA/cuda-gdb. ‣ For CUDA Toolkit 5.0 and earlier, at ftp://download.nvidia.com/CUDAOpen64/. ‣ Upon request by sending an e-mail to mailto:oss-reque...@nvidia.com. ``` Maybe we should add a new package named nvidia-cuda-gdb-src ? > do we need the libraries in stubs/ ? Exactly I don't know what they are used for ... By the name I guess they are used to stub the GPU. Let's provide a libcuda-stubs package? > Lintian reports several privacy-breach-generic in nsight and nvvp, > these probably need similar handling like we already do for -doc ... > > So far I haven't tested it at all beyond building the package. The trunk packaging files passes the build on my sid. I'm just an amateur at CUDA so I don't know how to test CUDA except for the nvidia compilers. Thanks.
Bug#783770: Fwd: [Patch] Shall we update CUDA to 7.0.28 ? (#783770)
[ dropping debian-devel@ ] On 2015-11-13 16:08, lumin wrote: > On Fri, 2015-11-13 at 15:21 +0100, Samuel Thibault wrote: >> Thanks for your contribution that will hopefully help getting cuda 7.0 >> or 7.5 packages out faster. > > I do hope so. :-) Thanks for your patches. I've started integrating them into svn :-) Therefore I've uploaded the current experimental cuda toolkit version to sid, which will be uninstallable without a driver from experimental, but that should clean in about a week once the current driver series hopefully migrates to testing without any new bugs :-) and I can push it to jessie-backports. Once that has happened, sid will receive newer drivers :-) most of your todo list is solved: + * [done] comment manpage patches out. ++ [done] solve a pile of lintianW on manpages + * [todo] update watch / watch.in + * [done] update CUDA_VERSION_DRIVER in rules.def + * [done] remove nvopencc-related stuff + * [done] remove libcuinj32-related stuff + * [done] update copyright with new EULA + * [more or less done] update get-orig-source in d/rules + * [todo] check the compatible gcc version +- d/rules: 's/__GNUC_MINOR__ > 8/__GNUC_MINOR__ > 9/' + * [todo] check --list-missing for missing docs. also check whether we needed anything uninstalled from these directories: usr/share/gdb/ usr/extras/Debugger/ do we need the libraries in stubs/ ? Lintian reports several privacy-breach-generic in nsight and nvvp, these probably need similar handling like we already do for -doc ... So far I haven't tested it at all beyond building the package. Andreas
Bug#783770: Fwd: [Patch] Shall we update CUDA to 7.0.28 ? (#783770)
Hi,
On Fri, 2015-11-13 at 15:21 +0100, Samuel Thibault wrote:
> Thanks for your contribution that will hopefully help getting cuda 7.0
> or 7.5 packages out faster.
I do hope so. :-)
> > FYI: As far as I know, in my experiments,
> > a Tesla K20C GPU works 5+ times faster than an Intel Xeon W3690.
>
> That's not a reason for rushing to CUDA 7.0 or later. A K20C will work
> fine with CUDA 6.5. Also, helping free software to support NVIDIA GPUs
> would help avoiding the issue :)
Well, I mean Caffe could work without CUDA but it is slow, so in order
to boost Caffe up I need a set of working build-deps, i.e.
we should import CUDA 7.5, which should be OK working with GCC-5.
> I guess there is no way to backport the CUDA 7.5 fixes to support GCC-5?
> (damn the non-free software...)
I think there is nearly no way doing so, even if we know what to change
to backport GCC-5 support into CUDA 7.0. That's because the CUDA's EULA
FORBIDS ANY KIND OF MODIFICATION, e.g. strip'ing the huge ELFs...
So
> Urgl, so CUDA 7.0 is not even enough?
>
> I guess we may want to skip 7.0 and directly upload 7.5.
Yes, NVCC 7.0.27 (shipped in CUDA 7.0.28, the version number is correct)
still complains about G{CC,++} >> 4.10. That means CUDA 7.0 refuses to
work with GCC-5 in my case.
So can we skip CUDA 7.0 ?
If that's OK, then I'll be glad to get CUDA 7.5 and
import&build&test it again.
> So yes, the answer is: "please be patient, we are working on it. Help is
> welcome".
I plan to take care of this package for some time.
Thank you for comment :-)
--
.''`. Lumin
: :' :
`. `'
`-638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A
signature.asc
Description: This is a digitally signed message part
Bug#783770: Fwd: [Patch] Shall we update CUDA to 7.0.28 ? (#783770)
Hello,
My few cents about it:
lumin, on Fri 13 Nov 2015 13:55:52 +, wrote:
> Debian's CUDA/experimental is QUITE OUT OF DATE so that
> it fails to work with GCC-5.
It's cuda 6.5. Cuda 7.0 is not *that* new. AIUI, it was officially
released by Nvidia in March 2015.
Yes, the push to gcc-5 posed a lot of problems, CUDA is one of
them. That's actually exactly why I make the starpu-contrib package
build-depend on older versions of gcc instead of the default version of
gcc.
> but I don't understand why Debian experimental holds such an
> .. 6.5 version, compared with the one Archlinux ships.
[...]
> Following is my dch, and you can see there are still some items remained to be
> done:
You named it :)
Thanks for your contribution that will hopefully help getting cuda 7.0
or 7.5 packages out faster.
> FYI: As far as I know, in my experiments,
> a Tesla K20C GPU works 5+ times faster than an Intel Xeon W3690.
That's not a reason for rushing to CUDA 7.0 or later. A K20C will work
fine with CUDA 6.5. Also, helping free software to support NVIDIA GPUs
would help avoiding the issue :)
> I'm afraid that I have to bump CUDA to 7.5, to solve the FTBFS of Caffe.
> which really fixes CUDA's attitude towards GCC-5.
I guess there is no way to backport the CUDA 7.5 fixes to support GCC-5?
(damn the non-free software...)
> What makes me happy is, the compilation for gcc-4.9 on *.cu files
> of Caffe runs well. CUDA-7.0.28 supports up to g{cc,++}-4.9, but
> still not working with g{cc,++}-5.
Urgl, so CUDA 7.0 is not even enough?
I guess we may want to skip 7.0 and directly upload 7.5.
> The caffe builds failed because liking ELFs to v5libs with g{cc,++}-4.9,
> so it matches my expectation.
Ok, so your case is indeed completely screwed for now, due to the
unfortunate combination of libstdc++ transition, late release of gcc-5,
and thus late support of gcc-5 in CUDA (a couple of months ago only).
That's basically a "flag day^Wmonth" issue.
So yes, the answer is: "please be patient, we are working on it. Help is
welcome".
Samuel
