On Sat, 25 Jun 2011 02:08:14 +1000, Bogdan Opanchuk <mantihor(a)gmail.com> wrote:
On Sat, Jun 25, 2011 at 1:37 AM, Andreas Kloeckner
> Oh, sorry. I misunderstood. I'm actually not planning on doing what you
> describe. What I'd like is to get towards a shared subset of
> functionality that makes it less annoying than currently to write code
> that talks to both packages.
This will be great too. I already have this in two projects in the
form of context-wrapping class (containing a single stream, I do not
need more) with functions for synchronization, memory allocation and
copy, kernel compilation and execution plus some fields with device
parameters. The main annoyance for me is push/pop mechanics of Cuda
contexts (unlike CL context objects); but I am not really following
Cuda API changes, so they may have done something about it in 4.0.
Push/pop is indeed deprecated in favor of set/get() in 4.0, thank god.
PyCUDA doesn't expose the setting API yet, simply because the module
itself does a fair bit of its own context management, and to retain
compatibility with older CUDA versions, I'm sticking to push/pop until a
future version of CUDA (5.x?) removes push/pop.
By the way, do you already have some specific architecture in mind?
particular, is this layer going to be written in C++ or Python, and
what functionality are you planning to include?
C++/Python? Python, unless C++ is necessary for speed. Functionality?
Just the bare necessities, just like you did.
In fact, can you point me to your version of this? (Is it in pyfft?)
This would already be a good starting point that I might simply throw
into compyte once the 2011.1 releases are out of the way. (Probably