Hi KarlThat'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? Thanks and 
Regards
Sumit
      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>
> *To:* Sumit Kumar <dost_4_e...@yahoo.com>
> *Cc:* "viennacl-devel@lists.sourceforge.net"
> <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

Reply via email to