KarlI know that we can copy a dense eigen matrix to a dense VCL matrix and the
same thing for sparse matrices also.Is it possible to copy a sparse eigen
matrix to a dense eigen matrix? and vice-versa ? Thanks and Regards
Sumit
From: Karl Rupp <[email protected]>
To: Sumit Kumar <[email protected]>
Cc: "[email protected]"
<[email protected]>
Sent: Tuesday, July 28, 2015 4:01 PM
Subject: Re: [ViennaCL-devel] ViennaCL reductions
Hi,
> That worked. So, the final question I have would be as follows:
> viennacl::copy(vcl_C, eigen_mat);
> is a valid statement
> However, if I want to copy vcl_C to some particular region of a host
> matrix, then, do I have to first create a temporary host matrix and then
> copy that host matrix into a larger matrix or is there anything direct?
> Something like this:
> viennacl::copy(vcl_C, prod.block(0, j, source.rows(), bTemp.cols()));
>
> Otherwise the only way I can think of is this:
> RMMatrix_Float temp(rows,cols);
> viennacl::copy(vcl_C, temp);
> RMMatrix_Float biggerMatrix.block(0,j,rows,cols) = temp
you can either use temporaries, or create an Eigen::Map<> from your
Eigen matrix for wrapping your existing matrix accordingly:
http://eigen.tuxfamily.org/dox/classEigen_1_1Map.html
Best regards,
Karli
> ------------------------------------------------------------------------
> *From:* Karl Rupp <[email protected]>
> *To:* Sumit Kumar <[email protected]>
> *Cc:* "[email protected]"
> <[email protected]>
> *Sent:* Tuesday, July 28, 2015 2:06 AM
> *Subject:* Re: [ViennaCL-devel] ViennaCL reductions
>
> Hi,
>
> > That's why I explicitly stated in my previous mail "Optional" :) I am
> > one of those folks who likes the coziness of compile time decisions and
> > (if possible) would like to make it available in VCL. However, I am not
> > sure if doing this is possible via the current API structure of VCL. I
> > will look into this as I first need to understand the intricacies of
> > OpenCL.
> >
> > BTW, a previous question of mine was unanswered (or I may have
> > overlooked). Are there any equivalent functions in VCL to do the
> following:
> > a.) Two matrices, when transferred to the GPU should undergo
> > element_wise multiplication ?
> > b.) A unary operation on a matrix that has been transferred to the GPU?
>
> a.) and b.) sound a lot like you are looking for element_*-functions
> http://viennacl.sourceforge.net/doc/manual-operations.html#manual-operations-blas1,
> <http://viennacl.sourceforge.net/doc/manual-operations.html#manual-operations-blas1,>
> which work for vectors and matrices alike.
>
> Best regards,
> Karli
>
>
>
> > ------------------------------------------------------------------------
> > *From:* Karl Rupp <[email protected] <mailto:[email protected]>>
> > *To:* Sumit Kumar <[email protected] <mailto:[email protected]>>
> > *Cc:* "[email protected]
> <mailto:[email protected]>"
> > <[email protected]
> <mailto:[email protected]>>
> > *Sent:* Monday, July 27, 2015 9:13 PM
> > *Subject:* Re: [ViennaCL-devel] ViennaCL reductions
> >
> > Hi Sumit,
> >
> > > Agreed, the names can be returned in any order. As you are using CMake
> > > would it be possible to:
> > > a.) Write a small helper script using CMake that lists what
> devices the
> > > user has on his/her machine that are OpenCL compliant?
> >
> > Exactly this is provided by running viennacl-info:
> > $> mkdir build && cd build
> > $> cmake ..
> > $> make viennacl-info
> > $> examples/tutorial/viennacl-info
> >
> >
> > > b.) Make VCL select the appropriate device so that these issues of
> > > context selection etc can be avoided?
> >
> > In most cases the first OpenCL device returned is the most appropriate
> > device for running the computations. If you know of any better strategy
> > for picking the default device, please let us know and we are happy to
> > adopt it. :-)
> >
> >
> > > c.) Of course, this would be purely optional and only available if the
> > > user wants to pre-select the device before writing any VCL code!
> >
> > How is that different from what is possible now? What is the value of
> > making a runtime-decision (current ViennaCL code) a compile-time
> > decision (CMake)?
> >
> > Imagine you are building a big application with GUI and other bells and
> > whistles. In such a scenario you would like the user to select the
> > compute device through a dialog at runtime rather than asking the user
> > to recompile the whole application just to change the default device.
> > Our current mindset is to incrementally move away from compile time
> > decisions in cases where they are not needed.
> >
> > Best regards,
> > Karli
> >
> >
> >
> >
> >
> >
> >
> > >
> ------------------------------------------------------------------------
> > > *From:* Karl Rupp <[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>>
> > > *To:* Sumit Kumar <[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>>
> > > *Cc:* "[email protected]
> <mailto:[email protected]>
> > <mailto:[email protected]
> <mailto:[email protected]>>"
> > > <[email protected]
> <mailto:[email protected]>
> > <mailto:[email protected]
> <mailto:[email protected]>>>
>
>
>
> > > *Sent:* Monday, July 27, 2015 7:03 PM
> > > *Subject:* Re: [ViennaCL-devel] ViennaCL reductions
> > >
> > > Hi Sumit,
> > >
> > > > Thanks for the update. I will check it out. As for the second one,
> > > > indeed thats what I ended up doing:
> > > >
> > > > // Get some context information for OpenCL compatible GPU
> devices
> > > > viennacl::ocl::platform pf;
> > > > std::vector<viennacl::ocl::device> devices =
> > > > pf.devices(CL_DEVICE_TYPE_GPU);
> > > > // If no GPU devices are found, we select the CPU device
> > > > if (devices.size() > 0)
> > > > {
> > > > // Now, often we may have an integrated GPU with the CPU. We
> > would
> > > > // like to avoid using that GPU. Instead, we search for a
> > discrete
> > > > // GPU.
> > > > viennacl::ocl::setup_context(0, devices[1]);
> > > > }
> > > > else
> > > > {
> > > > devices = pf.devices(CL_DEVICE_TYPE_CPU);
> > > > viennacl::ocl::setup_context(0, devices[0]);
> > > > }
> > >
> > > Keep in mind that devices may be returned in arbitrary order. I've
> > > already seen cases where the discrete GPU is returned as the first
> > > device. (Unfortunately I don't know of a robust and general way of
> > > dealing with such cases).
> > >
> > >
> > > > Here is my kludge. Is there any "real" example of data
> > partitioning and
> > > > using multiple GPU's?
> > >
> > > No. PCI-Express latencies narrow down to sweet spot of real
> performance
> > > gains for most algorithms in ViennaCL a lot. Only algorithms relying
> > > heavily on matrix-matrix multiplications are likely to show good
> benefit
> > > from multiple GPUs. As a consequence, we are currently keeping our
> focus
> > > on single GPUs. There is some multi-GPU support through ViennaCL as a
> > > plugin for PETSc available, but that focuses on iterative solvers and
> > > does not cover any eigenvalue routines yet.
> > >
> > >
> > >
> > >
> > > Best regards,
> > > Karli
> > >
> > >
> > >
> >
> >
> >
>
>
>
------------------------------------------------------------------------------
_______________________________________________
ViennaCL-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
