Hey hey, Philippe Tillet <phil.til...@gmail.com> writes: > ViennaCL's core cannot switch_context() internally because the context is > not registered in the backend. We could querry the necessary information > using the OpenCL API and create the appropriate queues/devices/programs for > registering the context, though, since the handles are accessible through > the OpenCL API.
Aha, but if I *have* constructed and registered the context in the backend, then all the hard work is done, and the only thing that needs doing is to switch the current context id. Then it would seem easier to do this implicitly in a central location (if there is one), than for the user to have to keep track. In the case of PyViennaCL, because there are so many ways of calling ViennaCL operations, I'm now worried that I'll have to add a context check-and-switch whenever a ViennaCL call is made using the OpenCL backend. It just seems like this should be redundant: why isn't the current context just always the one associated with the operands of a given operation? > The generator using current_context() is an error. The context should be an > argument and the linalg operations should pass the vector's context. I'll > fix this tonight. I've been busy with other things today :) Right-ho, no problem :) Toby > Philippe > > > 2014-07-03 18:25 GMT+02:00 Toby St Clere Smithe <m...@tsmithe.net>: > >> Hey Philippe, all, >> >> 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. >> >> Cheers, >> >> Toby >> >> -- Toby St Clere Smithe http://tsmithe.net ------------------------------------------------------------------------------ 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 ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
