On Sat, 30 Jul 2011 11:46:39 +0100 (BST), Jan Tore Korneliussen <[email protected]> wrote: Non-text part: multipart/mixed Non-text part: multipart/alternative > Hello pyopencl users, > > I have created a small project to explore declarative representations of > OpenCL command graphs. It is implemented in python and relies on pyopencl and > can be found here: > > http://code.google.com/p/ocl-cgraph-tools/ > > > I think that an alternative representation of a command graph can be useful > in many cases. > > * Can give the ability to move command graphs between dynamic language > environments like PyOpenCL and real-time environments (which may be > implemented in a compiled language). > * One way to get more dynamic runtime behaviour for compiled OpenCL > applications. > * Generation of host API C-code from a command graph. > * Store traces of programs which are using the OpenCL API. > * Intermediate format for autotuning/profile based optimization tools. > * Visualization of command graphs. > > > The syntax I have invented here must of course be seen as experimental and is > deliberately low-level to match the API. It is not given that a universal > low-level syntax is the best way to represent problems, maybe each domain > rather could use its own more high-level kernel graph syntax. Numpy > expressions "compiled" to OpenCL would be an example of this. > > I would be grateful for any feedback on this. Does such a mini-language has > its place? What would it take to make it useful?
Are you aware of any CL implementation that truly supports out-of-order command queues as of right now? I think I know Nv and AMD don't support it, does Intel? (I'd also be happy to be proven wrong on the first two.) In any case, good luck with your project! Andreas
pgpKLmjhUxeC1.pgp
Description: PGP signature
_______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
