You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Quoting: "In an ideal world, the Clyther developers would move the core such that it was built on top of PyOpenCL, so we wouldn't have to choose, and to avoid duplication of labor. I doubt that will ever happen, though." http://stackoverflow.com/a/4869923
Clyther looks like the most straightforward Python/OpenCL option, despite not being very complete, it is already very powerful and useful. However, it hasn't been updated in quite a while apparently. Given the ideas and features discussed on the website, I was wondering if it might be a feasible option to implement Clyther either on top of PyOpenCL or possibly llvm/llvmpy, llvm is already being used by AMD/NVIDIA to compile OpenCL and the tool chain is fully exposed, so that Python bytecode could be transparently processed and turned into corresponding CL kernels.
The text was updated successfully, but these errors were encountered:
When I created CLyther, PyOpenCL was in it's infancy so I created my own OpenCL Python bindings https://github.com/srossross/oclpb which are separate from the CLyther Language translator. It should be feasible to remove the dependency on oclpb and replace it with PyOpenCL
Quoting: "In an ideal world, the Clyther developers would move the core such that it was built on top of PyOpenCL, so we wouldn't have to choose, and to avoid duplication of labor. I doubt that will ever happen, though."
http://stackoverflow.com/a/4869923
Clyther looks like the most straightforward Python/OpenCL option, despite not being very complete, it is already very powerful and useful. However, it hasn't been updated in quite a while apparently. Given the ideas and features discussed on the website, I was wondering if it might be a feasible option to implement Clyther either on top of PyOpenCL or possibly llvm/llvmpy, llvm is already being used by AMD/NVIDIA to compile OpenCL and the tool chain is fully exposed, so that Python bytecode could be transparently processed and turned into corresponding CL kernels.
The text was updated successfully, but these errors were encountered: