The other option is to build the app to refer to the physical name (e.g. cufft_win32_10.dll) rather than cufft.dll Then you wouldn't have to copy it to the slot dir. -- David
On 09-Dec-2011 12:24 AM, Raistmer wrote: > Some of CUDA supporting DLLs (CUFFT for example) are quite big ~10MB in size. > To copy such sizes few times (cause running few tasks per GPU is common > practice > fir fast GPUs) per time interval ~mins (and VHAR SETI task computes in 2 mins > even on relatively old CUDA GPU) will give big stress on HDD subsystem and > definitely negatively affect host performance. > To copy such sizes per WU basis should not be considered as solution IMHO. > ----- Original Message ----- > *From:* Rom Walton <mailto:[email protected]> > *To:* David Anderson (BOINC) <mailto:[email protected]> ; > [email protected] <mailto:[email protected]> ; Eric Korpela > <mailto:[email protected]> > *Sent:* Friday, December 09, 2011 5:02 AM > *Subject:* Re: [boinc_dev] Server chooses wrong plan class for work allocation > > I thought both the executable and supporting DLLs needed to have the > <copy_file/> attribute on Windows. > > In that case the process would be launched from the slot directory and > the dll loaded from the slot directory. > > ----- Rom > > -----Original Message----- > From: [email protected] > <mailto:[email protected]> > [mailto:[email protected]] On Behalf Of David Anderson > Sent: Thursday, December 08, 2011 4:00 PM > To: [email protected] <mailto:[email protected]>; Eric > Korpela > Subject: Re: [boinc_dev] Server chooses wrong plan class for work > allocation > > Interesting! > According to MS docs > (http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx) > the search order for DLLs is: > 1) The directory where the executable module for the current process is > located. > 2) The current directory. > 3) ... some other directories > > In our case, 1) is the project directory and 2) is the slot directory. > So the cuda23 app is being linked with the pre-2.3 versions of both > cudart.dll and cufft.dll. > There's a collision between the physical names of the 'cuda' DLLs and > the logical names of the 'cuda32' DLLs. > > The solution is change physical names of the 'cuda' version DLLs. > SETI@home <mailto:SETI@home> needs to deploy a new app version for plan class > 'cuda' > where the FFT lib has: > physical name: cufft_10.dll > logical name: cufft.dll > copy_file: true > > ... and similarly for cudart.dll > > I'll update the docs to reflect this. > > ----------- > > Linux: here we have control over the search order. > For compatibility with Windows, we use the same order (project dir, slot > dir, other). > So the Linux 'cuda' versions need to be changed as above also. > > -- David > > > On 08-Dec-2011 12:07 PM, Richard Haselgrove wrote: > > Further investigation on this. I may have been getting work allocated > > with plan_class 'cuda', instead of 'cuda23', because the processing > > speeds were not as differentiated as they should have been. > > > > This is because DLLs from the wrong plan_class were being used. > > > > This may be specific to the SETI CUDA implementation, as originally > > supplied by NVIDIA to kick-start CUDA on BOINC, but the cautionary > > lesson may be helpful to other projects too. > _______________________________________________ > boinc_dev mailing list > [email protected] <mailto:[email protected]> > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ > boinc_dev mailing list > [email protected] <mailto:[email protected]> > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
