Hey Karl,
Most importantly, it is necessary to run the context setup before any of
> the ViennaCL objects are created. Also, setup_context() takes the context
> ID as the first argument, not the platform ID.
You only have one device per context, so there is no need to switch the
> device. 'deviceNumber' will always be zero if you only have one device per
> context. Remove the second line.
You're right. I was initially experimenting with cl_platform_id and
cl_device_id before I found out using contexts was the proper way to do it.
I had some leftover logic from using cl_platform|device_id when I started
using contexts, so that's where the platform id usage came from.
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.
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.
Ok, here's how it should work:
> context_ctr = 0;
> platforms_type platforms = viennacl::ocl::get_platforms();
> for (platform_id = 0; platform_id < platforms.size(); ++platform_id )
> {
> devices_type devices = platform_iter->devices(CL_DEVICE_TYPE_ALL);
> for(devices_type::iterator iter = devices.begin();
> iter != devices.end(); iter++)
> {
> viennacl::ocl::set_context_platform_index(context_ctr, platform_id);
> viennacl::ocl::setup_context(context_ctr, *iter);
> ++context_ctr;
> }
> }
For you case of a system with AMD GPU and both Intel and AMD SDKs
> installed, this gives you:
> Context 0: AMD GPU using AMD SDK
> Context 1: CPU using AMD SDK
> Context 2: CPU using Intel SDK
> (assuming that the AMD SDK is platform 0)
> Now you should be able to switch context as needed via
> viennacl::ocl::switch_context(0); // AMD GPU
> viennacl::ocl::switch_context(1); // CPU with AMD SDK
> viennacl::ocl::switch_context(2); // CPU with Intel SDK
>
If you still run into issues, please let us know, then this requires fixing
> in ViennaCL.
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?
-the rest is from ViennaCL:
Build Status = -2 ( Err = -11 )
Log: Internal Error: Storing X86 DLL failed!
-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*'
Can you provide a test case where the code silently creates a context even
> though it should not? If you really want to manage your own context and
> stuff, you will add a lot of (imho unnecessary) code to the GUI just for
> managing the OpenCL layer. Keep in mind that the code with the least
> maintenance effort is the code which isn't there...
Yes, it can be done, but you really should *not* do this, since you are not
> running any OpenCL operations outside ViennaCL.
I guess it's better to stay away from custom context creation. As for the
silent context, it's no longer an issue (I think).
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?
Regards, Namik
On Wed, Aug 13, 2014 at 3:08 PM, Toby St Clere Smithe <[email protected]>
wrote:
> Hi all,
>
> Karl Rupp <[email protected]> writes:
> >> I looked at Chap. 10, but didn't find a way to disable the auto context
> >> creation. I wish to disable it because it would make interaction with
> >> the UI a lot easier. Since the auto(0) context fails to add all devices,
> >> and I'm creating additional contexts (and one of those is bound to be
> >> the same as the one automatically created) , that complicates things
> >> when interacting with the UI.
> >
> > Can you provide a test case where the code silently creates a context
> > even though it should not? If you really want to manage your own context
> > and stuff, you will add a lot of (imho unnecessary) code to the GUI just
> > for managing the OpenCL layer. Keep in mind that the code with the least
> > maintenance effort is the code which isn't there...
>
> I would also be interested to see this, because I thought I'd eliminated
> all of these false contexts!
>
> Cheers,
>
> Toby
>
>
> --
> Toby St Clere Smithe
> http://tsmithe.net
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> ViennaCL-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/viennacl-devel
>
------------------------------------------------------------------------------
_______________________________________________
ViennaCL-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
