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
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-devel

Reply via email to