Hey, > After talking earlier about switch_context() and current_context(), I'm > not sure why I should have to call these explicitly in most cases. If > I'm performing an operation on two objects (both explicitly constructed > with the same context), shouldn't ViennaCL implicitly switch_context() > so that the current_context is that of the two objects in the operation? > > In this case, I'm copying data to a vector, and the device-specific > kernel uses current_context() (which returns a different context to that > with which the vector was constructed, thus giving an invalid command > queue). Shouldn't the relevant dispatch function compare > current_context() with that of the operand(s), and if current_context() > is different, call switch_context()? Is there any case where this > wouldn't work, and switch_context() would need to be called by the user > explicitly? I think we should be able to assume that the user will > always provide operands each with the same context; at least, I > guarantee that this is the case in PyViennaCL.
This is a matter of explicit vs. implicit. Assume the following (pseudo-)code: viennacl::context ctx1(...); viennacl::context ctx2(...); viennacl::vector<T> x(10, ctx1); viennacl::vector<T> y(10, ctx2); viennacl::vector<T> z(10, ctx2); At this point the user *explicitly* created the vectors in the two different contexts. Now let's continue with the current behavior: y += z; // okay x = y; // error, not in same context y += z; // still okay In order to make 'x = y;' a valid expression, the user would have to explicitly migrate y to ctx1. Now let's look at the same code with an implicit transfer: y += z; // okay x = y; // y implicitly migrated to ctx1 y += z; // y in ctx1 -> z also migrated to ctx1 in the end, all three vectors end up in ctx1, even though the user explicitly created them in two different contexts. Surprising? The primary reason why an explicit switch_context() is currently in place is that I haven't thought through all such possible obstacles and how do handle these in the least error-prone way, hence used this conservative approach. On the other hand, I agree that it is often convenient to just implicitly transfer data between contexts. What we can use in the future is to allow implicit context switches, yet provide a debug facility which triggers warnings if a context is switched implicitly. This could be a preprocessor define, or (more flexible) a member variable which prints to an ostream, or even a callback function. Best regards, Karli ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ ViennaCL-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/viennacl-devel
