Hi, I read your documentation. The project is more then just a collection of implementation. How much useful it is to abstract between PyCUDA and PyOpenCL? Personnaly, I probably won't use that part, but I want to abstract between CUDA and OpenCL.
I like the idea of making code generator that do transformation on the input before doing other computation. This is something I wanted Theano code generator to do, but I never got time to implement it. What the current parameter derive_s_from_lp and derive_lp_from_s mean? Also the code section is not something I call readable... Is is only because I never used Mako? Andreas, I think you used mako, do you find this redable? I'm not sure that forcing people to use Mako is a good idea. Can we do without it? I still think that we need to provide the user not just with a common gpu nd array object. We need to also provide fonctions on it. But I'm not sure how we should do this. Andreas, do you have an idea? Fred On Wed, Jul 18, 2012 at 10:29 AM, Bogdan Opanchuk <[email protected]> wrote: > Hi all, > > Some of you may remember compyte discussions last year when I made the > suggestion of creating a library with a compilation of GPGPU > algorithms, working both with PyOpenCL and PyCuda. Long story short, I > have finally found some time and created a prototype. The preliminary > tutorial can be found at http://tigger.publicfields.net/tutorial.html > and the project itself at https://github.com/Manticore/tigger . The > examples are working and those few tests I have are running. The code > in tigger.core is a mess, but I'm working on it. > > At this stage this library is a prototype (or even a proof of concept) > whose fate is not sealed. My current plans are to refactor tigger.core > and tigger.cluda (sorry for stealing the name, Andreas, I can change > it :) over the course of a week or two and start filling it with > actual algorithms. One of the first will be FFT, thus deprecating > pyfft, list of other plans is in TODO.rst. On the other hand, the > library could be made a part of compyte, although I'm not sure it'll > fit its goals. > > Anyway, any sort of input is appreciated. Those who want to use the > library for practical applications may want to wait for the next > version, which is supposed to be somewhat stable. > > _______________________________________________ > PyCUDA mailing list > [email protected] > http://lists.tiker.net/listinfo/pycuda _______________________________________________ PyCUDA mailing list [email protected] http://lists.tiker.net/listinfo/pycuda
