sm35=780,sm50=750ti

sm35=780,sm50=750ti

Those numbers look the same as BOINC reports as 'Compute Capability' when detecting cuda cards at startup. That would make it a very simple and deterministic relationship with the core hardware GPU chip families the various generations of NVidia cards are based on.

setiathome_CUDA: Found 4 CUDA device(s):
  Device 1: GeForce GTX 980, 4095 MiB, regsPerBlock 65536
     computeCap 5.2, multiProcs 16 
     pciBusID = 1, pciSlotID = 0
  Device 2: GeForce GTX 780, 3071 MiB, regsPerBlock 65536
     computeCap 3.5, multiProcs 12 
     pciBusID = 2, pciSlotID = 0
  Device 3: GeForce GTX 980, 4095 MiB, regsPerBlock 65536
     computeCap 5.2, multiProcs 16 
     pciBusID = 3, pciSlotID = 0
  Device 4: GeForce GTX 780, 3071 MiB, regsPerBlock 65536
     computeCap 3.5, multiProcs 12 
     pciBusID = 4, pciSlotID = 0

So far the App is working about the way it did in Linux, complete with the occasional flurry of errors. Strange how a certain angle range will trigger a number of consecutive errors.
;-)

I have sent you an email with updated source code for testing. Lot less errors for me. Hope it helps. You may need to do the #ifdefined __APPLE__ thing again. EDIT a new email fixed that.

So far the App is working about the way it did in Linux, complete with the occasional flurry of errors. Strange how a certain angle range will trigger a number of consecutive errors.
;-)

I have sent you an email with updated source code for testing. Lot less errors for me. Hope it helps. You may need to do the #ifdefined __APPLE__ thing again. EDIT a new email fixed that.

Seeing as you're getting some level of success down the conventional route, as soon as things let up I'll be poking at the XCode route to compare the amount of gymnastics required to get something functional. Bit of a chaotic week for me, so will still be on the sidelines for a few days, but checking in to see how things are coming along.

TomsMacPro:client Tom$ make -i -k
make: *** No rule to make target `/Users/Tom/boinc/db/sqlblob.cpp', needed by `ap_client-sqlblob.o'.
make: *** No rule to make target `/Users/Tom/boinc/db/sqlrow.cpp', needed by `ap_client-sqlrow.o'.
make: *** No rule to make target `/Users/Tom/boinc/db/xml_util.cpp', needed by `ap_client-xml_util.o'.
make: *** No rule to make target `/Users/Tom/boinc/client/lcgamm.cpp', needed by `ap_client-lcgamm.o'...

ap_fileio.cpp:820:80: warning: format specifies type 'long' but the argument has type 'int' [-Wformat]
    fprintf(stderr, "Error reading raw data: Expected %ld bytes, read %ld.\n", client.ap_shmem->ap_gdata.state.datasize, client.rawdata.size());

14 warnings generated.
mv -f .deps/ap_client-fft_setup.Tpo .deps/ap_client-fft_setup.Po
make: Target `all' not remade because of errors.
TomsMacPro:client Tom$

/usr/include/dispatch/object.h(143): error: expected an identifier
/usr/include/dispatch/object.h(362): error: identifier "dispatch_block_t" is undefined
2 errors detected in the compilation of "/var/folders/6c/hy0ffg_90sz3wbxfk7gzw3800000gn/T//tmpxft_00008c2c_00000000-15_cudaAcceleration.compute_50.cpp1.ii".
make[2]: [cudaAcceleration.o] Error 2 (ignored)
/usr/include/dispatch/object.h(143): error: expected an identifier
/usr/include/dispatch/object.h(362): error: identifier "dispatch_block_t" is undefined
2 errors detected in the compilation of "/var/folders/6c/hy0ffg_90sz3wbxfk7gzw3800000gn/T//tmpxft_00008c32_00000000-15_cudaAcc_CalcChirpData.compute_50.cpp1.ii".
make[2]: [cudaAcc_CalcChirpData.o] Error 2 (ignored)
/usr/include/dispatch/object.h(143): error: expected an identifier
/usr/include/dispatch/object.h(362): error: identifier "dispatch_block_t" is undefined
2 errors detected in the compilation of "/var/folders/6c/hy0ffg_90sz3wbxfk7gzw3800000gn/T//tmpxft_00008c38_00000000-15_cudaAcc_fft.compute_50.cpp1.ii".
make[2]: [cudaAcc_fft.o] Error 2 (ignored)

ETC

clang: error: no such file or directory: 'seti_cuda-analyzeFuncs_sse2.o'
clang: error: no such file or directory: 'seti_cuda-analyzeFuncs_sse3.o'
clang: error: no such file or directory: 'cudaAcceleration.o'
clang: error: no such file or directory: 'cudaAcc_CalcChirpData.o'
clang: error: no such file or directory: 'cudaAcc_fft.o'
clang: error: no such file or directory: 'cudaAcc_gaussfit.o'
clang: error: no such file or directory: 'cudaAcc_PowerSpectrum.o'
clang: error: no such file or directory: 'cudaAcc_pulsefind.o'
clang: error: no such file or directory: 'cudaAcc_summax.o'
clang: error: no such file or directory: 'cudaAcc_transpose.o'
clang: error: no such file or directory: 'cudaAcc_utilities.o'
clang: error: no such file or directory: 'cudaAcc_autocorr.o'
make[2]: [seti_cuda] Error 1 (ignored)

checking /Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/Headers/LinearAlgebra/object.h usability... no
checking /Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/Headers/LinearAlgebra/object.h presence... yes
configure: WARNING: /Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/Headers/LinearAlgebra/object.h: present but cannot be compiled
configure: WARNING: /Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/Headers/LinearAlgebra/object.h:     check for missing prerequisite headers?
configure: WARNING: /Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/Headers/LinearAlgebra/object.h: see the Autoconf documentation
configure: WARNING: /Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/Headers/LinearAlgebra/object.h:     section "Present But Cannot Be Compiled"
configure: WARNING: /Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/Headers/LinearAlgebra/object.h: proceeding with the compiler's result
configure: WARNING:     ## ---------------------------------------- ##
configure: WARNING:     ## Report this to http://lunatics.kwsn.net/ ##
configure: WARNING:     ## ---------------------------------------- ##
checking for /Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/Headers/LinearAlgebra/object.h... no

Seeing as you're getting some level of success down the conventional route, as soon as things let up I'll be poking at the XCode route to compare the amount of gymnastics required to get something functional. Bit of a chaotic week for me, so will still be on the sidelines for a few days, but checking in to see how things are coming along.

Just as a reminder, I've Never be able to compile anything using Mavericks and above. A couple people managed to compile in Mavericks, but I think they were using Mac Ports. Right now I'm compiling in Mountain Lion using CUDA Toolkit 6.5 which is the highest Toolkit you can use in Mountain Lion. It appears you need Toolkit 7.0 for the GTX 980...

More weirdness with Two 750Ti and AstroPulses. With just One 750Ti the unblanked APs run an average of 35 minutes, it's shown in the APR from running hundreds of them. The blanked ones take a few minutes more. Since adding the 2nd 750 card the APs take almost Twice as long, but that's not all. When One 750 runs an AP the Other 750 also runs CUDA tasks Over twice as slow. Here is a 'Normal' AR .37, http://setiathome.berkeley.edu/result.php?resultid=4588037713, Run time: 9 min 39 sec. Here is the same AR run during the AP, http://setiathome.berkeley.edu/result.php?resultid=4588110773, Run time: 20 min 34 sec. There are Three CUDA tasks that ran much slower than normal while that AP was running on the other card, here's another http://setiathome.berkeley.edu/result.php?resultid=4588118811

I never saw this when the machine was running One NV 750 and Two ATI 6800s.
So, Why does Two 750s hate APs So much on this machine? For some reason just One 750 running One AP will cause Both 750s to run at Half Speed.

More weirdness with Two 750Ti and AstroPulses. With just One 750Ti the unblanked APs run an average of 35 minutes, it's shown in the APR from running hundreds of them. The blanked ones take a few minutes more. Since adding the 2nd 750 card the APs take almost Twice as long, but that's not all. When One 750 runs an AP the Other 750 also runs CUDA tasks Over twice as slow. Here is a 'Normal' AR .37, http://setiathome.berkeley.edu/result.php?resultid=4588037713, Run time: 9 min 39 sec. Here is the same AR run during the AP, http://setiathome.berkeley.edu/result.php?resultid=4588110773, Run time: 20 min 34 sec. There are Three CUDA tasks that ran much slower than normal while that AP was running on the other card, here's another http://setiathome.berkeley.edu/result.php?resultid=4588118811

I never saw this when the machine was running One NV 750 and Two ATI 6800s.
So, Why does Two 750s hate APs So much on this machine? For some reason just One 750 running One AP will cause Both 750s to run at Half Speed.

A first thought that came in to my mind was 'CPU-usage' and the second was 'PCIE' usage. The third as i'm writing is a driver issue: Not that many MACs with many NVIDIA cards. EDIT (typo acrds --> cards)

More weirdness with Two 750Ti and AstroPulses. With just One 750Ti the unblanked APs run an average of 35 minutes, it's shown in the APR from running hundreds of them. The blanked ones take a few minutes more. Since adding the 2nd 750 card the APs take almost Twice as long, but that's not all. When One 750 runs an AP the Other 750 also runs CUDA tasks Over twice as slow. Here is a 'Normal' AR .37, http://setiathome.berkeley.edu/result.php?resultid=4588037713, Run time: 9 min 39 sec. Here is the same AR run during the AP, http://setiathome.berkeley.edu/result.php?resultid=4588110773, Run time: 20 min 34 sec. There are Three CUDA tasks that ran much slower than normal while that AP was running on the other card, here's another http://setiathome.berkeley.edu/result.php?resultid=4588118811

I never saw this when the machine was running One NV 750 and Two ATI 6800s.
So, Why does Two 750s hate APs So much on this machine? For some reason just One 750 running One AP will cause Both 750s to run at Half Speed.

A first thought that came in to my mind was 'CPU-usage' and the second was 'PCIE' usage. The third as i'm writing is a driver issue: Not that many MACs with many NVIDIA cards. EDIT (typo acrds --> cards)

CPU usage shouldn't be an issue, the machine has 8 Real cores and is only running 3 CPU tasks leaving 5 Cores for three GPUs. You can see the PCIe Usage in the nVidia settings in Ubuntu. The same nVidia cards in Ubuntu, running Your App, shows a Max PCIe usage of ~10% on cuda shorties, the longer tasks have much lower usage. The highest PCIe Usage on APs was around 6%, usually much lower. So, that wouldn't seem to be a problem either. Plus, there isn't a problem with the Two 750s running CUDA tasks while the ATI 6870 runs APs, and the CUDA tasks use More PCIe bandwidth than APs.
My guess is the AP App, but to compile another AP App I would have to remove the 750s and Boot to Mountain Lion...I'm getting tired of pulling cards.

//libsleep.c
#include <time.h> 
#include <errno.h> 
/* 
* To compile run: 
* gcc -O2 -fPIC -shared -Wl,-soname,libsleep.so -o libsleep.so libsleep.c 
* 
* To use: add 
* export LD_PRELOAD=/path/to/libsleep.so
* to your program startup script. (boincmgr startup script)
* 
* 
* 
*/ 
int sched_yield(void) 
{ 
  struct timespec t; 
  struct timespec r; 
  
  t.tv_sec = 0; 
  t.tv_nsec = 1000; // 0.001 s 
  while(nanosleep(&t, &r) == -1 && errno == EINTR) 
    { 
      t.tv_sec = r.tv_sec; 
      t.tv_nsec = r.tv_nsec; 
    } 
  return 0; 
}

If your AP app is based on Raistmer's code base (which it seems to be), it has many configurable options, one of which is -cpu_lock. If that isn't set up right when using multiple cards and multiple -instances_per_device, it might be possible that multiple app instances are all tied to one CPU, or at least to fewer CPUs than there are apps - even though there are other CPUs available. Just another possible explanation.

Check your desired configuration carefully, and perhaps actively disable -cpu_lock to see if the operating system makes a better job of distributing the workload.

From what I can tell, the driver architecture on Mac seems to be pretty high latency (relative and probably dependant on what the applications are doing though). Probably means that while mixing different vendors would be on separate driver stacks, and so would operate as expected, individual instances on one driver stack would tend to queue. I don't know how much work Raistmer put into settings to reduce the synchronisation rate (if any, unroll maybe ?), but possibly winding something out might improve the situation pending better understanding of the drivers on Mac....

BTW, have you noticed the last CUDA build has a problem with tasks with an AR of around 1.103119? All the Errors are around this particular AR, http://setiathome.berkeley.edu/results.php?hostid=6796479&state=6