juliaattic / cudnn.jl Goto Github PK

it still talks about tensor and filter types...

CUDNN downgrades CUDAapi to 0.2.1, CUDAdrv to 0.6.1, and CUDAnative to 0.5.3. Now CUDAnative cannot pass the test. A fix might be needed here. JuliaGPU/CUDAnative.jl#144

Hello there,

I understand this package is no longer maintained.

If you happen to see this message and know of any updated wrapper for cudnn, would you please let me know?

All the best,
Marc

Hi Deniz,

If you click the "settings" button, then under "Danger Zone" you'll find "Transfer ownership." You should be able to transfer to JuliaGPU; I see you're already an owner for that organization.

As described in https://discourse.julialang.org/t/ann-plans-for-removing-packages-that-do-not-yet-support-1-0-from-the-general-registry/ we are planning on removing packages that do not support 1.0 from the General registry. This package has been detected to not support 1.0 and is thus slated to be removed. The removal of packages from the registry will happen approximately a month after this issue is open.

To transition to the new Pkg system using Project.toml, see https://github.com/JuliaRegistries/Registrator.jl#transitioning-from-require-to-projecttoml.
To then tag a new version of the package, see https://github.com/JuliaRegistries/Registrator.jl#via-the-github-app.

If you believe this package has erroneously been detected as not supporting 1.0 or have any other questions, don't hesitate to discuss it here or in the thread linked at the top of this post.

Shouldn't be that hard to update. Ubuntu 16.04 has been at cuDNN v5 for a few weeks now...

I've just "implemented" (by copy-and-pasting from Knet.jl) a new CuConv.jl package for convolution and pooling on CUDA. I haven't tested it thoroughly yet, but all in all it seems to work as is and it basically covers everything that I personally want to have from cuDNN. Also, as discussed in JuliaGPU/CuArrays.jl#22, many operations from cuDNN might be better to implement in Julia itself. So the question arises - what other functions do we actually need?

What's included in Knet.jl / CuConv.jl:

1. Convolution.
2. Deconvolution.
3. Pooling.
4. Unpooling.

What's not there:

1. LRNCrossChannel (I don't actually know what it is).
2. Divisive normalization.
3. Batch normalization (not implemented in CUDNN.jl, but there's version from Knet).
4. TransformTensor (alpha * src + beta * dest -> dest).
5. AddTensor.
6. SetTensor (src .= value).
7. ScaleTensor (src .*= alpha).
8. Activation functions (sigmoid, relu, tanh).
9. Softmax.

For me almost everything here looks like a better fit for CUBLAS + CUDAnative (with additional bonus of fused broadcasting). If so, we could deprecate CUDNN and instead concentrate on a more Julian approach.

cc: @MikeInnes @jekbradbury @denizyuret

Although it's great to have ML-specific functionality held separately from base CuArrays in this package, I'm wondering if we should keep convolutions in CuArrays itself (effectively making it part of the standard library). Image processing is a big use case for GPUs, and it'd be particularly nice if CuArrays and ImageFiltering.jl worked out of the box together.

This wouldn't imply any hard dependency on CUDNN for CuArrays, only the soft dep that we already have (and we could have slower backup kernels when CUDNN isn't available).