"CRV§ADER//KY" <[email protected]> writes: > OpenCL looks like something that marries fantastically with the whole > greenlet single-threaded paradigm of Tornado. However I couldn't find > enough support in PyOpenCL. > > Currently, the only way AFAIK to make PyOpenCL work with Tornado is: > > > import concurrent.futures > from tornado.gen import coroutine > executor = concurrent.futures.ThreadPoolExecutor(NUM_THREADS) > > class CLAsyncHandler(RequestHandler): > @coroutine > def get(self): > event1 = <PyOpenCL host-device copy> > event2 = <PyOpenCL kernel, wait_for=[event1]> > event3 = <PyOpenCL device-host copy, wait_for=[event2]> > yield executor.submit(event3.wait) > <omissis: do something with the returned host buffer> > > > which is quite horrible from a performance point of view. > From what I understood so far from the Tornado docs, all that would > need to change in PyOpenCL to make this thread-less is to enrich > pyopencl.Event with the same API as concurrent.futures.Future: > https://docs.python.org/dev/library/concurrent.futures.html#future-objects > The only non-trivial method is add_done_callback(), which would > internally need to call clSetEventCallback, which I believe is not > currently in PyOpenCL at all? > > The above code would become > > from tornado.gen import coroutine > > class CLAsyncHandler(RequestHandler): > @coroutine > def get(self): > event1 = <PyOpenCL host-device copy> > event2 = <PyOpenCL kernel, wait_for=[event1]> > yield <PyOpenCL device-host copy, wait_for=[event2]> > <omissis: do something with the returned host buffer> > > > As a bonus but not fundamental point, it would be nice if the output > of the result() method of a device-to-copy Event was the output host > buffer.
Correct, clSetEventCallback is not currently wrapped. In the past, handling asynchronous callbacks from undetermined thread contexts in Python was a bit of a nightmare that I decided to not get into. Python 2.7 has actually made this a lot better by adding Py_AddPendingCall(), so I'd be willing to consider this, and it wouldn't even be terribly hard. On the cffi end, I'm not completely sure that cffi's callback mechanisms are safe when they're called at arbitrary, asynchronous times, but they at least don't mention that they *aren't*. Andreas
pgp96brQYwnvD.pgp
Description: PGP signature
_______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
