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 <r...@iue.tuwien.ac.at> 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 <r...@iue.tuwien.ac.at
>> <mailto: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>
>> <mailto: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>>
>> <mailto: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>>
>> <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,
>>
>> 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>>>
>> <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
>> <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>>>
>>
>> <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>>>
>> <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
>> <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
