Bug in CUDA backend about tensoroperations.jl

[tjjarvinen]

Can confirm that it now works with v4.07 - thanks!

Closing this one.

[Jutho]

The reason for this happening now is that indeed because you have CUDA.jl v5.0.0, whereas our tests and compat bounds are "CUDA=4". Apparently, these compat bounds are not respected in combination with package extensiosn (cjdoris/PackageExtensionCompat.jl#4)

We are looking into fixing this asap.

[lkdvos]

Actually, it seems like this might be a bug from our side. I think because of how I implemented the package extension, it was not reading the CUDA compat. I changed this now, such that TensorOperations should now restrict CUDA to v4. In order to support v5, a small adaptation of StridedViews.jl should do the trick, so we should be able to fix this soon.

[Jutho]

@lkdvos , so with the following configuration the above code definitely works:

⌅ [052768ef] CUDA v4.4.1
  [6aa20fa7] TensorOperations v4.0.6 `~/.julia/dev/TensorOperations`
⌃ [011b41b2] cuTENSOR v1.1.0

The following line, https://github.com/JuliaGPU/CUDA.jl/blob/9888ac92810373c3d6b58b5ca972d8df2afb4829/lib/cutensor/src/libcutensor.jl#L390C16-L390C16, which is in the stack trace, was already there in CUDA 4.4.1 and was already then forcing the conversion to ptr::PtrOrCuPtr{Cvoid}. So I guess that something in CUDA itself changed of how it handles conversions to PtrOrCuPtr{Cvoid} and why this does no longer end up with our definition for converting a CuStridedView{T} to PtrOrCuPtr{T}.

[Jutho]

Ok I think I understand. the reason why StridedViews was not enforcing CUDAv4 is because Strided 2.0.4 allows both StridedViews 0.1 and 0.2. So the package manager resolves this by having TensorOperations 4.0.6, Strided 2.0.4, CUDA5, and StridedViews 0.1.2. The latter doesn't have the package extension for CUDA and so does not impose restrictions on CUDA. And therefore, our pointer conversion routine is not called at all.

[Jutho]

Thanks for reporting