I've Built a Couple OSX CUDA Apps...
Message boards :
Number crunching :
I've Built a Couple OSX CUDA Apps...
Message board moderation
Previous · 1 . . . 16 · 17 · 18 · 19 · 20 · 21 · 22 . . . 58 · Next
| Author | Message |
|---|---|
|
Chris Adamek Send message Joined: 15 May 99 Posts: 251 Credit: 434,772,072 RAC: 236 
 |
I looked at that after someone suggested it in the Apple Forums. Mine are greyed out, don't work for Mavericks & Yosemite. The One for Lion still works though. Seems Apple has removed the Previous Free versions and now only offers El Capitan as a free version. Someone said if you email the Apple Store they will offer the Previous Free versions for around $20. Don't know if that's correct or not, I just read it on the internet ;-) That's odd, both show up as downloadable on my machines... Let me see if I can figure out an easy way to host a couple of 5GB files. Lol ID: 1766535 ·  |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
Here's another Darwin 11.4.2 machine failing with the CPU Apps, http://setiathome.berkeley.edu/show_host_detail.php?hostid=6250696. Seems it's the LapTops with an i5 or i7 CPU having the problems. It also seems they mostly work with the SETI@home v8 8.03 i686-apple-darwin App. Unfortunately, the Server has decided the App that Fails is Faster than the App that sometimes works and is determined to keep sending the App that Fails. Perhaps a Server Tweak to only send SETI@home v8 8.03 i686-apple-darwin to Hosts running Darwin 11.4.2 with an i5 or i7 CPU would work? With a hint to upgrade the OS to run the Optimized CPU Apps? There are a number of Older Hosts without an i5 or i7 that can't update to a newer OS and don't have this CPU problem. So, whatever is done should only affect the Hosts with the i-series CPUs. ID: 1766563 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
OK, I think this will work; MB CPU Apps for SETIv8. The SSE41 App will work with Core2 CPUs with at least SSE 4.1 in Snow Leopard and above, and with AVX CPUs in Mountain Lion and above. Now to see if we can get these CPU Apps that work with something higher than SSE3 onto Beta. ID: 1766626 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
Still No new Mac Apps on Beta... In other News, it appears I've finally managed to fix the problem with boinc-master in Mavericks and above. Seems it's simply NOT building the Libraries by just running Make. It works in Mountain Lion and below. In Yosemite after running Make you have to cd to the api & lib folders and run Make there as well...else it doesn't build the Required Libraries. This happens with both boinc-master versions 7.5 and 7.7. Unfortunately, the Apps I've built so far aren't any faster than those compiled in Mountain Lion. I'm also Still getting the Object.h Error with Petris' code whereas I don't get that Error with Jasons' code. It would be nice to compile the New code with NVCC 7.5... /usr/include/dispatch/object.h(145): error: expected an identifier I'm also seeing a large number of these errors; In file included from analyzeFuncs.cpp:128: but, I can Kill those by just removing what appears to be something dealing with a GTX 780. Being able to compile in Yosemite is a MAJOR breakthrough... ID: 1769935 · |
 petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 
 |
To fix dispatch_block_t error see http://hamelot.co.uk/programming/osx-gcc-dispatch_block_t-has-not-been-declared-invalid-typedef/ Still No new Mac Apps on Beta... To overcome Heisenbergs: "You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones ID: 1769969 · |
jason_gee  Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 
|
Should work fine. It's those kindof holes messing up cross platform. Price to pay living on the bleeding edge :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. ID: 1769972 · |
|
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156
|
The other error in line 160 149 #if (__CUDA_ARCH__ > 350) 150 _device__ float inline LDG_f_ca(float *addr, const int offset) 151 { 152 float v; 153 asm("ld.global.ca.nc.f32 %0, [%1];" : "=f"(v) : "l"(addr+offset)); 154 return v; 155 } 156 #else 157 __device__ float inline LDG_f_ca(float *addr, const int offset) 158 { 159 float v; 160 asm("ld.global.f32 %0, [%1];" : "=f"(v) : "l"(addr+offset)); 161 return v; 162 } 163 #endif That is valid PTX code. If the mac cuda compiler does not understand that You can replace it with this: __device__ float inline LDG_f_ca(float * __restrict__ addr, const int offset) { return addr[offset]; // slower than original PTX } To overcome Heisenbergs: "You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones ID: 1769973 · |
|
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0
|
Hmmm, if that's part of the lgamma code, cost could be excessive. Any idea what nv/Apple might have broken in 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. ID: 1769975 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
I found the same suggestion here, http://stackoverflow.com/questions/27976312/how-to-cope-with-non-gcc-compatible-code-in-os-x-yosemite-core-headers It doesn't work though. I even tried the Availability.h change with it. I've moved the MacOSX10.10.sdk/usr/include folder to the usr folder as it seems the compiler can't find it buried in the Xcode App. After the failure I realized the Answer doesn't apply to the problem. I'm Not using GCC, I'm using Clang, the answer is for people using GCC, header file contains code that can be processed by clang but not GCC. I don't have the problem running Jasons' code, I've managed to use NVCC 7.5 to compile setiathome_x41zi_x86_64-apple-darwin_cuda75. It works too... I have a feeling if I could compile your code with ToolKit 7.5 in Yosemite it might work better than ToolKit 6.5 in Mountain Lion. ID: 1769978 · |
|
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156
|
Hmmm, if that's part of the lgamma code, cost could be excessive. Any idea what nv/Apple might have broken in there ? I do not know about Apple. If TBar could tell something more about the errors. Is the line 160 the only one or if he fixes the line 160 what is the next line that produces error(s). My guess is that all ld. -ptx lines. To overcome Heisenbergs: "You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones ID: 1769979 · |
|
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156
|
Something causes object.h to be included. Can you see any difference in #include statements in the file that causes the error. CudaAcceleration.cu might be the file to look. To overcome Heisenbergs: "You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones ID: 1769980 · |
|
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0
|
Well when we get it all sussed out (eventually) it needs to go to nv (which I'll help with). It's the gcc to clang transition that's throwing me, and maintaining both in working order, well... wonder if we have to start deprecating some things on the stock side (which I'm purposely resisting) "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. ID: 1769981 · |
|
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156
|
Something causes object.h to be included. Try changing my code in CudaAcceleration.cu near line 50 to #ifdef _WIN32 #include "nvapi_device.h" #endif That makes the mac version not to inlcude nvapi_device.h I do not know if that helps or if it breaks some other code then. To overcome Heisenbergs: "You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones ID: 1769982 · |
|
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0
|
Something causes object.h to be included. Will be able to have a dig a bit later, though suspect some kindof include deeper in. Probably just a nameclash that needs an #ifndef guard "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. ID: 1769983 · |
|
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0
|
Something causes object.h to be included. Might do, either way that include is my Windows driver level one, so should be inactive anyway. "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. ID: 1769984 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
Hmmm, if that's part of the lgamma code, cost could be excessive. Any idea what nv/Apple might have broken in there ? I'm getting numerous groups similar to; In file included from confsettings.cpp:6:
./cuda/cudaAcceleration.h:160:35: error: invalid output constraint '=f' in asm
asm("ld.global.f32 %0, [%1];" : "=f"(v) : "l"(addr+offset));
./cuda/cudaAcceleration.h:168:50: error: invalid output constraint '=f' in asm
asm("ld.global.ca.nc.v2.f32 {%0, %1}, [%2];" : "=f"(v.x), "=f"(v.y) : "l"(addr+offset));
./cuda/cudaAcceleration.h:176:58: error: invalid output constraint '=f' in asm
asm("ld.global.ca.nc.v4.f32 {%0, %1, %2, %3}, [%4];" : "=f"(v.x), "=f"(v.y), "=f"(v.z), "=f"(v.w) : "l"(addr+offset));
./cuda/cudaAcceleration.h:184:41: error: invalid output constraint '=f' in asm
asm("ld.global.cg.nc.f32 %0, [%1];" : "=f"(v) : "l"(addr+offset));
./cuda/cudaAcceleration.h:191:50: error: invalid output constraint '=f' in asm
asm("ld.global.cg.nc.v2.f32 {%0, %1}, [%2];" : "=f"(v.x), "=f"(v.y) : "l"(addr+offset));
./cuda/cudaAcceleration.h:198:58: error: invalid output constraint '=f' in asm
asm("ld.global.cg.nc.v4.f32 {%0, %1, %2, %3}, [%4];" : "=f"(v.x), "=f"(v.y), "=f"(v.z), "=f"(v.w) : "l"(addr+offset));
./cuda/cudaAcceleration.h:206:41: error: invalid output constraint '=f' in asm
asm("ld.global.cs.nc.f32 %0, [%1];" : "=f"(v) : "l"(addr+offset));
./cuda/cudaAcceleration.h:213:50: error: invalid output constraint '=f' in asm
asm("ld.global.cs.nc.v2.f32 {%0, %1}, [%2];" : "=f"(v.x), "=f"(v.y) : "l"(addr+offset));
./cuda/cudaAcceleration.h:220:58: error: invalid output constraint '=f' in asm
asm("ld.global.cs.nc.v4.f32 {%0, %1, %2, %3}, [%4];" : "=f"(v.x), "=f"(v.y), "=f"(v.z), "=f"(v.w) : "l"(addr+offset));
./cuda/cudaAcceleration.h:228:41: error: invalid output constraint '=f' in asm
asm("ld.global.lu.nc.f32 %0, [%1];" : "=f"(v) : "l"(addr+offset));
./cuda/cudaAcceleration.h:235:50: error: invalid output constraint '=f' in asm
asm("ld.global.lu.nc.v2.f32 {%0, %1}, [%2];" : "=f"(v.x), "=f"(v.y) : "l"(addr+offset));
./cuda/cudaAcceleration.h:242:58: error: invalid output constraint '=f' in asm
asm("ld.global.lu.nc.v4.f32 {%0, %1, %2, %3}, [%4];" : "=f"(v.x), "=f"(v.y), "=f"(v.z), "=f"(v.w) : "l"(addr+offset));
./cuda/cudaAcceleration.h:251:58: error: invalid output constraint '=f' in asm
asm("ld.global.cs.nc.v4.f32 {%0, %1, %2, %3}, [%4];" : "=f"(v.x), "=f"(v.y), "=f"(v.z), "=f"(v.w) : "l"(addr+offset));
./cuda/cudaAcceleration.h:260:43: error: invalid output constraint '=f' in asm
asm("ld.global.cs.nc.f32 {%0}, [%1];" : "=f"(v) : "l"(addr+offset));
./cuda/cudaAcceleration.h:280:39: error: invalid output constraint '=f' in asm
asm("mul.rn.sat.f32 %0, %1, %2 ;" : "=f"(res) : "f"(a), "f"(b));
./cuda/cudaAcceleration.h:294:36: error: invalid output constraint '=f' in asm
asm("cvt.rni.f32.f32 %0, %1 ;" : "=f"(res) : "f"(a));
./cuda/cudaAcceleration.h:301:35: error: invalid output constraint '=f' in asm
asm("cvt.rz.f32.f64 %0, %1 ;" : "=f"(res) : "d"(a));
The next group starts;
In file included from analyzeFuncs.cpp:128:
./cuda/cudaAcceleration.h:160:35: error: invalid output constraint '=f' in asm
asm("ld.global.f32 %0, [%1];" : "=f"(v) : "l"(addr+offset));
./cuda/cudaAcceleration.h:168:50: error: invalid output constraint '=f' in asm
asm("ld.global.ca.nc.v2.f32 {%0, %1}, [%2];" : "=f"(v.x), "=f"(v.y) : "l"(addr+offset));
etc
etcIt's very late here, I'll have to try things earlier... ID: 1769987 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
Something causes object.h to be included. Still No luck. If I remove everything in cudaAcceleration.h between; #if (__CUDA_ARCH__ > 350) and #ifdef USE_STOCKHAM The Errors are reduced down to just repeated lines such as; /usr/include/dispatch/object.h(143): error: expected an identifier
/usr/include/dispatch/object.h(362): error: identifier "dispatch_block_t" is undefined
/usr/include/dispatch/object.h(143): error: expected an identifier
/usr/include/dispatch/object.h(362): error: identifier "dispatch_block_t" is undefined
cuda/cudaAcc_gaussfit.cu(375): error: identifier "LDG_f_ca" is undefined
cuda/cudaAcc_gaussfit.cu(410): error: identifier "LDG_f_ca" is undefined
cuda/cudaAcc_gaussfit.cu(419): error: identifier "LDG_f_ca" is undefined
cuda/cudaAcc_gaussfit.cu(439): error: identifier "LDG_f_ca" is undefined
cuda/cudaAcc_gaussfit.cu(662): error: identifier "LDG_f_ca" is undefined
cuda/cudaAcc_gaussfit.cu(222): error: identifier "LDG_f_ca" is undefined
detected during instantiation of "void GaussFit_kernel<ul_FftLength>(float, result_flag *, __nv_bool) [with ul_FftLength=8]"
(1131): here
cuda/cudaAcc_gaussfit.cu(227): error: identifier "LDG_f_ca" is undefined
detected during instantiation of "void GaussFit_kernel<ul_FftLength>(float, result_flag *, __nv_bool) [with ul_FftLength=8]"
(1131): here
etc, etc...
cuda/cudaAcc_PowerSpectrum.cu(31): error: identifier "LDG_f4_cs" is undefined
cuda/cudaAcc_PowerSpectrum.cu(50): error: identifier "LDG_f2_cs" is undefined
cuda/cudaAcc_pulsefind.cu(382): error: identifier "LDG_f_cs" is undefined
cuda/cudaAcc_pulsefind.cu(397): error: identifier "LDG_f_cs" is undefined
cuda/cudaAcc_pulsefind.cu(420): error: identifier "LDG_f_ca" is undefined
cuda/cudaAcc_pulsefind.cu(194): error: identifier "LDG_f_cs" is undefined
etc, etc....
and finally;
cuda/cudaAcc_autocorr.cu(226): error: identifier "LDG_f2_cs" is undefinedStrange I don't see these Errors in Mountain Lion with Xcode 5.1.1 and ToolKit 6.5 They appeared in Yosemite with Xcode 7.2.1 and ToolKit 7.5. Again, I can compile other SETI Apps without any problems, including setiathome_x41zi_x86_64-apple-darwin_cuda75 ID: 1770214 · |
|
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156
|
Something causes object.h to be included. The LDG_... are defined in cudaAcceleration.h and they should not be removed. Something causes object.h to be included. To overcome Heisenbergs: "You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones ID: 1770230 · |
|
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156
|
the asm statements that the LDG inline functions use are valid. The error "invalid output constraint '=f' in asm" is not giving much information. "=f" means an output variable that is of type float. Could there be a compiler setting that causes floats to be treated as doubles. If that is the case, you could try "=d" but that would probably slow things down and/or introduce calculation errors. To overcome Heisenbergs: "You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones ID: 1770231 · |
|
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156
|
Do you use Makefile and make command to build? Check Makefile for "6.5". There may be wrong INCLUDE path settings. Set to 7.5. Or if not using Makefile then check the settings from your compiler-environment. PATH? try runnning nvcc --version from command line. ... To overcome Heisenbergs: "You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones ID: 1770233 · |
©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.