search

JuliaAttic / CUBLAS.jl

Julia interface to CUBLAS
Other
26 stars 19 forks source link

Use CUDAdrv instead of CUDArt #30

Closed MikeInnes closed 7 years ago

MikeInnes commented 7 years ago

This package only needs a couple of types anyway, but generally CUDAdrv is better maintained (we even discussed deprecating CUDArt in order to unify things a bit more).

maleadt commented 7 years ago

wrt. OwnedPtr, this is the first design iteration so it could be improved, but conceptually I didn't want downstream packages to use it because it is just an implementation detail to deal with resource finalization. And because the design is bound to change, as is evident from this use case.

But as you say, some users will require manual memory management to build whatever they need. What about an abstract Buffer with OwnedPtr being the struct CUDABuffer <: Buffer, and by-protocol having an unsafe_convert(::Ptr, Buffer and some others?

MikeInnes commented 7 years ago

That could work. You could also expose struct Buffer(ptr::T, len::Int) or something similar, and guarantee the API of Buffer but not of the internal ptr type (other than that it can be passed to kernels).

Raw access to buffers seems essential, but I don't think we need anything more than that (e.g. pointer arithmetic, which we can do by storing an offset where needed).

MikeInnes commented 7 years ago

I've tried removing OwnedPtr but I think it's going to be an uphill battle; CUBLAS uses pointer(xs) a lot as well as pointer arithmetic. It seems strange that pointer still returns an OwnedPtr if that's meant to be an implementation detail; and since it's not a subtype of Ref there's no interface we can use to handle it abstractly.

I think we should go ahead with this improvement (which is at least no worse than the original) and then figure out the right pointer design that handles these cases.

maleadt commented 7 years ago

It seems strange that pointer still returns an OwnedPtr if that's meant to be an implementation detail

It ought to implement the same basic interface.

and since it's not a subtype of Ref there's no interface we can use to handle it abstractly.

I thought subtyping Ref had other consequences, wrt. ccall and such. Not sure though.

I think we should go ahead with this improvement (which is at least no worse than the original) and then figure out the right pointer design that handles these cases.

Was going to propose the same. We can iron out a buffer-like interface, or another design, when we have some more bandwidth to do so (hackathon). I'll try and keep OwnedPtr stable until then.

MikeInnes commented 7 years ago

Great, thanks a lot. I don't think the stability restrictions on OwnedPtr are too tight, since we're only really relying on it to exist and behave in a vaguely pointer-like way.