Skip to content
This repository has been archived by the owner on Jan 22, 2024. It is now read-only.

Split cuda image into cuda-runtime and cuda-devel #14

Closed
wants to merge 1 commit into from
Closed

Split cuda image into cuda-runtime and cuda-devel #14

wants to merge 1 commit into from

Conversation

flx42
Copy link
Member

@flx42 flx42 commented Nov 20, 2015

Fixes: #12

Submitting this one for review by @3XX0 and @ruffsl since it touches almost every file in the repository.
Now we have two flavors of each CUDA toolkit: cuda-runtime and cuda-devel.

  • cuda-runtime only contains the CUDA shared libraries. If you want to use a pre-built package of a project (e.g. a binary or a pip package), then it should work fine.
  • cuda-devel adds the header files, static CUDA libraries, the compiler toolchain, the debugging tools.
    For convenience, this image should be tagged cuda by users. This image doesn't include documentation, samples and visual tools; thus the image is still significantly smaller than the previous cuda image.

Here are the size of the images right now:

REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
cuda-devel          7.0                 8c9f67f29ae9        15 minutes ago      1.194 GB
cuda-runtime        7.0                 2ad0a2582ca9        19 minutes ago      539.6 MB
cuda-devel          6.5                 cb3358301dbd        24 minutes ago      1.012 GB
cuda-runtime        6.5                 9754b1ebf287        26 minutes ago      428.9 MB
cuda-devel          7.5                 2cb11b823f01        31 minutes ago      1.223 GB
cuda-runtime        7.5                 376f27b3595d        34 minutes ago      561.7 MB
ubuntu              14.04               e9ae3c220b23        10 days ago         187.9 MB

@ruffsl
Copy link
Contributor

ruffsl commented Nov 20, 2015

So, you'd want to make a separate repository for cuda-devel vs cuda-runtime?
I was thinking you could split that by a tag to just reduce the fragmentation:

Supported tags and respective Dockerfile links

Keep in mind where you'd want to attach the cudnn image later though, whether it be a tag or repo in itself. Perhaps 7.0-cudnn could be FROM cuda:7.0-runtime, and folks who want devel + cudnn just rebuild devel pointing to it? Although I see a lot projects using cudnn are normally distributed via building from source, so I'm not sure.

@flx42
Copy link
Member Author

flx42 commented Nov 20, 2015

I don't want to commit to a particular layout or tag strategy for the Docker Hub just yet. If we had done so already we will be in even more trouble right now since we are changing everything. I expect this will happen again one or multiple times.
Without considering the Docker Hub, I think the current layout makes sense and avoid having too many folder indirections.
But in the end, I don't expect us to have separate repositories for cuda-devel and cuda-runtime or even for cudnn, I don't think that's a frequent approach.

@ruffsl
Copy link
Contributor

ruffsl commented Nov 20, 2015

Well, either way @flx42 , the number of leaf folders made is the same: 2x3=3x2. I'm just thinking you may want to structure by os->v#->app. Its common to see most tag structures set version number as the prefix, and instance specifics as the postfix. You could play around with other tag conventions, but it could get a little verbose. Can't hurt to have the folder tree structure mimic the branching tag hierarchy.

Playing devils advocate, @3XX0, what would be some cases for the opposite (for a cuDNN repo)?

@3XX0
Copy link
Member

3XX0 commented Nov 20, 2015

I was following our package convention (i.e cuda-X-version) but either way is fine.
Not sure what's the official way of doing it

@ruffsl
Copy link
Contributor

ruffsl commented Nov 21, 2015

@3XX0 , what you've described looks great, I am in agreement. I like the flexibility offered to users by making both a runtime and devel version of cuDNN, and the pattern of tag aliases is very clear. It's ok it have a good amount of tags, as the build process is automated, maintenance is quite low once we get it down, and it lets users a pick what the need.

Just looked through b45091a and it LGTM! One suggestion is that perhaps you'd want to create a simple Makefile to build, tag, pull, rm all the growing number of tags, like this Makefile. They are quite simple, and users can quickly mod it as needed.

Oh, and @flx42 , as long as your touching every Dockerfile, you might want to reorder the packages in the apt-get install alphabetically, but that's just me being OCD.

@flx42 flx42 closed this in fe36ee3 Nov 21, 2015
@flx42 flx42 deleted the split_cuda_image branch November 21, 2015 02:12
@ruffsl
Copy link
Contributor

ruffsl commented Dec 3, 2015

@3XX0 , if you updated those links point to their respective Dockerfiles, I believe that bullet markdown list would be a useful addition to the beginning of this repo's README.md.

@3XX0
Copy link
Member

3XX0 commented Dec 3, 2015

Yes, we're going to update all the documentation fairly soon.
In the meantime I put it on the HUB documentation: https://hub.docker.com/r/nvidia/cuda/

@ruffsl
Copy link
Contributor

ruffsl commented Dec 3, 2015

I think if you make that repo automated, you could have it render documentation on the docker-repo page using the README.md from the git-repo. See Understand the build process.

@flx42
Copy link
Member Author

flx42 commented Dec 4, 2015

@ruffsl I added a Makefile like you suggested :)
next step is #18

@ruffsl
Copy link
Contributor

ruffsl commented Dec 4, 2015

That's a great Makefile , I think I might mimic it :D

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants