Hi Charles,
Once again, after spending so much time previously before messaging this
list I have now solved the problem shortly afterwards. In your
documentation section 'User-Provided OpenCL Contexts' I got the idea to
pull all the relevant information from the viennacl objects I am passing
to the functions. This way I can setup the context with the previously
existing context. The relevant code looks like this:
// viennacl::matrix *vcl_A
viennacl::ocl::context ctx = vcl_A->handle().opencl_handle().context();
cl_context my_context =
vcl_A->handle().opencl_handle().context().handle().get();
cl_device_id my_device =
vcl_A->handle().opencl_handle().context().devices()[0].id();
cl_command_queue queue =
vcl_A->handle().opencl_handle().context().get_queue().handle().get();
viennacl::ocl::setup_context(0, my_context, my_device, queue);
Now I can still use the 'ctx' object as needed and the context for the
'enqueue' call is using the correct context.
Thanks for responding and for creating the documentation. I always seem
to find another useful nugget.
great to hear that you found a fix :-)
Based on your description, I think the reason for these troubles is the
singleton used for the context. If everything is compiled as a single
library, the singleton (a static member) is working just fine. However,
if you compile the user-provided code separately, you may end up with a
separate shared library that duplicates the singleton (and thus two
contexts get created). Whether or not this is the case depends on how
you implemented the just-in-time compilation - at least it seems like
the most plausible cause.
Best regards,
Karli
On Wed, Jul 26, 2017 at 10:10 AM, Karl Rupp <[email protected]
<mailto:[email protected]>> wrote:
Hi Charles,
can you point me to the code that exposes the problem? The OpenCL
error indicates that the memory object passed in is not correct, so
maybe there is indeed a second context in play that should not be there.
Best regards,
Karli
On 07/26/2017 08:58 AM, Charles Determan wrote:
I have an interesting problem. In the context of developing
additional functionality for the gpuR package I want to have the
option for users to provide a custom OpenCL kernel that will
compile and provide a function that can immediately be used
within R. I am quite close where I can dynamically create the
necessary C++ files, compile, and load the function. This leads
to my current problem.
If I take a kernel that currently works within the package and
use it to create this custom function the following happens. I
can get the previously initialized matrices from the context
index I pass (i.e. I can print them). This made me believe that
I can use my previously defined contexts and objects. But when
I get to the 'viennacl::ocl::enqueue' call of the kernel
function it throws the error which I thought I read meant the
contexts weren't matching but I'm not sure where the disconnect is.
ViennaCL: Error -38 in function arg (
path/to/R/R-3.4.0/library/RViennaCL/include/viennacl/ocl/kernel.hpp:239
)
Error in cpp_gpuMatrix_custom_igemm(igpuA@address, TRUE,
igpuB@address, :
ViennaCL: FATAL ERROR: CL_INVALID_MEM_OBJECT.
If you think that this is a bug in ViennaCL, please report it at
[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>> and supply at
least the following information:
* Operating System
* Which OpenCL implementation (AMD, NVIDIA, etc.)
* ViennaCL version
Many thanks in advance!
Running with VIENNACL_DEBUG_ALL I get the following output:
ViennaCL: Initializing context no. 0
ViennaCL: Initializing new ViennaCL context.
ViennaCL: Setting all devices for context...
ViennaCL: Getting platform...
ViennaCL: Querying devices available at current platform.
ViennaCL: Found 1 devices.
ViennaCL: Creating device object (CTOR with cl_device_id)
ViennaCL: Creating device object (Copy CTOR)
ViennaCL: Number of devices for context: 1
ViennaCL: Creating device object (Copy CTOR)
ViennaCL: Initialization of new ViennaCL context done.
ViennaCL: Creating device object (Copy CTOR)
ViennaCL: Creating device object (Copy CTOR)
ViennaCL: Adding new queue for device 0x2e2a00 to context 0x21847b40
ViennaCL: Context no. 0 initialized with 1 devices
ViennaCL: Device id: 0x2e2a00
ViennaCL: Creating device object (Copy CTOR)
ViennaCL: Adding program 'my_kernel' with source to context
0x21847b40
ViennaCL: Creating kernel object (full CTOR): iMatMult
ViennaCL: Stored program 'my_kernel' in context 0x21847b40
ViennaCL: There is/are 1 program(s)
ViennaCL: Getting program 'my_kernel' from context 0x21847b40
ViennaCL: There are 1 programs
ViennaCL: Setting global work size to 128 at index 0 for kernel
iMatMult
ViennaCL: Setting global work size to 128 at index 1 for kernel
iMatMult
ViennaCL: Setting local work size to 16 at index 0 for kernel
iMatMult
ViennaCL: Setting local work size to 16 at index 1 for kernel
iMatMult
ViennaCL: Setting int precision kernel argument 4 at pos 0 for
kernel iMatMult
ViennaCL: Setting int precision kernel argument 128 at pos 1 for
kernel iMatMult
ViennaCL: Setting int precision kernel argument 4 at pos 2 for
kernel iMatMult
ViennaCL: Setting int precision kernel argument 128 at pos 3 for
kernel iMatMult
ViennaCL: Setting generic kernel argument 0x1f59f720 at pos 4
for kernel iMatMult
I initially see that it is 'initializing context 0' when it was
previously initialized within the main 'gpuR' package. Perhaps
this is okay, provided it is initialized in the same way? Or
perhaps I need to find a way to carry the previous context
between functions (e.g. an external pointer).
Any thoughts are appreciated,
Charles
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
ViennaCL-support mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/viennacl-support
<https://lists.sourceforge.net/lists/listinfo/viennacl-support>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
ViennaCL-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-support
