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, which work for vectors and matrices alike. Best regards, Karli > ------------------------------------------------------------------------ > *From:* Karl Rupp <r...@iue.tuwien.ac.at> > *To:* Sumit Kumar <dost_4_e...@yahoo.com> > *Cc:* "viennacl-devel@lists.sourceforge.net" > <viennacl-devel@lists.sourceforge.net> > *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 <r...@iue.tuwien.ac.at <mailto:r...@iue.tuwien.ac.at>> > > *To:* Sumit Kumar <dost_4_e...@yahoo.com <mailto:dost_4_e...@yahoo.com>> > > *Cc:* "viennacl-devel@lists.sourceforge.net > <mailto:viennacl-devel@lists.sourceforge.net>" > > <viennacl-devel@lists.sourceforge.net > <mailto:viennacl-devel@lists.sourceforge.net>> > > *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 ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
