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.

got it, thanks

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

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

---

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

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

Jason,

Are you going to check in the missing include?

Jason,

Are you going to check in the missing include?

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.

Referring to

#include "version.h"

Which was needed for my 7.5 API compatibility patch to work.

Referring to

#include "version.h"

Which was needed for my 7.5 API compatibility patch to work.

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 */
#define BOINC_MAJOR_VERSION 6

/* Minor part of BOINC version number */
#define BOINC_MINOR_VERSION 2

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.

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

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

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.

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

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

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.

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.

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.

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.

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.

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:

...
aid.gpu_device_num = -1;
aid.gpu_opencl_dev_index = -1;
...

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.

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.