Karl,

I have tried now with the regular .size() calls and setting the leading
dimensions with .internal_size().  Same error.

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]) )
}

Regards,
Charles



On Tue, Aug 16, 2016 at 4:33 AM, Karl Rupp <r...@iue.tuwien.ac.at> 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 <r...@iue.tuwien.ac.at
>> <mailto:r...@iue.tuwien.ac.at>> 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
>>         <cdeterma...@gmail.com <mailto:cdeterma...@gmail.com>
>>         <mailto:cdeterma...@gmail.com <mailto:cdeterma...@gmail.com>>>
>>         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
>>         <r...@iue.tuwien.ac.at <mailto:r...@iue.tuwien.ac.at>
>>             <mailto:r...@iue.tuwien.ac.at
>>         <mailto:r...@iue.tuwien.ac.at>>> 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
>>                     <cdeterma...@gmail.com
>>         <mailto:cdeterma...@gmail.com> <mailto:cdeterma...@gmail.com
>>         <mailto:cdeterma...@gmail.com>>
>>                     <mailto:cdeterma...@gmail.com
>>         <mailto:cdeterma...@gmail.com>
>>                     <mailto:cdeterma...@gmail.com
>>         <mailto:cdeterma...@gmail.com>>>> 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>>>).
>>
>>                         Regards,
>>                         Charles
>>
>>                         On Wed, Aug 10, 2016 at 12:09 PM,
>>         <r...@iue.tuwien.ac.at <mailto:r...@iue.tuwien.ac.at>
>>                     <mailto:r...@iue.tuwien.ac.at
>>         <mailto:r...@iue.tuwien.ac.at>>
>>                         <mailto:r...@iue.tuwien.ac.at
>>         <mailto:r...@iue.tuwien.ac.at>
>>
>>                     <mailto:r...@iue.tuwien.ac.at
>>         <mailto:r...@iue.tuwien.ac.at>>>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
------------------------------------------------------------------------------
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel

Reply via email to