From: Charles D. <cde...@gm...> - 2016-08-17 13:23:17
|
Karl, I actually did use the relevant internal_size1/2 calls, just being little lazy in email, didn't realize there was a plain internal_size method. I have been modifying the clBLAS source to troubleshoot on what argument the CL_CHECK call is crashing on. It is crashing on the first kernel argument which is defined just before this call gemmKernelArgs[ 0] = &A; Where 'A' is referring to the buffer of the first matrix which I have passed in as cl_mem bufA = A.handle().opencl_handle().get() This is now where I am currently stuck as to why it believes that the buffer I pull from the viennacl matrix is invalid. Regards, Charles On Wed, Aug 17, 2016 at 4:00 AM, Karl Rupp <ru...@iu...> wrote: > Hi, > > I have tried now with the regular .size() calls and setting the leading >> dimensions with .internal_size(). Same error. >> > > This should be either .internal_size1() or .internal_size2(). > For dense matrices .internal_size() equals .internal_size1() * > internal_size2(). > > > The error is reported on line 274 of the clBLAS/src/libary/blas/xgemm.cc >> file. It appears this loop is where it is causing the problem. >> >> for (unsigned int i = 0; i < numKernelArgs; i++) { >> CL_CHECK( clSetKernelArg( clKernel, i, kernelArgSizes[i], >> kernelArgs[i]) ) >> } >> > > I can't tell what is going wrong here based on the description provided. > > Best regards, > Karli > > > >> On Tue, Aug 16, 2016 at 4:33 AM, Karl Rupp <ru...@iu... >> <mailto:ru...@iu...>> wrote: >> >> Hi, >> >> >> >> On 08/15/2016 08:56 PM, Charles Determan wrote: >> >> Karl, >> >> I have the OpenCL backend enabled and I have tried: >> >> cl_mem bufA = A.handle().opencl_handle().get() >> cl_mem bufB = B.handle().opencl_handle().get() >> cl_mem bufC = C.handle().opencl_handle().get() >> >> cl_command_queue queue = >> viennacl::ocl::current_context().get_queue().handle().get(); >> >> err = clblasDgemm(clblasRowMajor, clblasNoTrans, clblasNoTrans, >> A.internal_size2(), >> B.internal_size1(), A.internal_size1(), >> >> >> Are you sure these sizes are correct? I'd expect that you use >> .size1() and .size2() here, and use the respective .internal_size1() >> and .internal_size2() for the leading dimensions (lda, ldb, ldc). >> >> Best regards, >> Karli >> >> >> alpha, bufA, 0, lda, >> bufB, 0, ldb, beta, >> bufC, 0, ldc, >> 1, >> &queue, >> 0, NULL, 0); >> >> >> Although this compiles it results in the error - >> CL_INVALID_MEM_OBJECT >> >> >> Where (which line) do you get the error? >> >> Best regards, >> Karli >> >> Not sure if you have any other thoughts or if I should try >> asking clBLAS >> developers. >> >> Thanks again, >> Charles >> >> On Mon, Aug 15, 2016 at 1:30 PM, Karl Rupp >> <ru...@iu... <mailto:ru...@iu...> >> <mailto:ru...@iu... <mailto:ru...@iu...>>> >> wrote: >> >> Hi Charles, >> >> I am trying to verify my interface with clBLAS before >> going >> completely >> in to clMAGMA. However, I keep getting an OpenCL error >> -38 which >> corresponds to invalid memory (CL_INVALID_MEM_OBJECT) >> when trying a >> clblasDgemm call. This must be referring to the opencl >> memory >> handles I >> am passing in. The fields generally accepts memory >> buffers (cl_mem) >> objects. I have tried passing both >> A.handle.opencl_handle() and >> A.handle.opencl_handle().get() in those fields but get >> the same >> error. >> >> >> These should be A.handle.opencl_handle().get() >> Mind the parantheses after 'handle'. >> >> Also, you will get the error if you don't enable the OpenCL >> backends, or if you enabled the CUDA backend as well (as >> CUDA will >> be the default then). >> >> Best regards, >> Karli >> >> >> I will continue to poke around (maybe I need to use >> internal_size >> numbers) but thought I would ask you about this. >> >> Any insight? >> >> Thanks, >> >> Charles >> >> On Fri, Aug 12, 2016 at 3:21 PM, Charles Determan >> <cde...@gm... <mailto:cde...@gm...> >> <mailto:cde...@gm... <mailto:cde...@gm...>> >> <mailto:cde...@gm... >> <mailto:cde...@gm...> <mailto:cde...@gm... >> <mailto:cde...@gm...>>>> >> wrote: >> >> Thanks Karl, >> >> One followup question, what distinguishes handle(), >> handle1(), and >> handle2()? Do they refer to different buffers? >> >> Regards, >> Charles >> >> On Fri, Aug 12, 2016 at 3:13 PM, Karl Rupp >> <ru...@iu... <mailto:ru...@iu...> >> <mailto:ru...@iu... <mailto:ru...@iu...>> >> <mailto:ru...@iu... >> <mailto:ru...@iu...> >> <mailto:ru...@iu... >> <mailto:ru...@iu...>>>> wrote: >> >> Hi Charles, >> >> call .handle()/.handle1()/.handle2() to get the >> abstract >> memory >> buffers, and call .opencl_handle() on them to >> get the cl_mem >> handles: >> >> A.handle().opencl_handle() >> >> Similarly, the command queue is obtained with >> viennacl::ocl::get_queue().handle().get() >> >> Unfortunately it's not explicitly written in the >> manual :-/ >> >> Best regards, >> Karli >> >> >> On 08/12/2016 09:39 PM, Charles Determan wrote: >> >> I also would need to access the command >> queue handle >> (cl_command_queue) >> object to pass to clBLAS and clMAGMA >> functions. Is >> this easily >> accessible as well? >> >> Thanks, >> Charles >> >> On Fri, Aug 12, 2016 at 11:45 AM, Charles >> Determan >> <cde...@gm... >> <mailto:cde...@gm...> >> <mailto:cde...@gm... >> <mailto:cde...@gm...>> <mailto:cde...@gm... >> <mailto:cde...@gm...> >> <mailto:cde...@gm... >> <mailto:cde...@gm...>>> >> <mailto:cde...@gm... >> <mailto:cde...@gm...> >> <mailto:cde...@gm... >> <mailto:cde...@gm...>> >> <mailto:cde...@gm... >> <mailto:cde...@gm...> >> <mailto:cde...@gm... >> <mailto:cde...@gm...>>>>> wrote: >> >> Thanks Karl, >> >> I have been looking through the docs and >> I can't >> find an >> example for >> how to pull the OpenCL handles from a >> matrix. I >> saw a >> couple I >> think from a context but not sure that >> is what I >> need. >> Is this in >> the documentation somewhere? The closest >> I >> could fine >> is this page >> >> (http://viennacl.sourceforge.net/doc/manual-memory.html >> <http://viennacl.sourceforge.net/doc/manual-memory.html> >> <http://viennacl.sourceforge.net/doc/manual-memory.html >> <http://viennacl.sourceforge.net/doc/manual-memory.html>> >> >> <http://viennacl.sourceforge.net/doc/manual-memory.html >> <http://viennacl.sourceforge.net/doc/manual-memory.html> >> <http://viennacl.sourceforge.net/doc/manual-memory.html >> <http://viennacl.sourceforge.net/doc/manual-memory.html>>> >> >> <http://viennacl.sourceforge.net/doc/manual-memory.html >> <http://viennacl.sourceforge.net/doc/manual-memory.html> >> <http://viennacl.sourceforge.net/doc/manual-memory.html >> <http://viennacl.sourceforge.net/doc/manual-memory.html>> >> >> <http://viennacl.sourceforge.net/doc/manual-memory.html >> <http://viennacl.sourceforge.net/doc/manual-memory.html> >> <http://viennacl.sourceforge.net/doc/manual-memory.html >> <http://viennacl.sourceforge.net/doc/manual-memory.html>>>>). >> >> Regards, >> Charles >> >> On Wed, Aug 10, 2016 at 12:09 PM, >> <ru...@iu... <mailto:ru...@iu...> >> <mailto:ru...@iu... <mailto:ru...@iu...>> >> <mailto:ru...@iu... >> <mailto:ru...@iu...> >> <mailto:ru...@iu... >> <mailto:ru...@iu...>>> >> <mailto:ru...@iu... >> <mailto:ru...@iu...> >> <mailto:ru...@iu... >> <mailto:ru...@iu...>> >> >> <mailto:ru...@iu... >> <mailto:ru...@iu...> >> <mailto:ru...@iu... >> <mailto:ru...@iu...>>>>> wrote: >> >> Hi Charles, >> >> >> I have recently expressed some >> interest >> in different >> factorizations such as >> QR and SVD. I am aware that >> these or >> currently >> experimental >> within >> ViennaCL. Until such a time >> that these >> factorizations are >> fully supported >> (I hope to contribute but the >> algorithms are >> quite complex) >> would it be >> feasible to interface with a >> library like >> clMAGMA? I'm not >> sure of any >> other library offhand that does >> implement these >> methods. I >> thought perhaps >> VexCL but I couldn't find >> anything to that >> effect in the >> documentation. >> >> >> Sure, you can always grab the OpenCL >> handles >> from >> the matrices >> and plug that into clMAGMA. >> I don't think there is any value in >> ViennaCL >> wrapping the >> clMAGMA interfaces, though. >> >> Best regards, >> Karli >> >> >> >> >> >> >> >> >> >> >> >> > |