Comments (8)
Yes, that's very reasonable.
from cudart.jl.
Ah, turns out I only have CUDA 7.0, so I think I can't do that. I don't see any obvious way you accounted for multiple versions, is there?
from cudart.jl.
I think we can support multiple "gen" directories (it might take a bit of tweaking of the core code, but that part should be pretty easy). Start by making a gen-7.0
folder, copying the wrap_cuda.jl
script from the 6.5 directory, and run it. (You'll need to install Clang.) It's a bit of a pain to get this set up (you need to build Julia with Clang support, if you don't have it already), but once all the parts are there it was (for 6.5) entirely automagic.
from cudart.jl.
OK I'll try that but It'll take me some time before I get there then, quite busy currently.
from cudart.jl.
I believe I've generated the bindings (for 7.5, not 7.0, I was mistaken) but I am clueless as to how we should decide which one to include here and here. Any ideas or pointers?
Also, even if I generate bindings for 7.5 and can load and use them, we should also apply this fix to the 6.5 folder so that both bindings behave the same. But I don't know how to generate them given I don't have cuda 6.5. I don't think I can easily install multiple cuda versions in Arch linux because it gets installed to /opt/cuda/...
without version number in the path.
from cudart.jl.
I believe I've generated the bindings (for 7.5
Nice!
Probably the best choice is to do the check in deps/build.jl
, and encode the proper path in a deps/deps.jl
file. ImageMagick.jl has an example of the kind of logic that would likely be useful.
Also, even if I generate bindings for 7.5 and can load and use them, we should also apply this fix to the 6.5 folder
I volunteer to make that change to the 6.5 folder and test it.
from cudart.jl.
How about running wrap_cuda.jl
during build, is that a bad idea?
Otherwise, how would you go about finding out the installed CUDA version? Parsing the output of nvcc -V
sounds wrong and brittle. I don't think BinDeps
is the right thing here, because a lot of people install CUDA manually.
Maybe it's best to move this or similar to build-time and then call one of these two manually.
But do we expect people to re-run Pkg.build("CUDArt")
manually when they update CUDA? I'm sure many won't, I'd probably forget myself. Though we could detect that by saving the "built version" and checking the current version on module load.
Sorry for so many questions, it's the first time I do this
from cudart.jl.
How about running wrap_cuda.jl during build, is that a bad idea?
Yes, because most people won't have Clang.jl installed and working.
CUDA library versioning doesn't seem to have been a big problem so far, I'd say.
Maybe it's best to move this or similar to build-time and then call one of these two manually.
Seems reasonable.
But do we expect people to re-run Pkg.build("CUDArt") manually when they update CUDA? I'm sure many won't, I'd probably forget myself. Though we could detect that by saving the "built version" and checking the current version on module load.
I think it's OK to expect people to do a little manual work when they update CUDA. Furthermore, if they don't, but nothing breaks, I wouldn't classify that as a problem. Most of the CUDA API has been pretty stable over many releases, so I don't think it's a catastrophe to get the version wrong.
from cudart.jl.
Related Issues (20)
- Tests fail on Windows with 0.6 HOT 1
- Info about upcoming removal of packages in the General registry
- Support for ptx modules with external functions HOT 2
- Does CUDArt support cuda 8.0? HOT 1
- triggering gc based on gpu memory
- CUDArt assumptions not robust
- Precompile Error HOT 1
- Intermittent GC-related test failure (`isempty(cuda_ptrs)`) HOT 2
- New tag HOT 2
- Updated build script for visual studio 17 but get compile errors HOT 2
- error could not load library "libnvidia-ml" HOT 4
- Makefile needs to select correct gcc compiler HOT 1
- Rename types to CuArray, CuMatrix and so forth for consistency with CUDAdrv?
- CUDArt should not rely on `nvidia-smi` or `nvml` on Mac OSX HOT 31
- CUDArt fails to build when no CUDA device is present
- gcc5.4.0 support HOT 1
- OOB during package build HOT 7
- No method matching reset(::Cudadrv.CuPrimaryContext) HOT 3
- GCC Version On CUDA 8.0 HOT 3
- Unified Memory support HOT 11
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cudart.jl.