+- +-
Say hello if visiting :) by Gecko
11 Jan 2023, 07:43:05 pm

Seti is down again by Mike
09 Aug 2017, 10:02:44 am

Some considerations regarding OpenCL MultiBeam app tuning from algorithm view by Raistmer
11 Dec 2016, 06:30:56 am

Loading APU to the limit: performance considerations by Mike
05 Nov 2016, 06:49:26 am

Better sleep on Windows - new round by Raistmer
26 Aug 2016, 02:02:31 pm

Author Topic: Recent Driver Cuda-safe Project List  (Read 39984 times)

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: Recent Driver Cuda-safe Project List
« Reply #15 on: 21 Nov 2011, 03:13:00 pm »
Anything to add to Slicker's reply Jason?

  Sounds great.  Perhaps just mention that any kind of exit, such as early exits or error outs etc, should be handled in such a way that the device gets its synchronisation before quitting...   In the case of Seti it just meant handling 2 x early exit conditions & changing a macro used for error outs ( SETIERROR(...)  )

That just makes sure that in every possible exit case (except hard terminateProcess() via task manager etc, which cannot be protected from), that there aren't any transfers or kernels in progress.  My own implementation was semantically different to David's, but either way should be manageable as long as the process isn't killed underneath the working GPU.

[Edit:] for GPUs, IIRC they always fully exit on snooze, & a suspend message isn't used, but could indeed be something to double check if it needs handling as well.

« Last Edit: 21 Nov 2011, 03:17:06 pm by Jason G »

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: Recent Driver Cuda-safe Project List
« Reply #16 on: 02 Mar 2012, 02:23:47 am »
Updated first post, due to mentions of cross project sticky downcock woes on number crunching:
Update: March 2nd 2012
Unfortunately the message about sticky downclocks caused by non-threadsafe application exit behaviour hasn't apparently been getting out enough for users.  The Cuda 4.1 Toolkit release notes text file contains  a fairly concise description of the issues at hand, suitable for developers, relating directly to later drivers & proper application termination.
* The CUDA driver creates worker threads on all platforms, and this can cause issues at process cleanup in some multithreaded applications on all supported operating systems.
On Linux, for example, if an application spawns multiple host pthreads, calls into CUDART, and then exits all user-spawned threads with pthread_exit(), the process may never terminate. Driver threads will not automatically exit once the user's threads have gone down.
The proper solution is to either:
(1) call cudaDeviceReset()* on all used devices before termination of host threads, or,
(2) trigger process termination directly (i.e, with exit()) rather than relying on the process to die after only user-spawned threads have been individually exited.
*note that the Cuda 3.2 equivalent of cudaDeviceReset() is cudaThreadExit()


Welcome, Guest.
Please login or register.
Forgot your password?
Total Members: 97
Latest: ToeBee
New This Month: 0
New This Week: 0
New Today: 0
Total Posts: 59559
Total Topics: 1672
Most Online Today: 25
Most Online Ever: 983
(20 Jan 2020, 03:17:55 pm)
Users Online
Members: 0
Guests: 12
Total: 12
Powered by EzPortal