Karl,
One last followup question on this line of thought. I seem to be able to
use the direct context in most of my functions but I am having trouble when
I try to assign a previously declared class variable.
In my class dynVCLMat (
https://github.com/cdeterman/gpuR/blob/develop/inst/include/gpuR/dynVCLMat.hpp)
I have 'A' declared as a viennacl::matrix
I can assign this object with a new matrix:
viennacl::context
ctx(viennacl::ocl::get_context(static_cast<long>(ctx_id)));
A = viennacl::matrix<T>(nr_in, nc_in, ctx);
This normally works fine as long as the 'ctx_id' is the current context.
If it isn't (say the ctx_id is '1' when the current context is '0'), then I
get the error:
>Error: ViennaCL: FATAL ERROR: CL_INVALID_MEM_OBJECT
I'm trying to purge away my 'setContext()' calls within functions so they
can fork safely but this doesn't appear to behave the way I was expecting.
Regards,
Charles
On Tue, May 10, 2016 at 10:54 AM, Charles Determan <cdeterma...@gmail.com>
wrote:
> That does it, didn't think to look for an explicit context.hpp file.
> Makes sense that the it is with the matrix.hpp file now.
>
> Thanks again,
> Charles
>
> On Tue, May 10, 2016 at 9:07 AM, Karl Rupp <r...@iue.tuwien.ac.at> wrote:
>
>> Hi,
>>
>> > After poking around with different headers it appears I need one of the
>>
>>> object type files such as "viennacl/matrix.hpp" in order to declare
>>> viennacl::context objects. Shouldn't this be possible from just
>>> "viennacl/ocl/backend.hpp"? Just curious on the design at this point.
>>>
>>
>> have you tried to include viennacl/context.hpp directly?
>>
>> Best regards,
>> Karli
>>
>>
>>
>> On Tue, May 10, 2016 at 8:40 AM, Charles Determan <cdeterma...@gmail.com
>>> <mailto:cdeterma...@gmail.com>> wrote:
>>>
>>> Excellent, thank you for explaining that. One followup thing, I am
>>> trying a trivial function to test this:
>>>
>>> int findContext(int x){
>>> viennacl::context
>>> ctx(viennacl::ocl::get_context(static_cast<long>(x)))
>>> return x
>>> }
>>>
>>> but I keep getting a compiler error:
>>>
>>> >error: variable ‘viennacl::context ctx’ has initializer but
>>> incomplete type
>>>
>>> Did I miss something?
>>>
>>> Thanks,
>>> Charles
>>>
>>>
>>> On Mon, May 9, 2016 at 4:09 PM, Karl Rupp <r...@iue.tuwien.ac.at
>>> <mailto:r...@iue.tuwien.ac.at>> wrote:
>>>
>>> Hi Charles,
>>>
>>> setContext() is not thread-safe, so if mclapply() is executing
>>> in parallel, there will be a race. MPI works across processes,
>>> so globals are not shared (and hence setContext() has no
>>> problems).
>>>
>>> If you want to run multithreaded, you should manage the contexts
>>> explicitly. That is, pass a viennacl::context object to the
>>> respective constructors of viennacl::vector, viennacl::matrix,
>>> etc. You can find examples here:
>>>
>>> https://github.com/viennacl/viennacl-dev/blob/master/examples/tutorial/multithreaded.cpp
>>>
>>> https://github.com/viennacl/viennacl-dev/blob/master/examples/tutorial/multithreaded_cg.cpp
>>>
>>> Best regards,
>>> Karli
>>>
>>>
>>>
>>>
>>> On 05/09/2016 10:32 PM, Charles Determan wrote:
>>>
>>> I am trying to use multiple GPU's in parallel using ViennaCL
>>> through my
>>> gpuR package. In essence the context is selected at the R
>>> level (one
>>> context per device already initialized). Then a matrix is
>>> created on
>>> that device. The code looks like this:
>>>
>>> create_matrix <- function(id){
>>> # sets context
>>> setContext(id)
>>> # create matrix
>>> mat <- vclMatrix(rnorm(16), nrow=4, ncol=4)
>>> return(mat)
>>> }
>>>
>>> # a fork over context 1 and 2
>>> out <- mclapply(1:2, function(x) create_matrix(x))
>>>
>>> Yet, strangely this just hangs. It doesn't return
>>> anything. Perhaps I
>>> am missing something in how OpenCL contexts are handed in
>>> parallel? I
>>> ask as I recall that PETSC had some multi GPU functionality
>>> with MPI.
>>> The above makes sense to me without MPI but again I may be
>>> missing
>>> something.
>>>
>>> The actual copying happens in this file at line 36
>>> (
>>> https://github.com/cdeterman/gpuR/blob/develop/src/dynVCLMat.cpp)
>>> just
>>> after "starting to copy". It seems almost like it a problem
>>> with the
>>> class objects (defined in
>>>
>>> https://github.com/cdeterman/gpuR/blob/develop/inst/include/gpuR/dynVCLMat.hpp
>>> ).
>>>
>>> Any insight would be appreciated.
>>>
>>> Regards,
>>> Charles
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Mobile security can be enabling, not merely restricting.
>>> Employees who
>>> bring their own devices (BYOD) to work are irked by the
>>> imposition of MDM
>>> restrictions. Mobile Device Manager Plus allows you to
>>> control only the
>>> apps on BYO-devices by containerizing them, leaving personal
>>> data untouched!
>>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>>>
>>>
>>>
>>> _______________________________________________
>>> ViennaCL-devel mailing list
>>> ViennaCL-devel@lists.sourceforge.net
>>> <mailto:ViennaCL-devel@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/viennacl-devel
>>>
>>>
>>>
>>>
>>>
>>
>
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
