On Sat, 25 Jun 2011 02:08:14 +1000, Bogdan Opanchuk <[email protected]> wrote: > Hello Andreas, > > On Sat, Jun 25, 2011 at 1:37 AM, Andreas Kloeckner > <[email protected]> wrote: > > 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? In > 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 tomorrow) Andreas
pgpuCOJS5AFLq.pgp
Description: PGP signature
_______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
