Forum > Discussion Forum

Recent Driver Cuda-safe Project List

<< < (4/4)

Jason G:

--- Quote from: Claggy on 21 Nov 2011, 03:02:07 pm ---Anything to add to Slicker's reply Jason?

Claggy

--- End quote ---
  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.

Jason

Jason G:
Updated first post, due to mentions of cross project sticky downcock woes on number crunching:

--- Quote ---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.

--- Quote ---* 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.
--- End quote ---
*note that the Cuda 3.2 equivalent of cudaDeviceReset() is cudaThreadExit()
--- End quote ---

Navigation

[0] Message Index

[*] Previous page