Thank you! this is very useful .
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.
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.
On Tue, Jul 12, 2016 at 9:27 AM, Karl Rupp <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>> 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
