Hey hey, I admit I may have panicked a bit too much. After playing around with it a little more, I now understand why it reported different context ids.
*They weren't context ids, they were platform ids.* I was comparing my context counter to the viennacl::ocl::current_context().platform_index(). Those two are obviously completely different things. Context switching does work fine after all. Consequently, platform/device switching works fine too. Omg, this looks like the OpenCL SDK died. I had some other user report on a > similar topic on Windows, which I was never able to reproduce on Linux. Can > you please make sure that you use the latest drivers and OpenCL SDK? We > might have to file a bug report here... Now this is a completely different story. I'll try the newest OpenCL SDK and see what happens. Any chance you can send me the full output? Sure, I'll send it right away. This is a fallback mechanism: you can switch to *any* context ID you want. > If the context has been customized using setup_context() and friends, then > it will create the context with this customized setup. Otherwise it will > create a context with just the default device. This is mostly convenience > for multi-threaded use case scenarios or applications where totally > unrelated operations should be fed to different contexts (rather than just > command queues). Ah, I see. That's a nice feature now that I think about it. Is it documented somewhere in the manual? It might be a good idea to document it so people don't go nuts for no reason, like I did. Regards, Namik On Wed, Aug 13, 2014 at 10:24 PM, Karl Rupp <r...@iue.tuwien.ac.at> wrote: > Hi, > > > This error might be due to the ViennaCL-objects created in a >> different context. Do you recreate the ViennaCL-objects for each >> benchmark run? If so, there should be no such problem. >> >> >> Uhmmm, I don't think so. Anyways, that error is gone now that I'm using >> contexts in the proper way. >> > > Ok, I'll check this. > > > > I hope the user can't change the combo box values while the >> benchmark is running... >> >> >> It's only temporary for testing purposes. The real context switching >> will occur when the benchmark is started. >> > > Ah, ok :-) > > > > Yeah this is much better. Here's the new situation: >> I think there's no more duplicate contexts/devices. I've got 3 contexts: >> >> Context 0: AMD GPU using AMD SDK -works fine >> Context 1: CPU using AMD SDK -crashes >> Context 2: CPU using Intel SDK - works fine >> >> When using context 1, the program crashes with the following feedback: >> >> -in this particular run, the contexts were setup like this: >> Context id: 0 Context value: 0x87e168 Device name: Tahiti >> Context id: 1 Context value: 0x87e510 Device name: Intel(R) >> Core(TM) i5-2500K CPU @ 3.30GHz >> Context id: 2 Context value: 0x60051e8 Device name: Intel(R) >> Core(TM) i5-2500K CPU @ 3.30GHz >> >> -these two lines are my debug output: >> *1.* Benchmarking... Context id: 0 Context value: 0x87e510 >> *2.* Running on device name: Intel(R) Core(TM) i5-2500K CPU @ >> 3.30GHz >> >> -I'm getting the id >> with viennacl::ocl::current_context().platform_index() and context value >> with viennacl::ocl::current_context().handle().get() >> -Notice how it says the id is 0, even though it should be 1, while the >> context value is properly changed to the value of context 1. Also, >> running on context 2, it runs fine, but reports the id to be 1. What's >> the deal here? >> > > Ok, I'll check this myself, I'll need to have a look at the surrounding > code. > > > > -the rest is from ViennaCL: >> Build Status = -2 ( Err = -11 ) >> Log: Internal Error: Storing X86 DLL failed! >> > > Omg, this looks like the OpenCL SDK died. I had some other user report on > a similar topic on Windows, which I was never able to reproduce on Linux. > Can you please make sure that you use the latest drivers and OpenCL SDK? We > might have to file a bug report here... > > > > -then a lot of source code, with this in the middle: >> ViennaCL: FATAL ERROR: Could not find kernel >> >> -and finally, this: >> Number of kernels in program: 0 >> >> vec_mul' from program 'float_ell_matrix' >> >> Invalid parameter passed to C runtime function. >> >> Invalid parameter passed to C runtime function. >> >> terminate called after throwing an instance of 'char const*' >> > > Any chance you can send me the full output? > > > > OK scratch that. And scratch everything I've written so far. I just >> attempted to query contexts 4,5,6,... . And it unfortunately worked! I >> seem to have mysterious extra contexts! I'm totally confused now. >> >> Context id: 0 Context value: 0xc5e168 >> >> Context id: 0 Device name: Tahiti >> >> Context id: 1 Context value: 0xc5e510 >> >> Context id: 1 Device name: Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz >> >> Context id: 2 Context value: 0x61051e8 >> >> Context id: 2 Device name: Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz >> >> Context id: 3 Context value: 0xa9bdd90 >> >> Context id: 3 Device name: Tahiti >> >> Context id: 4 Context value: 0xa9be0a8 >> >> Context id: 4 Device name: Tahiti >> >> Context id: 5 Context value: 0xa9be3c0 >> >> Context id: 5 Device name: Tahiti >> >> Context id: 6 Context value: 0xa9be6d8 >> >> Context id: 6 Device name: Tahiti >> >> Context id: 7 Context value: 0xa9be9f0 >> >> Context id: 7 Device name: Tahiti >> >> and so on... >> >> What's going on here? >> > > This is a fallback mechanism: you can switch to *any* context ID you want. > If the context has been customized using setup_context() and friends, then > it will create the context with this customized setup. Otherwise it will > create a context with just the default device. This is mostly convenience > for multi-threaded use case scenarios or applications where totally > unrelated operations should be fed to different contexts (rather than just > command queues). > > Best regards, > Karli > >
------------------------------------------------------------------------------
_______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
