2011/5/11 Frédéric Bastien <[email protected]> > Hi, > > After our workshop this weekend, it sorted out that it would be very > useful to have the base GpuNdArray as a c object. We can inherit from > it in python and add many thing that is not supported in C or faster > version that use code generated on the fly. > > Do you have problem with this? If not, I will port the code in Theano > to be the first version of this. Our base object is in C, so this > should not be too hard. Globally my proposition is to have an object > with the same interface as numpy.ndarray. > > Here is the presentation with some fix, update: > > > https://docs.google.com/present/edit?id=dgktznnp_34dfdxgjgw&authkey=CIndhbMH > > Do you have any problem with the base object being in C? You talked > about problem with OpenCL. I did not understand them. Do you think > this proposition will have problem? Do we need to add the offset as > you talked about? > > thanks > > Frédéric > > _______________________________________________ > PyCUDA mailing list > [email protected] > http://lists.tiker.net/listinfo/pycuda >
Another possibility is to start a new project that is technically distinct from PyCUDA and PyOpenCL, although certainly built with interoperability in mind. PyCUDA and PyOpenCL could be seen as lightweight wrappers around CUDA and OpenCL. Since neither of these standards has an n-dimensional tensor datatype, then it could be seen as a loss of focus to add one. At the same time, a standalone project could provide a datatype that is compatible with *both* CUDA and OpenCL. The datatype consists essentially of a float pointer and shape and stride info. Since host-allocated OpenCL buffers can be de-referenced from non-OpenCL code, and I understand that in some cases OpenCL-allocated buffers can be passed to CUDA routines (is this true?) it would be nice if the data-type helped to gloss over these differences as much as possible. So how about starting a new project with the datatype that Fred describes, with the small addition of like a 'context' pointer or something, and possibly a 'context_type' enum that says whether it was an OpenCL or a CUDA or a HOST pointer that is allocated. The type can provide a python binding in C or python that supports numpy compatibility in cases where the data is stored in a way that is compatible with host-side pointers. The library can provide native C implementations of calls to CUBLAS, CUSPARSE, CUFFT, CURAND, and possibly some basic unary and binary arithmetic. This would essentially be a C package at first I think, and so operations that require any amount of code generation should be handled by higher level packages in different programming languages (e.g. python). This sounds a bit like a proposal to reimplement numpy, but the basics seem straightforward and in fact already done between Theano and PyCUDA. Also there's I think not the same pressure on the interface in Python to be good - downstream projects such as PyCUDA, Theano, and gnumpy can make the interface more or less pythonic. It's just a matter of refactoring. I don't know of another project that has done this. James -- http://www-etud.iro.umontreal.ca/~bergstrj
_______________________________________________ PyCUDA mailing list [email protected] http://lists.tiker.net/listinfo/pycuda
