Archives Discussions

[rafal_lewczuk]

available at sourceforge.net

Hi,

While learning about GPGPU and data parallelism I implemented a set of Python bindings for AMD CAL library. Project seeks for more general data-parallelism related topics but currently CAL interface is (mostly) all of its functionality. This is a first release (or rather a rudimentary development snapshot), so expect it to be a (somewhat incomplete) toy rather than a well thought-out, industrial strength library . While it may not feature a decent performance nor API stability, it is a good tool to learn about IL language or figure out (un)documented parts of the language - it lets implementing GPU-aware programs as simple Python scripts.

You can find project page at http://sourceforge.net/projects/pygwa. A tarball with source code is now available at downloads section (there is no version control due to technical reasons - SVN service at sourceforge crashes for unknown reason, I hope it will be solved soon).

This code has been implemented on Ubuntu 8.04/amd64 and Radeon 4850 card. It wasn't tested on other platforms, particularly not on Windows. After unpacking look at README file for build instructions. Suggestions, bug reports and feature requests are welcome.

Regards,

rle

[rahulgarg]

Cool. Looking over it. I am working on something similar. I am using ctypes though thats not a big issue.
About license : would you consider some other license than GPL? Since its a library that people will link to, might be better to license it under LGPL or BSD or something though since you are the author, thats upto you.
(I will be using Apache2 when I release it).

[rafal_lewczuk]

Hi,

I was a bit puzzled deciding GPL<->LGPL and temporarily chose GPL but I think I'll go LGPL with the next snapshot (I hope to have it out at the end of this week or at the beginning of the next week).

About ctype: it is propably better for most things as much of my code looks heavily redundant (all these classes representing various things, having nothing but constructors and destructors and lots of glue code). As I don't mind programming C, I didn't care much about this. Some things need to be native, however,  like CalResource<->Numeric.array integration - this way it is possible to implement resource objects as Numeric.array descendants thus eliminating many bulk data copies into and from resource objects (planned but not implemented yet).

Regards

rle