Hi Dmitriy, > To get a little bit more background, we are thinking of enabling Apache > mahout algebra to auto probe for hardware and use ViennaCL-supported > in-memory computations there (not to mention additional solvers are just > great, some of our basic in-memory java-only algebra is just very slow). > > We were thinking, and were having a question, perhaps if we wanted to > support all of the possible backend options, it looks like we would have > to build 3 different jars: one is that loads -l openCL, one that loads > cuda, and one is just all in host memory backend.
You might be fine with just 2: host-only and host+OpenCL. You can use OpenCL on NVIDIA GPUs without any performance drop compared to CUDA. host+OpenCL is also much more build-friendly than anything CUDA-related. > The reason we don't seem to be able to create just one jar maven module > to support all backends in one maven artifact is because once we load > the library, it will probably at some point will try to load both opencl > and cuda, whereas in reality we expect environments that at runtime may > have only one (or even none) of those apis configured and supported. > > So what we were thinking, perhaps we need 3 separate artifacts > eventually, one for host+opencl, one for host+cuda, and if all of that > works, then we could also have just host-only module (since cpu > benchmarks seem to be quite good too, so if we get this for free, then > there's no reason not to use it). > > on the downside of this 3 differently compiled modules, it would seem we > won't able to load any two of these modules at the same time since the > symbols are likely clash. Hard to see how much that might be a problem. > > Or, is it possible that we are completely misunderstanding this and it > is possible to compile a single ViennaCL-enabled .so so that it will > load libOpenCL.so if it is available only, and cuda if it is available > only etc. etc. (I don't think so, right now loading .so crashes if there > is no libOpenCL.so in the system but we try to create opencl context). > > Or perhaps it is just possible to probe for support of opencl and cuda > and just avoid creating context with non-supported devices by our logic > and then we can support all options in one module? That option would be > terrific to have. I really don't like having to compile and publish 3 > different maven artifcacts for each case too much. What you are asking for is a dynamic load of backends at runtime, just like you can load all kinds of plugins in your webbrowser dynamically. Currently such a dynamic backend enabling is not supported in ViennaCL (most scientific software does not support that), so you have to work with two or three separate builds of ViennaCL and load the correct one at runtime to avoid symbol clashes. We intend to provide a dynamic backend detection at runtime with ViennaCL 2.0. Although an earlier poll in this mailing list indicated that most users are fine with the status quo, over the last months I've come to the conclusion that such a dynamic backend detection mechanism is necessary to bring ViennaCL to the next level. Applications such as the one you are working on cannot (or do not want to) afford messy recompilations or managing multiple builds of the different libraries they rely on. This is a topic I touched in some of my recent talks, so it's something I'm really serious about :-) Best regards, Karli > > > On Tue, Jul 12, 2016 at 9:27 AM, Karl Rupp <r...@iue.tuwien.ac.at > <mailto:r...@iue.tuwien.ac.at>> wrote: > > Hi, > > > One question: you mentioned padding for the `matrix` type. When i > > initialize the `matrix` instance, i only specify dimensions. how > do I > know padding values? > > > if you want to provide your own padded dimensions, consider using > matrix_base directly. If you want to query the padded dimensions, > use internal_size1() and internal_size2() for the internal number of > rows and columns. > > http://viennacl.sourceforge.net/doc/manual-types.html#manual-types-matrix > > Best regards, > Karli > > > > > On Tue, Jul 12, 2016 at 5:53 AM, Karl Rupp > <r...@iue.tuwien.ac.at <mailto:r...@iue.tuwien.ac.at> > <mailto:r...@iue.tuwien.ac.at <mailto:r...@iue.tuwien.ac.at>>> > wrote: > > Hi Dmitriy, > > On 07/12/2016 07:17 AM, Dmitriy Lyubimov wrote: > > Hi, > > I am trying to create some elementary wrappers for VCL > in javacpp. > > Everything goes fine, except i really would rather not > use those > "cpu" > types (std::map, > std::vector) and rather initialize matrices directly by > feeding > row-major or CCS formats. > > I see that matrix () constructor accepts this form of > initialization; > but it really states that > it does "wrapping" for the device memory. > > > Yes, the constructors either create their own memory buffer > (zero-initialized) or wrap an existing buffer. These are > the only > reasonable options. > > > Now, i can create a host matrix() using host memory and > row-major > packing. This works ok it seems. > > However, these are still host instances. Can i copy host > instances to > instances on opencl context? > > > Did you look at viennacl::copy() or viennacl::fast_copy()? > > > That might be one way bypassing unnecessary (in my case) > complexities of > working with std::vector and std::map classes from java > side. > > But it looks like there's no copy() variation that > would accept a > matrix-on-host and matrix-on-opencl arguments (or > rather, it of > course > declares those to be ambiguous since two methods fit). > > > If you want to copy your OpenCL data into a > viennacl::matrix, you > may wrap the memory handle (obtained with .elements()) into > a vector > and copy that. If you have plain host data, use > viennacl::fast_copy() and mind the data layout (padding of > rows/columns!) > > > For compressed_matrix, there seems to be a set() > method, but i guess > this also requires CCS arrays in the device memory if I > use it. Same > question, is there a way to send-and-wrap CCS arrays to an > opencl device > instance of compressed matrix without using std::map? > > > Currently you have to use .set() if you want to bypass > viennacl::copy() and std::map. > > I acknowledge that the C++ type system is a pain when > interfacing > from other languages. We will make this much more convenient in > ViennaCL 2.0. The existing interface in ViennaCL 1.x is too > hard to > fix without breaking lots of user code, so we won't invest > time in > that (contributions welcome, though :-) ) > > Best regards, > Karli > > > > > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
