I think a lot of users do upgrades the same basic way that I do... That is, I save parts both because many times I cannot find someplace worthy to send the cast-offs and in other cases they are not necessariiy worth that much ... that said, I have examples where during upgrades I find "spare" places for seemingly old and useless parts in another machine.
As an example I have three Nvidia cards in my suite with only two installed... when I upgrade to my next CPU and MB combination I am hoping to move from 2 GPU slots max to three or four ... meaning that I could very well face the possibility that I could not fill all of those slots with up-to-date GPUs ... but I may very well, and probably will have some old GPUs that are still functional on the shelf ... and they are likely to be put back into service ... And, as I have demonstrated that for the most part Win7 does function well with both ATI and Nvidia cards side by side ... well, that means that my days of mix and match are not likely to end soon ... I tried very hard in the early days of GPU computing to make this point, users are not going to want to lightly have to toss GPUs that cost hundreds of dollars ... and as powerful as even the low end of these processors are, we would be remiss if we did not facilitate to the greatest extent possible the potentials here ... On May 17, 2010, at 12:57 PM, Raistmer wrote: >> I'd imagine a user would install either an >> NVIDIA or an ATI driver. Either way the project doesn't have to include >> a suitable OpenCL.dll file with the application. > >> -Kamran > > Even now there are users with both NV and ATI GPUs installed into single > host. > I would not await that number of such users will decrease, quite reverse can > be true. > For now we at Lunatics team were not able to make ATI AP work on NV + ATI > GPUs host. > NV GPU had to be removed to ATI GPU start to work OK. But ultimately app > should be able to function when both GPUs installed. > I keep in mind such situation while providing OpenCL.DLL along with app > binaries itself. > But how to manage this when same project would be able to use OpenCL on > both types of GPUs?... 2 OpenCL.DLL in single project directory - not good > solution :) > > > -----Original Message----- > From: Raistmer [mailto:[email protected]] > Sent: Saturday, May 15, 2010 1:11 AM > To: Kamran Karimi; David Anderson > Cc: [email protected] > Subject: Re: [boinc_dev] BOINC now supports OpenCL > > Do you have OpenCL for ATI GPUs already? > The problem of shipping OpenCL.dll with app strats when both SDKs (and > both > DLLs ) present on user PC. > NV OpenCL.dll resides in system32 (that is, "system" file, no need to > distribute indeed) but it can't handle ATI's OpenCL library calls. > > ----- Original Message ----- > From: "Kamran Karimi" <[email protected]> > To: "David Anderson" <[email protected]> > Cc: <[email protected]> > Sent: Saturday, May 15, 2010 2:19 AM > Subject: Re: [boinc_dev] BOINC now supports OpenCL > > >> BTW there was no need to supply any OpenCL.dll files with the app. We >> sent the OpenCL kernel source to volunteer computers and compiled it > at >> execution time with no problem. >> >> In short, things worked smoothly. >> >> -Kamran >> >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Kamran Karimi >> Sent: Friday, May 14, 2010 3:15 PM >> To: David Anderson >> Cc: [email protected] >> Subject: [boinc_dev] BOINC now supports OpenCL >> >> I am happy to report that we successfully tried an NVIDIA OpenCL test >> version of our AQUA app on volunteer computers. >> >> There is no way to know for sure whether people who ran the work units >> on their computers had OpenCL SDKs or not, but we didn't see any >> failures, which means that every user with the appropriate NVIDIA > driver >> version (197.13+) who downloaded the OpenCL app ran it successfully to >> completion. >> >> We have an ATI OpenCL test version of the app too. We can try it ASA > the >> appropriate application plan is functional. >> >> -Kamran >> >> >> -----Original Message----- >> From: David Anderson [mailto:[email protected]] >> Sent: Wednesday, May 12, 2010 8:09 PM >> To: Kamran Karimi >> Cc: [email protected] >> Subject: Re: [boinc_dev] OpenCL support? >> >> I added plan classes cuda_opencl (misnomer, sorry) and ati_opencl. >> The former requires driver version 197.13+; >> the latter is a stub that never matches. >> >> -- David >> >> Kamran Karimi wrote: >>> Thanks for the clarification. >>> >>> I would appreciate it if you could do the app_plan() modifications to >>> make sure opencl_nvidia is available to everybody for testing. >>> >>> -Kamran >>> >>> >>> -----Original Message----- >>> From: David Anderson [mailto:[email protected]] >>> Sent: Wednesday, May 12, 2010 3:22 PM >>> To: Kamran Karimi >>> Cc: [email protected] >>> Subject: Re: [boinc_dev] OpenCL support? >>> >>> Kamran Karimi wrote: >>>> We also have two versions of our aqua app for NVIDIA and ATI. They >> run >>>> when invoked manually, and accept a "--device" argument to determine >>>> which GPU to use (as provided to cuda apps before, but I can't find >>> this >>>> argument in the sched_customize.cpp file any more). >>> >>> It's not supplied by the scheduler. >>> It's supplied by the client, after it decides which GPU to use. >>> >>>> We can try the apps >>>> under BOINC when it can detect and report OpenCL's presence. >>> >>> You can try them right now; >>> just define an opencl_nvidia plan class, >>> and add a clause to app_plan() in which you check for >>> driver version 197.13 or later. >>> I can add this if you want. >>> >>> ATI: we need to wait until ATI includes OpenCL support in their >> driver. >>> Asking volunteers to install an SDK, >>> and having the client check for it, is not viable. >>> >>> -- David >>> >> >> _______________________________________________ >> 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. >> _______________________________________________ >> 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. >> > > _______________________________________________ > 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. _______________________________________________ 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.
