Hey, > 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
Haha - send me your address and I'll order a hairdresser for you :-P > 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. The GTX 970 and 980 are again limited by firmware for double precision, so these GPUs are not that interesting for GPGPU. Also, we already have a profile for the GTX 750 Ti, which is Maxwell and detected as such (hence the profile gets reused for the 970 and 980). What we don't have at the moment is a profile for the GTX Titan (with no good fallback), so I consider this more urgent. > 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. Makes sense, thanks! > 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. Btw: Please be considerate with MacOS and don't forget the necessary #ifdef when including the OpenCL headers... :-) Best regards, Karli ------------------------------------------------------------------------------ _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
