Hi, > 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.
It seems to me that your matrix A got created in the 'other' context (in this example: with ID 0) first. Automatic context migration is not supported, because that can cause quite a couple of undesired side effects. If you want to make sure that ['A' resides on the correct context, call .switch_memory_context(new_ctx) first. For your example: viennacl::context ctx(viennacl::ocl::get_context(ctx_id)); A.switch_memory_context(ctx); A = viennacl::matrix<T>(nr_in, nc_in, ctx); Best regards, Karli > > On Tue, May 10, 2016 at 10:54 AM, Charles Determan > <cdeterma...@gmail.com <mailto: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 > <mailto: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> > <mailto: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> > <mailto: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> > <mailto: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
