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
Hi Andy and Dmitriy,
apologies for the late reply and thanks for narrowing down the problem.
I could reproduce the problem on my machine and can confirm that the
issue is due to the order of include files. Specifically, Andy's code
compiles if
#include "viennacl/compressed_matrix.hpp"
is inclu
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 argu
On Wed, Aug 17, 2016 at 2:50 AM, Karl Rupp wrote:
> Hi Andy and Dmitriy,
>
> We could (and probably should?) add such a convenience header file at the
> expense of increased compilation times (and reduced encapsulation of source
> code against compiler issues).
+1 on single header! :)
Ultimate
Hi,
> 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
> ker
PS also since it is being built as part of our build, we also get control
over supported HW options and platforms. I.e., we may generate not only
per-platform support, but also further specialize for things like +AVX2
instruction set optimized openMP version (which anecdotally runs about ~2
times f
Hi Dmitriy,
> We could (and probably should?) add such a convenience header file
> at the expense of increased compilation times (and reduced
> encapsulation of source code against compiler issues).
>
>
> +1 on single header! :)
thanks for the feedback:
https://github.com/viennacl/vie
There is a fair amount of output, hopefully something here provides a clue
that you can understand.
ViennaCL: Initializing context no. 1
ViennaCL: Initializing new ViennaCL context.
ViennaCL: Setting all devices for context...
ViennaCL: Getting platform...
ViennaCL: Querying devices available at c
Just adding my opinion here as I have been following this thread. Would it
be possible to have both the .so library and header only options available
or is it a strictly 'this-or-that' scenario?
Regards,
Charles
On Wed, Aug 17, 2016 at 2:53 PM, Karl Rupp wrote:
> Hi Dmitriy,
>
> > We could
Hi Charles,
> There is a fair amount of output, hopefully something here provides a
> clue that you can understand.
Ok, so let me explain the relevant messages:
> ViennaCL: Setting handle kernel argument 0xbac6690 at pos 0 for kernel
> assign_cpu
(...)
> ViennaCL: Setting handle kernel argument
Thanks for explanation Karl,
Running again and printing the cl_mem objects (from opencl_handle().get())
it appears that the relevant addresses (last three lines) are being used in
multiple areas such as 'Writing data'.
ViennaCL: Initializing context no. 1
ViennaCL: Initializing new ViennaCL conte
Hi Charles,
> Just adding my opinion here as I have been following this thread. Would
> it be possible to have both the .so library and header only options
> available or is it a strictly 'this-or-that' scenario?
a header-only version should be possible, but exposes the user to all
kinds of com
> Running again and printing the cl_mem objects (from
> opencl_handle().get()) it appears that the relevant addresses (last
> three lines) are being used in multiple areas such as 'Writing data'.
this may be the case, yes.
> trying dgemm
> 0xa84df00
> 0xa8b4c40
> 0xa8b5990
These are the correct
Ok, thanks, I will try asking those with clBLAS (I haven't started messing
with clMAGMA yet until I can get the clBLAS interface working). I will
report back if I manage to solve the problem.
Regards,
Charles
On Wed, Aug 17, 2016 at 3:16 PM, Karl Rupp wrote:
>
> Running again and printing the
14 matches
Mail list logo
