Initialisation problems
5 posts
• Page 1 of 1
Re: Initialisation problems
Hi Dave,
We're going to take a day to try to reproduce and we'll get back to this thread with our thoughts. I think we have enough information here, but we will reply with questions if we don't.
John
We're going to take a day to try to reproduce and we'll get back to this thread with our thoughts. I think we have enough information here, but we will reply with questions if we don't.
John
- john
- Administrator
- Posts: 587
- Joined: Thu Jul 23, 2009 2:31 pm
Re: Initialisation problems
Hi John
Much appreciated.
Cheers
Dave
Much appreciated.
Cheers
Dave
- d_hastie
- Posts: 3
- Joined: Tue Nov 30, 2010 10:14 am
Re: Initialisation problems
Hi Dave,
I think the reason you're running into some errors here is because of the nature of how CUDA 3.2 and earlier assign threads to a device. CUDA imposes a restriction where a single thread can only be bound to one device, and once bound, you cannot change the device to which it is bound, unless you call cudaThreadExit (note that in CUDA 4 this restriction will be lifted completely). This leads to the requirement that multi-GPU programs be multi-threaded.
I don't think that the cudaThreadExit solution that you outlined will work robustly, because once you call cudaThreadExit you've destroyed the context that you had previously created for the currently bound device, which in turn leads to zero concurrency between the two devices.
The best way to solve this problem is to create multiple threads for each job that you want to issue. The multigpu example in our SDK shows how to call culaSelectDevice and culaInitialize in each thread. You could also wait until CUDA 4 (and the corresponding CULA version) is released, but this solution will solve your problem right now.
Dan
I think the reason you're running into some errors here is because of the nature of how CUDA 3.2 and earlier assign threads to a device. CUDA imposes a restriction where a single thread can only be bound to one device, and once bound, you cannot change the device to which it is bound, unless you call cudaThreadExit (note that in CUDA 4 this restriction will be lifted completely). This leads to the requirement that multi-GPU programs be multi-threaded.
I don't think that the cudaThreadExit solution that you outlined will work robustly, because once you call cudaThreadExit you've destroyed the context that you had previously created for the currently bound device, which in turn leads to zero concurrency between the two devices.
The best way to solve this problem is to create multiple threads for each job that you want to issue. The multigpu example in our SDK shows how to call culaSelectDevice and culaInitialize in each thread. You could also wait until CUDA 4 (and the corresponding CULA version) is released, but this solution will solve your problem right now.
Dan
- dan
- Administrator
- Posts: 61
- Joined: Thu Jul 23, 2009 2:29 pm
5 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 3 guests