Hey :) 2014-11-09 10:06 GMT-05:00 Karl Rupp <[email protected]>:
> Hi guys, > > I've updated our roadmap taking into account the latest release: > https://github.com/viennacl/viennacl-dev/wiki/ViennaCL-Roadmap > Feel free to add your topics and post your wishes :-) > > Awesome! Is it like a christmas present list? Can we post any wish? I'd like a pony, actually. :D The 1.6.1 release is scheduled for the week November 17-21, for which we > will provide a new fast kernel right when it is presented at the > Supercomputing conference. > > I had the hope I could get my hand on some GTX970 or GTX980, but I wasn't able to. If any deveoper has access to such hardware, it would be great to let us know, so that we can get optimized kernel for this hardware, and possibly compare against CuBLAS, before SC14. > My personal main goal for 1.7.0 is to reduce the use of Boost.uBLAS as > much as possible and to have a fast, entirely GPU-based AMG > preconditioner (similar to what is in CUSP). At the same time, I'd like > to promote shorter release cycles: 1.6.0 was released about a year after > 1.5.0, which keeps quite a number of completed features stuck in the > pipeline for too long. > > I've added mines. Rather modest: better auto-tuning, and more devices supported. I am directing my efforts towards my specialization for dense BLAS on OpenCL, which will hopefully get integrated in the 2.0.0 release. Maybe there will be a 1.8.0 release as well, which will still follow the > current header-only model. However, we may also switch to ViennaCL 2.0.0 > right after the 1.7.x series in order to better target languages other > than C++ (most notably C and Fortran due to their wide-spread use in HPC). > > I will post what I think is reasonable, although most of my thoughts go towards ViennaCL 2.0. As I said I have started today to rewrite the OpenCL layer of ViennaCL using CL/cl.hpp and dynamic layout + datatype (the rationale behind this choice is that OpenCL is already not type-safe anyway, and so clAmdBlas is not type-safe either). It will be interesting to see the influence it will have on the compilation time. Philippe Any thoughts and input is - as always - welcome :-) > > Best regards, > Karli > > > ------------------------------------------------------------------------------ > _______________________________________________ > ViennaCL-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/viennacl-devel >
------------------------------------------------------------------------------
_______________________________________________ ViennaCL-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/viennacl-devel
