There aren't any counters, but the results are the same.

So how it would help in debugging??

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

I don't plan on running very many Tasks with an App that takes 44 minutes to finish a shorty.

1) no need to run many, only few needed but debuggable, that is, with right wingman's result.
2) no need to find another OS X OpenCL wingman. Just any OpenCL wingman. Actually, better it will be Windows-based one.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

It seems to be working with the Repository driver showing OpenCL 1.2 AMD-APP (1800.11). The older App r3306 was compiled with SDK 2.8.1 and works with OpenCL 1.2 AMD-APP (1526.3). For some reason the new App compiled with SDK 2.9.1 doesn't work with the older driver 14.6. Strange considering 14.6 and SDK 2.9.1 was released about the same time. I dunno.
There doesn't seem to be much difference between the older App and the newer r3482, at least not on my old cards; http://setiathome.berkeley.edu/result.php?resultid=5023490256
At least they seem to be validating.

Maybe helpful to look at
http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/system-requirements-driver-compatibility
AMDs list with minimum driver per SDK.

---

_\|/_
U r s

I don't plan on running very many Tasks with an App that takes 44 minutes to finish a shorty.

1) no need to run many, only few needed but debuggable, that is, with right wingman's result.
2) no need to find another OS X OpenCL wingman. Just any OpenCL wingman. Actually, better it will be Windows-based one.

If you need some results with counters there are still a few at Beta, you have to look down near the bottom though. I'm not sure Counters are going to be any indication on why some thing is running many times slower than it should. It's been a problem for about a year now, so there are a few results around. Here is a Host; http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=64333
You can find a few down around here, http://setiweb.ssl.berkeley.edu/beta/top_hosts.php?sort_by=expavg_credit&offset=260

It seems to be working with the Repository driver showing OpenCL 1.2 AMD-APP (1800.11). The older App r3306 was compiled with SDK 2.8.1 and works with OpenCL 1.2 AMD-APP (1526.3). For some reason the new App compiled with SDK 2.9.1 doesn't work with the older driver 14.6. Strange considering 14.6 and SDK 2.9.1 was released about the same time. I dunno.
There doesn't seem to be much difference between the older App and the newer r3482, at least not on my old cards; http://setiathome.berkeley.edu/result.php?resultid=5023490256
At least they seem to be validating.

Maybe helpful to look at
http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/system-requirements-driver-compatibility
AMDs list with minimum driver per SDK.

Yes, I looked at that. My favorite driver is the AMD Catalyst 14.6, which should work with SDK v2.9.1...right? It is listed as a beta though, amd-driver-installer-14.20-x86.x86_64.run and 14.4 is listed as 14.10.1006. I'm thinking about going back to SDK 2.8.1 and trying another compile. It seems the older App with 14.6 is about the same as the newer App with whatever the repository is sending as AMD-APP 1800.11, but, it would be nice to be able to use the older driver.

Here is a Host; http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=64333

Well, lets consider this particular task:
http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8698303

1)

Low-performance GPU detected, default period_iterations_num set to 500
For low-performance GPU path use_sleep enabled with 5ms per iteration
Used GPU device parameters are:
Number of compute units: 2
Single buffer allocation size: 128MB
Total device global memory: 512MB
max WG size: 1024
local mem type: Real
FERMI path used: yes
LotOfMem path: yes
LowPerformanceGPU path: yes
period_iterations_num=500

Bold line explains part of delay. It responsible for big elapsed time on low-perf path. r3482 deals with low-perf path quite differently so should show speedup here.

2) Counters:

PC_triplet_find_hit total=4.7650E+04, N=47650 , <>=1 , min=1 , max=1
PC_triplet_find_miss total=8.9200E+02, N=892 , <>=1 , min=1 , max=1


PC_pulse_find_hit total=3.6165E+04, N=36165 , <>=1 , min=1 , max=1
PC_pulse_find_miss total=1.4000E+01, N=14 , <>=1 , min=1 , max=1
PC_pulse_find_early_miss total=9.0000E+00, N=9 , <>=1 , min=1 , max=1
PC_pulse_find_2CPU total=0.0000E+00, N=0 , <>=0 , min=0 , max=0


PoT_transfer_not_needed total=4.7640E+04, N=47640 , <>=1 , min=1 , max=1
PoT_transfer_needed total=9.0300E+02, N=903 , <>=1 , min=1 , max=1

wingman has:

class PC_triplet_find_hit: total=47630, N=47630, <>=1, min=1 max=1
class PC_triplet_find_miss: total=912, N=912, <>=1, min=1 max=1


class PC_pulse_find_hit: total=36164, N=36164, <>=1, min=1 max=1
class PC_pulse_find_miss: total=15, N=15, <>=1, min=1 max=1
class PC_pulse_find_early_miss: total=10, N=10, <>=1, min=1 max=1
class PC_pulse_find_2CPU: total=0, N=0, <>=0, min=0 max=0


class PoT_transfer_not_needed: total=47620, N=47620, <>=1, min=1 max=1
class PoT_transfer_needed: total=923, N=923, <>=1, min=1 max=1

Worst part is: they differ (!). Though for this particular task seems wingman needed more CPU support than OS X one, it could mean quite imprecise results from GPU part that could explain some signal missing from one side and excessive CPU (and correspondingly increased elapsed) time usage in other cases.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Here is a Host; http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=64333

Well, lets consider this particular task:
http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8698303

1)

Low-performance GPU detected, default period_iterations_num set to 500
For low-performance GPU path use_sleep enabled with 5ms per iteration
Used GPU device parameters are:
Number of compute units: 2
Single buffer allocation size: 128MB
Total device global memory: 512MB
max WG size: 1024
local mem type: Real
FERMI path used: yes
LotOfMem path: yes
LowPerformanceGPU path: yes
period_iterations_num=500

Bold line explains part of delay. It responsible for big elapsed time on low-perf path. r3482 deals with low-perf path quite differently so should show speedup here....

&&&&&
Worst part is: they differ (!). Though for this particular task seems wingman needed more CPU support than OS X one, it could mean quite imprecise results from GPU part that could explain some signal missing from one side and excessive CPU (and correspondingly increased elapsed) time usage in other cases.

Remember this thread? GPU units taking an absurd amount of time to finish

So, for a GT 730, running a Green Bank (blc) task, nearly 7 hours to complete sounds OK?

The specs on the 730 that matter, Number of compute units: 2
There were actually people telling him it's normal to take 7 hours for a GUPPI on that card.
The solution for those cards? "You might want to install the Cuda50 App from the Lunatics installer on that machine"
Here are the results with CUDA: BLC3 Run time: 1 hours 12 min 14 sec
Much better than 7 Hours.

I don't know why people were surprised the OpenCL App took so long on that card, it's very close to the same GPU in the Mac LapTops and they have been having this problem for almost a Year with the OpenCL App. In Addition, Most of the Results are Incorrect to boot! Not only do they take Much longer to complete, they give Bad results.

There is a solution. The same solution found for the similar NV 730 cards. Run the Mac CUDA App. Not only does it work much better on these Low End GPUs, it actually produces nearly 100% valid results. Win, WIN.
*nods head*

Yes, I looked at that. My favorite driver is the AMD Catalyst 14.6, which should work with SDK v2.9.1...right? It is listed as a beta though, amd-driver-installer-14.20-x86.x86_64.run and 14.4 is listed as 14.10.1006. I'm thinking about going back to SDK 2.8.1 and trying another compile. It seems the older App with 14.6 is about the same as the newer App with whatever the repository is sending as AMD-APP 1800.11, but, it would be nice to be able to use the older driver.

You only need that specific include headers from the APP SDK 2.9.1. Otherwise you can freely choose if you want SDK 2.8.1 or 2.9.1.
There is nothing more in there that would be needed for compiling a setiathome app. The needed libraries for GPU apps are included within the GPU driver.

---

_\|/_
U r s

Hmmm, almost 3 weeks in and 20 downloads later there still isn't any feedback on the New 'Baseline' CUDA Apps. It would be nice to know how it is working. Hopefully it will be a little faster on the Fermi+ GPUs and solve the detection problems on some of the Laptops. The major item is to make sure you use a CUDA driver that supports your OS. Each New OS version uses a New CUDA driver. The Newer drivers generally support the Older OSes but the Older Drivers Do Not Support the Newer OSes.
On the Lower End GPUs the 'Baseline' CUDA App should be almost twice as fast as the Current Stock OpenCL App. I submitted the 'Baseline' CUDA App to Beta a couple weeks ago, haven't heard anything about the CUDA App or the CPU App since....oh well.

The 'Special' CUDA App, aka Petri's code, is still on hold as it continues to be off by at least 1 Pulse count on about half the GUPPI tasks. Kinda reminds me of the Mac nVidia OpenCL App, it's off just enough to eventually validate. But, the Special App gives the correct results on the Arecibo tasks and is much, Much, faster than the OpenCL App, so the validation wait isn't as frustrating.

In general (but not always) the more mature the applications, the less feedback I tend to receive. I'd attribute that to there being fewer problems, and increased user familiarity. Special exceptions do occur from time, for example I do receive occasional emails or PMs from people that managed to build the codebase for an unusual platform/situation (usual out of politeness, and rarely raising questions or problems), similar from other platform test builds.

In the case of Cuda 'baseline', that familiarity + just working is just boring.

Pushing the envelope with Petri's modifications/updates will be the next task IMO, which I'm sure will generate more excitement, questions, problems, and things not yet considered. Fortunately for me I learned near infinite patience along the way from hacking on Lunatics and AK code from 2007 onwards.

With the OSes, Devices/Drivers, Languages/Apis, and project in a confused state of flux, I predict that many users will just stick with whatever the project issues. IMO probably won't start to settle down until end of year.

---

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

Yes, the Special build is much more exciting ;-)
Shame it only works on the newer GPUs. From what I see if you have a GPU with Compute Code 3.0 or lower the Baseline Apps posted at C.A. is about the best it's going to get. The recent Special code seems to make 750Ti GPUs hang. Not only is it hanging on my Mac it's also causing a couple hangs on the Linux machine. I went back to the older code for now. I have dozens of Apps scattered around a few OSes and I don't think I had run the App I'm currently running. It seems to be running extremely well in Darwin 14.5. It's a little slower on the GUPPIs but doesn't hang and most everything validates right away. I'll check it with Darwin 15.5 in a while, after the few APs are finished. Seems 15.5 even slows down APs, not quite as slow as it slows down the OpenCL MBs though.

True that when Fermi Class was the thing, I didn't pull any punches, but now that v8 and Kepler-Maxwell-Pascal is a thing, it makes sense to me to open the floodgates.

With the newer code, I regard the precision and compatibility issues as par for the course. The current volatility in the OSes (all of them) is complicating matters. Just something we have to ride through I think.

---

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

Finally one of TBar-built CUDA MB binaries (CUDA42) deployed on beta. Lets see how it will go.
Those with Macs and NV cards please test intensively (and in stock mode for awhile - we need to compare different builds before deployment to main).

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Finally one of TBar-built CUDA MB binaries (CUDA42) deployed on beta. Lets see how it will go.
Those with Macs and NV cards please test intensively (and in stock mode for awhile - we need to compare different builds before deployment to main).

There appears to be a problem somewhere down the line with device selection - possibly in TBar's application, possibly in BOINC, possibly in Eric's deployment.

It would be really helpful if someone with a multi-gpu Mac (ideally, all NVidia GPUs, but different card types) could join the Beta testing drive, and answer the questions which TBar has so far been unable to answer.

See active discussion in http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2266

Will asses my latent Mac Pro tomorrow, and can potentially swap different GPUs in and out if needed, see if it balks on the beta app build etc.

In 'essence' baseline builds should 'just work', however the Mac situation is dicey, with multiple deprecations and other breaking changes (thanks Apple), and multiple different build systems required for one app (which is ridiculous)

This is probably somewhat related to the same issues with stock cpu/gpu, in that long standing tools/techniques no longer completely work, not helped by the Boinc libraries being in Xcode and everything else not.

After experimenting and discussing with Petri's code (Linux based more or less traditional build system in hand), similar issues but different issues arise, in that it's like trying to put Square pegs in round holes.

In that light, we reached a sortof mutual nod consensus of two, that the situation has reached saturation point, and reformation is now necessary (if not an immediate solution)

IOW, quick and simple answers that catch all are unlikely at present. The main problems are systemic over problems with baseline or next generation experimental application code. Probably if the Mac specific problems look to be the same issues in different clothing (to be confirmed), then we're talking rolling over into x42, as opposed to trying to wedge current codebases into places they just don't fit.

---

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

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.

---

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

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.

Yeah, like I said, Systemic :D beta is there to catch this stuff (IMO). Who knows where the breakage happened ? (not me). Anything like process explorer on Mac, that could reveal the command line fed to the app ?

---

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