The particular problem we're grappling with at Beta is

setiathome_CUDA: No device specified, determined to use CUDA device 1

- which seems likely to be either an API or a deployment issue, nothing to do with the cuda-ness of the application per se. (Which is producing validated results, though a small sample so far).

Was there a client code change to remove the -device nn command line ? If so then it's the client changing things without notifying developers. If not, then it's a build specific breakage in reading and interpreting the command line.

Usage of the command line to pass device numbers (save as a fallback for old client versions) has been deprecated since a858fe79d76af5826eafc8a35d8b537dc9e18b02 - 11 September 2011

It's become even more important since the full implementation of OpenCL enumeration in later BOINC v7 clients, because there is no guarantee that cuda device numbers and OpenCL device numbers are enumerated identically: BOINC needs to be able to uniquely identity hardware devices in either mode, to avoid potentially scheduling a CUDA application and an OpenCL application to the same hardware but with different device numbers.

Nice. That's the kindof pointless deprecation that will foster outright rebellion. [I give a cr@p about OpenCL devices because why ? ]

---

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

All I'm going to say is it's very strange it works perfectly fine for 7 months under Anonymous platform, place it on the SETI Server and suddenly BOINC doesn't know what to do with it.
Very strange indeed.

We haven't yet seen the comparative <app_version>...</app_version> sections I requested at Beta, some three hours ago. They would probably explain the mystery, perhaps lying in the presence or absence of <api_version> data.

Nice. That's the kindof pointless deprecation that will foster outright rebellion. [I give a cr@p about OpenCL devices because why ? ]

Because your applications are going to run under a collaborative framework where developers from other projects might choose to use a different development platform.

Nice. That's the kindof pointless deprecation that will foster outright rebellion. [I give a cr@p about OpenCL devices because why ? ]

Because your applications are going to run under a collaborative framework where developers from other projects might choose to use a different development platform.

Then you, along with Boinc developers, have no understanding of the principles of information hiding (reference https://en.wikipedia.org/wiki/Information_hiding, whereby my application has no responsibility to understand anything about OpenCL, Arm CPus, or Abacus bearing marmosets. It's bad design to cast external expectations onto a microcosm.

---

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

Nice. That's the kindof pointless deprecation that will foster outright rebellion. [I give a cr@p about OpenCL devices because why ? ]

Because your applications are going to run under a collaborative framework where developers from other projects might choose to use a different development platform.

Then you, along with Boinc developers, have no understanding of the principles of information hiding (reference https://en.wikipedia.org/wiki/Information_hiding, whereby my application has no responsibility to understand anything about OpenCL, Arm CPus, or Abacus bearing marmosets. It's bad design to cast external expectations onto a microcosm.

But you, as an application developer, working inside something that is as much a computer science experiment as any astronomy/particle physics/pharmaceutical/mathematical (need I go on) experiment surely have some duty to RTFM - keep up-to-date with current trends? Otherwise you'd still be programming for CUDA 1.0 under Windows 3.11

Nice. That's the kindof pointless deprecation that will foster outright rebellion. [I give a cr@p about OpenCL devices because why ? ]

Because your applications are going to run under a collaborative framework where developers from other projects might choose to use a different development platform.

Then you, along with Boinc developers, have no understanding of the principles of information hiding (reference https://en.wikipedia.org/wiki/Information_hiding, whereby my application has no responsibility to understand anything about OpenCL, Arm CPus, or Abacus bearing marmosets. It's bad design to cast external expectations onto a microcosm.

But you, as an application developer, working inside something that is as much a computer science experiment as any astronomy/particle physics/pharmaceutical/mathematical (need I go on) experiment surely have some duty to RTFM - keep up-to-date with current trends? Otherwise you'd still be programming for CUDA 1.0 under Windows 3.11

Sure: but then let's ask the question why this doesn't appear to be broken on other platforms. Possibly because proper developers vetoed and repaired the damage caused by senselessly creating extra work for other people ?

[Edit:] If they are going to make changes to APIs like that, they better move to hard version them ---> i.e. Version X client, only supports apps with X API. I could go with that.

---

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

Sure: but then let's ask the question why this doesn't appear to be broken on other platforms. Possibly because proper developers vetoed and repaired the damage caused by senselessly creating extra work for other people ?

[Edit:] If they are going to make changes to APIs like that, they better move to hard version them ---> i.e. Version X client, only supports apps with X API. I could go with that.

TBar has demonstrated (provisionally so far) that his build does device selection correctly under anonymous platform, but fails when deployed as a stock app. I can think of a possible reason for that, and how it could be worked round: but I need to see the evidence from <app_version> before I can advise Eric.

From what you're saying, it's possible that your builds will need the same workround when deployed as stock.

Sure: but then let's ask the question why this doesn't appear to be broken on other platforms. Possibly because proper developers vetoed and repaired the damage caused by senselessly creating extra work for other people ?

[Edit:] If they are going to make changes to APIs like that, they better move to hard version them ---> i.e. Version X client, only supports apps with X API. I could go with that.

TBar has demonstrated (provisionally so far) that his build does device selection correctly under anonymous platform, but fails when deployed as a stock app. I can think of a possible reason for that, and how it could be worked round: but I need to see the evidence from <app_version> before I can advise Eric.

From what you're saying, it's possible that your builds will need the same workround when deployed as stock.

That's reasonable. I have no objection to updates after the fact, but pointless deprecation of 'stuff that works' is just the wrong way for a resource stressed system to operate. Maybe David needs to think about developers more before making changes ... just throwing that out there.

---

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

Sure: but then let's ask the question why this doesn't appear to be broken on other platforms. Possibly because proper developers vetoed and repaired the damage caused by senselessly creating extra work for other people ?

[Edit:] If they are going to make changes to APIs like that, they better move to hard version them ---> i.e. Version X client, only supports apps with X API. I could go with that.

TBar has demonstrated (provisionally so far) that his build does device selection correctly under anonymous platform, but fails when deployed as a stock app. I can think of a possible reason for that, and how it could be worked round: but I need to see the evidence from <app_version> before I can advise Eric.

From what you're saying, it's possible that your builds will need the same workround when deployed as stock.

That's reasonable. I have no objection to updates after the fact, but pointless deprecation of 'stuff that works' is just the wrong way for a resource stressed system to operate. Maybe David needs to think about developers more before making changes ... just throwing that out there.

Further research - there's a possibility (waiting on a test result from TBar) that befb90f0d4d1f14ae4a42d1a49bd612e9bcc4f96 may be implicated (not for the first time).

If so, your own builds won't need the workround.

Sure: but then let's ask the question why this doesn't appear to be broken on other platforms. Possibly because proper developers vetoed and repaired the damage caused by senselessly creating extra work for other people ?

[Edit:] If they are going to make changes to APIs like that, they better move to hard version them ---> i.e. Version X client, only supports apps with X API. I could go with that.

TBar has demonstrated (provisionally so far) that his build does device selection correctly under anonymous platform, but fails when deployed as a stock app. I can think of a possible reason for that, and how it could be worked round: but I need to see the evidence from <app_version> before I can advise Eric.

From what you're saying, it's possible that your builds will need the same workround when deployed as stock.

That's reasonable. I have no objection to updates after the fact, but pointless deprecation of 'stuff that works' is just the wrong way for a resource stressed system to operate. Maybe David needs to think about developers more before making changes ... just throwing that out there.

Further research - there's a possibility (waiting on a test result from TBar) that befb90f0d4d1f14ae4a42d1a49bd612e9bcc4f96 may be implicated (not for the first time).

If so, your own builds won't need the workround.

I saw the word 'Bitcoin' and passed out.

---

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

I saw the word 'Bitcoin' and passed out.

Yeah, well, likewise.

Sometimes David does bend over backwards to accommodate maverick developers ;-)

OK, heading out for a walk to clear my head - back in an hour or so.

k - Just put Andromeda, (2 GTX-750TI SC GPUs), to the task at Beta. Picked up CUDA75 Units there. Device 0 and Device 1 are crunching. I will let this go for a few hours.

Andromeda, Comp. ID = 78425 at Beta.

Once again, this system is a Hackintosh with model ID of 3,1. BOINC displays true system hardware specs.

I hope the data gathered helps. :-)

[EDIT:]

Also, I'm crunching 4 Units at a time; two on each Device.


TL

---

TimeLord04
Have TARDIS, will travel...
Come along K-9!
Join Calm Chaos

Thanks - I'll keep an eye on it.

From what we've discovered so far at Beta (there's been a lively discussion there too today), I suspect that your BOINC will show two tasks running on Device 0, and two tasks on Device 1. But the results on the website will show that every task has been run using Jason's default of DevPref 1, and none at all with DevPref 2 (Jason's code doesn't acknowledge the existence of BOINC's DevPref 0).

We're working on a workround, but we're not quite done yet.

Went out for about 45+ min... Got back to find the first four Units completed and Uploaded; but, NOT Reported. I hit Update and got them Reported.

Found one Unit has been Validated against TBar's system with three 950 cards. Three of my Units are still Pending.

System picked up 20 more Units; so, now I have close to 40 Units in queue.

I wish you, TBar, and anyone else involved the GREATEST success with this endeavor. :-) I hope the next step, (after getting this to Main), will be to get this included into a future Lunatics Install.


TL

---

TimeLord04
Have TARDIS, will travel...
Come along K-9!
Join Calm Chaos

Does indeed appear that all the first four tasks ran on Device 1 (in Jason's enumeration - still waiting to work out if that's BOINC's Device 0)

@ Jason,

Please review (including linked docs) and consider committing Juha's patch at Beta message 59208, to fix the device selection code for newer cases.

Just picked up some SoG_MAC Units... They're towards the bottom of my Beta queue, though.


TL

---

TimeLord04
Have TARDIS, will travel...
Come along K-9!
Join Calm Chaos

@ Jason,

Please review (including linked docs) and consider committing Juha's patch at Beta message 59208, to fix the device selection code for newer cases.

There we go:

Modified:
branches/sah_v7_opt/Xbranch/client/main.cpp
Log:
Patch for Cuda device selection, Care of Juha Sointusalo.
Deals with boinc api 7.5 onwards breaking change (mid major version),
from standard use of command line to field not present on preferred earlier versions.

Will need checking by anyone using the applicable boincapi 7.5+

Doesn't affect current Windows builds on main/Lunatics, as they use an older API modified to reduce problems on exit. A compelling reason to use newer boincApi doesn't really exist for Cuda, though if desired could be encouraged by switching from imperative thread/process management, to asynchronous friendly behaviour. That though would warrant a major version update [of client, api and apps].

[Edit:] applied to the svn copy of Petri's alpha as well

---

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

The new OSX CUDA Apps updated to work with BOINC API 7.5 are now at Crunchers Anonymous
The only change is to the CUDA Apps themselves.

The Current Driver for OSX 10.11.6 to 10.9.x is Version 7.5.30, also available in your System Preferences/CUDA pane if you've already installed an older CUDA driver.

Testers at Beta are needed. The Current Apps at Beta work fine for machines with just 1 GPU and they will be updated shorty to work correctly with multiple GPUs. To run the CUDA Apps at Beta you will probably have to Abort a good number of OpenCL tasks before being sent the CUDA tasks. Don't be shy with the Abort button ;-)

TBar, need a link for the library, the one I have want's to install items, I just need the library so I can move them to the folder