Message boards :
Number crunching :
I've Built a Couple OSX CUDA Apps...
Message board moderation
Previous · 1 . . . 31 · 32 · 33 · 34 · 35 · 36 · 37 . . . 58 · Next
Author | Message |
---|---|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
If you've already downloaded the 6.5 Toolkit just use unpack to Expand the package. Then look in the cuda_6.5.27_mac_64/lib folder for the libcudart.6.5.dylib and libcufft.6.5.dylib libraries. The easiest way to obtain the libraries now is to go to Beta and have Beta download the libraries to the setiweb.ssl.berkeley.edu_beta folder for you. |
Zalster Send message Joined: 27 May 99 Posts: 5517 Credit: 528,817,460 RAC: 242 |
got it, thanks |
TimeLord04 Send message Joined: 9 Mar 06 Posts: 21140 Credit: 33,933,039 RAC: 23 |
Well, I TRIED to run SOG on Beta... BOINC set to run 2 Units at a time per card, and while Elapsed Time incremented; Remaining Time did NOT decrease on the Units. Instead, Remaining Time fluctuated WILDLY going from 18 Min. to 1 Hr and 13 Min. and back again... This also had an effect on Progress Percentage going from 18% to 70+% and back again... So, I've Aborted ALL SOG at Beta. Perhaps because they also use OpenCL that this could be the contributing factor...???... I won't be allowing those to run anymore on my system. :-( TL P.S. Report on the CUDA75 that the system first worked on... NO Errors, NO Invalids. Low Inconclusives... CUDA75 ROCKS!!!!! :-) Have completed over 40 of them with these results. :-) I have four CUDA75 Units still in queue. These will be completed tomorrow. TimeLord04 Have TARDIS, will travel... Come along K-9! Join Calm Chaos |
Chris Adamek Send message Joined: 15 May 99 Posts: 251 Credit: 434,772,072 RAC: 236 |
That's actually normal behavior for SoG. It does almost all of its work on the GPU and doesn't report its progress the same way the other types of apps do. Boinc doesn't know what to make of that so it appears as if the progress is bouncing around. It was likely progressing normally. Chris |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13841 Credit: 208,696,464 RAC: 304 |
Well, I TRIED to run SOG on Beta... BOINC set to run 2 Units at a time per card, and while Elapsed Time incremented; Remaining Time did NOT decrease on the Units. Instead, Remaining Time fluctuated WILDLY going from 18 Min. to 1 Hr and 13 Min. and back again... This also had an effect on Progress Percentage going from 18% to 70+% and back again... So, I've Aborted ALL SOG at Beta. Perhaps because they also use OpenCL that this could be the contributing factor...???... If it's the first time running those applications it will take a while for things to settle down & estimated run times to be closer to actual run times, and for the display for work done & to be done to settle down. Grant Darwin NT |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
The Updated version of x41p_zi is now posted at C.A. for those with compatible GPUs. The App will only work on GPUs with Compute Capability 3.2 and higher, you can check the Compute Capability here, https://en.wikipedia.org/wiki/CUDA#GPUs_supported Be sure to checkout the Notes file in the docs folder, this App should be run ONE task at a time per GPU. As before, paste the files in the expanded Special_CUDA75-ComputeCode3.2+ folder and the CUDA Libraries libcudart.6.5.dylib & libcufft.6.5.dylib into /Library/Application Support/BOINC Data/projects/setiathome.berkeley.edu and then run the BOINC installer to set the correct file permissions. If you are not currently running the CUDA75 or CUDA65 package under Anonymous platform you should finish the existing tasks before installing this package. The package contains the CPU SSE41 App and the Special nVidia CUDA75 App. Special_CUDA75-ComputeCode3.2+.zip |
Juha Send message Joined: 7 Mar 04 Posts: 388 Credit: 1,857,738 RAC: 0 |
Jason, Are you going to check in the missing include? |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
Jason, For the alpha ? just committed what was given, but will look if missed a file. Or you're referring to the stock main ? "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
Juha Send message Joined: 7 Mar 04 Posts: 388 Credit: 1,857,738 RAC: 0 |
Referring to #include "version.h" Which was needed for my 7.5 API compatibility patch to work. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
Referring to Odd, mine picks up the version definitions from boinc's version.h (which is where I would have expected) /* Major part of BOINC version number */ and the requisite app_init_data structure from boinclib's app_ipc.h, via seti.h (which contains gCUDADevPref). Naturally the patch is inactive for me, but I don't see anything missing ? [Edit:] Oh I see perhaps... linux path [and windows/vc being too smartarsed...] "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
Juha Send message Joined: 7 Mar 04 Posts: 388 Credit: 1,857,738 RAC: 0 |
Odd, mine picks up the version definitions from boinc's version.h (which is where I would have expected) And that's the one to include. Are you sure yours is really picking up BOINC's version.h without the #include ? Btw, we already had this discussion over at Beta. Just how much vodka you had? :P |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
Odd, mine picks up the version definitions from boinc's version.h (which is where I would have expected) None :(, but as per last minute edit: Probably just Windows/VC being too clever (It also builds on Visual studio with clean checkout just now ;) ) I'll force a #include "version.h" in main above anyway, as can't be bothered figuring out how visual studio magically knows about that file, to take me to the definitions on right-click in main.cpp, lol. "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
Juha Send message Joined: 7 Mar 04 Posts: 388 Credit: 1,857,738 RAC: 0 |
Like I said, in pre-processor tests, unknown identifiers are replaced with zero: #if GHRWJYJKGOWF > 5 gerhguih #endif compiles just fine even when you don't have that G... defined. Conditional inclusion |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
Like I said, in pre-processor tests, unknown identifiers are replaced with zero: I realise that part, though not how visual studio was finding the reference :) [taking me straight to the correct file] (not even forced includes in the solution) Anyway done. Next I'll have to go look at this conversation I must have had while asleep :D [Edit:] Done, yeah blaming m$ for making it work when it shouldn't have. Those macros (6.2) come defined with the #include disabled :D "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
Juha Send message Joined: 7 Mar 04 Posts: 388 Credit: 1,857,738 RAC: 0 |
Grepping the Xbranch I found reference to version.h in client/win_build/seti_boinc.vcxproj and seti_boinc.vcxproj.filters. It's also included from analyzeFuncs.cpp. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
Grepping the Xbranch I found reference to version.h in client/win_build/seti_boinc.vcxproj and seti_boinc.vcxproj.filters. It's also included from analyzeFuncs.cpp. Hmmm, probably the filters did it. well I'll be glad when I finally get the move to Gradle done... (so can ditch the proprietary project files come x42) "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14676 Credit: 200,643,578 RAC: 874 |
While we're tidying up the x41 branch code as the long term reference set while you clean the stables ready for x42.... Could we make sure that all three conditions are fully and properly covered, please? The variables are: 1) The BOINC [client] version declared to be in use on the build machine - e.g. by version.h 2) The BOINC API_version linked into the compiled binary. Note this is independent of (1). 3) The BOINC client being run on the end-user's machine. As things stand at the moment (following our joint work in the Beta thread): Juha's patch is compiled into the app if (1) is >= 7.5.0 - and the head BOINC code is at 7.7.0, so it passes. Juha's patch is necessary if (2) is >= 7.5.0 Juha's patch causes a car-crash if (3) is < 7.1.0, because the fallback path is processed first and overwritten by the patch code - which can't get a valid number under old clients. Should be simple to stash the fallback command line number into a temporary variable and reinstate it if no v7 (init_data) value is available. We need to make this reliable because other builders - e,g, whoever was responsible for the current cuda60 stock build for Linux - are sharing the same codebase. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
Yeah the #include "version.h" , Juha had me add, only exists in the boinc source folder, usually placed next to the Xbranch (or other) sources when building (so will receive the correct numbers/api as expected). #1 & #2 will match, unless someone deliberately built libraries from a different (Boinc) source set, and forced linked those in, with a different boinc tree next to the Xbranch folder. #3, should only become a concern, if some new client(s) on a given platform formally deprecate an older api version. Running an ancient client with app built against a newish api may or may not do something weird (depends on Boinc). The special case of Windows binaries made here, the api 'interface' is not modified 6.2.18 (iirc), however the actual app internal behaviour is, and someone custom building on that platform with newer api would need to comment out about 3 lines, or #defines There are other more critical breaking changes, care of nv and m%, with respect to Cuda versions + Visual Studio edition deprecations/incompatibilities. That and the complexity of Mac builds (that tBar's been dealing with) is what's driving toward a modern unified buildsystem. "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
Juha's patch causes a car-crash if (3) is < 7.1.0, because the fallback path is processed first and overwritten by the patch code - which can't get a valid number under old clients. No under old clients (new api) it still gets the original -device -N command line value [Edit:] precisely which api version was -device N removed ? [Edit2:] Checking default value for new api, init_data, gpu device number ---> think it should be -1 [Edit3:] confirmed, from client app_start.cpp: ... When no GPU [Also confirm boinclib default to -1 for new api/lib if not read from init_data ] [Edit:] So, walking through Old client, old api --> sends -device N New client, old api --> client will send -device N if api_version<7.5 (*) Old client, new api --> app picks up -Device N New client, new api --> patch picks up init_data (* patched)should be sending same value in init_data as well, so overwrite is fine. so possible breakage would be if project doesn't specify, or specifies wrong, api_version (unlikely), or app_info doesn't specify, or specifies wrong api, for anon ? (more likely) "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14676 Credit: 200,643,578 RAC: 874 |
My concern would be - and my C coding is known to be weak-to-nonexistent - something like Enter main loop at line 169 (and remain in it until line 313) Set gCUDADevPref from command line at line 214 If app was compiled on new build system, overwrite gCUDADevPref at line 286, losing command line information - which will be needed if runtime client is v6, because .......... ah, I think I get it. Old runtime client returns app_init_data.gpu_device_num = -1, and line 285 skips the overwrite. OK, sorry I spoke, time for bed obviously. G'night. |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.