NVIDIA has released a beta of their CUDA development environment, although only Red Hat is officially supported, it would be great if Gentoo had an ebuild for it. Reproducible: Always Steps to Reproduce:
So that URL doesn't get missed: http://developer.nvidia.com/cuda
Just a note: The official 1.0 release is now out.
Created attachment 130448 [details] CUDA ebuild I wrote ebuild which installs and configures CUDA (sets a file in /etc/env.d) This is my first ebuild so I guess there is a room for improvement. I will add doc flag soon. Hope it helps someone. :)
Created attachment 138597 [details] CUDA 1.1 ebuild
I created a 1.1 version of the ebuild from the 1.0 ebuild. Hopefully somebody with more experience making ebuilds will take the time to fix it up?
(In reply to comment #5) > I created a 1.1 version of the ebuild from the 1.0 ebuild. Hopefully somebody > with more experience making ebuilds will take the time to fix it up? > Why did you choose the SuSE package? There is a generic package: http://developer.download.nvidia.com/compute/cuda/1_1/Linux/sdk/NVIDIA_CUDA_SDK_1.1_Linux.run which might be better. Also, I think CUDA requires the new nvidia driver a runtime?
CUDA Toolkit != CUDA SDK
(In reply to comment #6) > Also, I think CUDA requires the new nvidia driver a runtime? It does. I made an ebuild for that too but it doesn't do everything correctly. Specifically, it doesn't install the CUDA portion which is necessary here. I ended up manually installing the driver. So I'll revise my earlier statement, it would be nice if somebody would fix up the nvidia-cuda-1.1.ebuild and make a nvidia-drivers-169.04.ebuild that properly installs all the required components. I'm not the best person for that job.
the nvidia code examples expect cuda to be installed in /usr/local/cuda instead of /opt/cuda. is there any reason we shouldn't just use /usr/local/cuda?
Bug #199671 has an ebuild for the driver. I just tested it (bumped to 169.07) and the cuda-1.1 ebuild on my system here (previously had installed the toolkit by hand). Everything works perfectly. I'm no ebuild guru to know what needs to be done to clean up the cuda ebuild completely. Certainly, it will need to be setup to use a different install file on x86 machines. Given that one can install the toolkit and compile code in emulation mode, I wouldn't add a dependency to the driver. Instead, perhaps a warning should be included notifying the user that they will need this particular driver version (or newer) to run code on the device.
Created attachment 157285 [details] amd64/x86 Nvidia Cuda 1.1 Ebuild This ebuild is based on attachment 138597 [details]. It allows both amd64 and x86 to install the library, and makes use of the existing .run unpack procedure to extract the files. I've also added the build time dependency on dev-lang/perl. To finish this ebuild off it will need a suitable license (check the license, see if there's already one in /usr/portage/licenses, if so use that, if not attach it to this bug), it'll need any further/runtime dependencies checking and possibly a pkg_postinst einfo message saying that they'll need the driver in order to get any proper speed out of their code...
To any potential user, the ebuild is not supposed to be stored in dev-utils/cuda but dev-util/nvidia-cuda. Portage complains (ebuild nvidia-cuda-1.1.ebuild digest) otherwise. I have also issues regarding the downloading of the CDK. Has its location changed? paris nvidia-cuda # ebuild nvidia-cuda-1.1.ebuild digest >>> Downloading 'ftp://trumpetti.atm.tut.fi/gentoo/distfiles/NVIDIA_CUDA_Toolkit_1.1_Suse10.2_x86_64.run' --2008-07-16 10:43:41-- ftp://trumpetti.atm.tut.fi/gentoo/distfiles/NVIDIA_CUDA_Toolkit_1.1_Suse10.2_x86_64.run => `/home/root/distfiles/NVIDIA_CUDA_Toolkit_1.1_Suse10.2_x86_64.run' Resolving trumpetti.atm.tut.fi... 130.230.54.100, 2001:708:310:54::2 Connecting to trumpetti.atm.tut.fi|130.230.54.100|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD /gentoo/distfiles ... done. ==> SIZE NVIDIA_CUDA_Toolkit_1.1_Suse10.2_x86_64.run ... done. ==> PASV ... done. ==> RETR NVIDIA_CUDA_Toolkit_1.1_Suse10.2_x86_64.run ... No such file `NVIDIA_CUDA_Toolkit_1.1_Suse10.2_x86_64.run'. >>> Downloading 'http://gentoo.osuosl.org/distfiles/NVIDIA_CUDA_Toolkit_1.1_Suse10.2_x86_64.run' --2008-07-16 10:43:41-- http://gentoo.osuosl.org/distfiles/NVIDIA_CUDA_Toolkit_1.1_Suse10.2_x86_64.run Resolving gentoo.osuosl.org... 64.50.236.52, 64.50.238.52 Connecting to gentoo.osuosl.org|64.50.236.52|:80...
Daniel, the ebuild initially attempts to download the sources from Gentoo mirrors, and if those fail then it will attempt the original source location listed in SRC_URI. Since this isn't an official ebuild, the sources haven't been copied to the Gentoo mirrors, and so they'll all fail (you can tell a gentoo mirror address, because it tends to feature the words gentoo and distfiles in the URL, as yours both do). If you wait until all those have failed, it'll eventually try and download it from the right place. If you really have no patience you can add RESTRICT="mirror" to the ebuild. This will cause it not to try the Gentoo mirrors first, but go directly to the addresses listed in the ebuild. In general, this doesn't get added to testing ebuilds in case it gets forgotten and left in when the ebuild gets added to the tree. Hope that helps... 5:)
Hi! Thanks for the change in the title. It's dev-util though, not dev-utils (the final 's' was also a mistake). Something else, I read _very quickly_ the README file for the Cuda SDK (The one for Suse 10.2, considering that it is the one considered in this ebuild) and it says so: "CUDA and its libraries are compiled with gcc 3.4.5 and the same tools should be used on other distributions. Alternatively, compatibility packages containing libstdc++.so.6 may be used. These are available for many Linux distributions. For example, on recent Fedora Core releases, the compat-libstdc++-34 is needed." Shouldn't this be reflected in the ebuild? BTW, Shouldn't there be any reference to the necessary nvidia-drivers? Daniel
Hi! > Daniel, the ebuild initially attempts to download the sources from Gentoo > mirrors, and if those fail then it will attempt the original source location > listed in SRC_URI. Since this isn't an official ebuild, the sources haven't > been copied to the Gentoo mirrors, and so they'll all fail (you can tell a > gentoo mirror address, because it tends to feature the words gentoo and > distfiles in the URL, as yours both do). If you wait until all those have > failed, it'll eventually try and download it from the right place. OK d'OK.... My mistake. Thanks for the info... ;) Daniel
Daniel, see comment 8 as to why the nvidia-drivers aren't a requirement. Technically someone could just use their machine to compile the code, but not actually need the nvidia-driver because the code won't be run on that machine (for example, for distcc). Possibly, if it seems that's not a wise decision, it'll change, but at the moment this is very much an ebuild in development. As to the stdc++ libraries, good catch, they probably are a requirement. I haven't actually built anything with cuda yet, so I've no idea of its actual dependencies. They should be pretty easy to add in sometime. Remind me if I haven't posted a new ebuild in a couple of weeks... 5:)
(In reply to comment #16) > As to the stdc++ libraries, good catch, they probably are a requirement. I > haven't actually built anything with cuda yet, so I've no idea of its actual > dependencies. They should be pretty easy to add in sometime. Remind me if I > haven't posted a new ebuild in a couple of weeks... 5:) > I don't know how picky the requirements technically are, but I've been doing active CUDA development for the past year now (with the original ebuild posted) and haven't noticed any problems despite running gcc 4.1.2 (vs the 3.4.5 in the SUSE 10.2 build). However, none of the CUDA 1.1 distributions work with gcc 4.2, so there should be some kind of check there. The soon to be released CUDA 2.0 (currently in beta) will be support some distributions that use gcc 4.2. I don't know about 4.3. I'm certainly willing to test and find working configurations if it would help.
Created attachment 163369 [details] CUDA 2.0
(In reply to comment #17) > However, none of the CUDA 1.1 distributions work with gcc 4.2, so there should > be some kind of check there. The soon to be released CUDA 2.0 (currently in > beta) will be support some distributions that use gcc 4.2. I don't know about > 4.3. I'm certainly willing to test and find working configurations if it would > help. CUDA 2.0 was released last friday. I have successfully installed and run it on Xeon E5420 with gcc-4.3.1-r1 (despite it's not supported) and gentoo-sources-2.6.25-r7. I have modified ebuild 1.1 by correcting SRC_URI and adding "drivers" flag.
I think it will hit the tree faster if we let nvidia-drivers maintainer know about this bug :)
(In reply to comment #20) > I think it will hit the tree faster if we let nvidia-drivers maintainer know > about this bug :) > Might have a point there!. Good work, looks promising ! I'll have a further look into it this evening after I come back home.
Created attachment 166102 [details] revised cuda toolkit 2.0 ebuild
I'm successfully using this modified cuda-2.0 ebuild with gcc 4.1.2 and nvidia-drivers-177.70 on both x86 and amd64. The biggest change was to explicitly install the files, rather than running NVIDIA's Perl script, which does too much (tries to remove older versions) yet not enough (doesn't compress man pages.) I also slotted it, in case someone wants to write an eselect module or something. I removed the "driver" use flag, as it didn't seem useful. You don't need the driver (or even a card) to use the toolkit, as it includes an emulated GPU. OTOH, if you do have an NVIDIA card, you've likely already installed the driver. Finally, I changed the package name to "nvidia-cuda-toolkit" to avoid confusion with the SDK and driver (ala comment #6). I may yet make a nvidia-cuda-sdk ebuild.
May I suggest to install the files to /usr/local/cuda where everyone expects them to be. Also I think slotting is not really necessary since CUDA 2.0 came to stay.
(In reply to comment #24) > May I suggest to install the files to /usr/local/cuda where everyone expects > them to be. Also I think slotting is not really necessary since CUDA 2.0 came > to stay. > The file structure inside the package doesn't mesh with standards for what goes in /usr/local, which includes the standard shared bin/ lib/ include/ share/ ... NVIDIA's CUDA package is setup with standards consistent with /opt (/opt/cuda/bin /opt/cuda/include /opt/cuda/doc...) which I assume is why the original ebuild put it there. Major restructuring of the file structure to fit it into /usr/local will only make things less standard and even harder to find. As far as my vote counts, CUDA doesn't need to be slotted. You've got to re-emerge older drivers for CUDA 1.1 to work anyways, so there really is no need/want to have multiple CUDA versions on the same system. Plus it makes them harder to find.....
RESTRICT="strip" should be RESTRICT="strip mirror" so we don't cycle through the Gentoo mirrors.
Created attachment 168796 [details] non-slotted ebuild
(From comment #25) > As far as my vote counts, CUDA doesn't need to be slotted. You've got to > re-emerge older drivers for CUDA 1.1 to work anyways, so there really is no > need/want to have multiple CUDA versions on the same system. Plus it makes them > harder to find..... I think CUDA 1.1 could be used with its emulated GPU, so it's not strictly necessary to use the older drivers. I don't care about slotting either way. I figured that someone with old 1.1 code might find it useful. If 2.0 is a proper superset of 1.1 then it's not necessary, obviously. (Note that I don't use CUDA-- I just install it for my users, and they generally get tetchy about removing older versions of packages.) I've attached a non-slotted version with the RESTRICT change mentioned in comment #26.
Added with minor changes as dev-util/nvidia-cuda-toolkit. dev-util/nvidia-cuda-sdk will follow shortly. Thanks to everyone who contributed to the discussion or submitted ebuilds :)
