Message boards :
Number crunching :
Monitoring inconclusive GBT validations and harvesting data for testing
Message board moderation
Previous · 1 . . . 10 · 11 · 12 · 13 · 14 · 15 · 16 . . . 36 · Next
Author | Message |
---|---|
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
I haven't published any recent Mac builds of Cuda baseline yet apart from one old test build on a forum post, for a number of unrelated reasons (mostly time). If you're seeing issues with Cuda baseline builds from current source, you'll need to determine if the problems are: - boincapi related (which typically manifest in errors after exit), - build system related (Apple's changes of compiler and libraries) - Cuda version including web driver change related, (possible, though doubtful IMO) - a runtime/OS level change (possibly priority/timeouts of some sort) - Something else (app code issue is possible, though less likely than above, and I'd need a smoking gun of some sort.) Are you including nvcc --gencode entries during build on mac, targeted for 750ti (iirc ~ compute capability 5.0 (?) ) so as to embed PTX binaries ? or relying on the web driver to generate it on first run ? (this could be a difference fitting into multiple of the above slots, so they aren't entirely mutually exclusive conditions) "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. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Well, I don't have a Mac Laptop, so, it would be difficult to test. The people at Beta are showing the entries though; http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=72386 http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24674317 That's two for two, those are the only Laptops running the App as far as I know. I have Never seen the problem on a Desktop GPU. The line used on the App used by those machines was; NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_20,code=sm_20 -gencode arch=compute_20,code=sm_21 -gencode arch=compute_20,code=compute_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 The Line used on the 'Special' Apps with Toolkit 7.5 is; NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 I ALWAYS use the same Line. It's the Same line used with the x41p_zi App that doesn't have any problems with the 750Ti. I ONCE compiled an App without -gencode arch=compute_50,code=sm_50 to see what would happen. The results were the Card wouldn't work AT ALL with the Special App. This is Not good for reasons I'm sure you understand. One of these days I might compile a Special App without -gencode arch=compute_52,code=sm_52 just to see what happens with the 950s. I find it interesting the Baseline CUDA42 App doesn't have any problems with the 750Ti or the 950, and the highest gencode it has is code=sm_30. So yes, All the current Apps are using the gencode for the 750Ti, except the CUDA42 App, because it is impossible to use anything higher than 30 with Toolkit 4.2. I even use -gencode arch=compute_61,code=sm_61 when compiling with Toolkit 8. It appears I might have to go back to Darwin 15.4 and Driver 8.0.29 to make the 750Ti happy with x41p_zi3g. |
betreger Send message Joined: 29 Jun 99 Posts: 11408 Credit: 29,581,041 RAC: 66 |
IMO, for decades the fruit people have made their machines difficult, at best, to work with the rest of the world. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
It appears I might have to go back to Darwin 15.4 and Driver 8.0.29 to make the 750Ti happy with x41p_zi3g. OK, yeah gencode entries should be fine (naturally, just one possible variable eliminated). Well anyway my characteristic spider-sense is jangling (again). If you run into the same issues sending you back to building on 15.4, then in part we're probably looking at OSX C-runtime, or Cuda Runtime thread safety issues pulling into line with ~2005 Windows (which was arguably inevitable). Similar things *may* happen on the latest Linux Kernels, with slightly different symptoms, due to incorporation of revised blocklayer for nVME high bandwidth multithreaded scaling. If so, I'll probably have to find some time for comparative builds, such that we can accumulate some evidence to feed back into Boinc's library and standard buildsystem practices. "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. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
IMO, for decades the fruit people have made their machines difficult, at best, to work with the rest of the world. Yes, digging into the issues, I landed on a developer Blog: The unbearable fragility of modern OSX development ... bearing in mind he's coming from a simple utility developer direction, and talking mostly about app store publication, though certainly in a similar spirit to some of the challenges we have, and may still, run into. "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. |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13835 Credit: 208,696,464 RAC: 304 |
My latest version (and the previous one too) zi3f-zi3g give 99%+ similarity on tests. One guppi vlar finds an extra signal (low power, low average) and my inconclusives is falling rapidly. The old ones from earlier version do persist a month or so in the inconclusives though until they are validated by a third computer. When there's a Windows version ready for testing on Beta i'd be more than happy to give it a run. Or better yet, as Rastmer says, submit it to Beta for testing by as many different OS & hardware combinations as possible. Grant Darwin NT |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
My latest version (and the previous one too) zi3f-zi3g give 99%+ similarity on tests. One guppi vlar finds an extra signal (low power, low average) and my inconclusives is falling rapidly. The old ones from earlier version do persist a month or so in the inconclusives though until they are validated by a third computer. There'll definitely be wider alpha out before that, so keep an eye out. I'll be pushing Petri code toward stock as build system and users can actually support it without having to supply fire extinguishers AMD style. "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. |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13835 Credit: 208,696,464 RAC: 304 |
I'll be pushing Petri code toward stock The sooner the better IMHO; but as I understand it so far the hardware & OSs used for testing have been limited in number & scope? The more the merrier- look at all the fun M$ have with their 100,000s of testers; and still issues manage to get through. If it's looking as good as it appears to be from here, time to let Beta have a go at it- particularly with the older & slower hardware & hodgepodge of OSs & drivers. Find out just what does & doesn't work, put a line in the sand & then you can go forwards (and backwards) from there & develop it further- but at least get the present application out there (if it's good enough). It's got to start somewhere, sometime. Now would be really nice... Pretty please, with sugar on top? :-) Grant Darwin NT |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
I'll be pushing Petri code toward stock Not quite as the 'other camp' would paint. On the nVidia/CUDA side it's sheer manpower and resources. Frankly since the Guppi change nVidia is the underdog, simply because I have to work to eat [and there is ZERO real development help]. That's always a temporary measure though. I'd like it to be different, but well ---> Buy AMD? "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. |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13835 Credit: 208,696,464 RAC: 304 |
but well ---> Buy AMD? Too late for that- recently replaced one of my GTX 750Tis with a GTX 1070, and I've still got the other GTX 750Tis. AMD have improved, but NVidia still have the lead in GPU hardware. Just need the software to unleash it's potential. Grant Darwin NT |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
but well ---> Buy AMD? Well we'd all like that, but continuously seems I need to do something. Maybe it's time for people to start coughing up actual dollars into one or another cause. My Coffers are Dry. "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. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Well, I don't have a Mac Laptop, so, it would be difficult to test. The people at Beta are showing the entries though; So.... That didn't work out very well. The three problems seemed to be fixed in Yosemite with x41p_zi3g, but the 750Ti was producing Invalid Overflows. I tried it in Darwin 15.4 with the cuda 8 driver, but the Extreme Autocorrelation Peaks were back. I decided to move to Darwin 15.6 and compile a new App there with Toolkit 7.5. I also decided to try that Gencode test. I compiled 3 Apps, 1 Normal, 1 leaving out the sm52. and 1 leaving out the sm50&52. Leaving out sm52 resulted in the App still working with the 750Ti and 950s. The App without sm50&52 fails though. I believe I've seen this Error before, it's either the same, or very close to, the Error you receive when you try to compile the Special App with -gencode arch=compute_30,code=sm_30 added; ............... WU true angle range is : 0.422162 Sigma 3 Cuda error '(cudaBindTextureToArray( dev_gauss_dof_lcgf_cache_TEX, dev_gauss_dof_lcgf_cache, channelDesc))' in file 'cuda/cudaAcc_gaussfit.cu' in line 781 : invalid texture reference. </stderr_txt> I'll have to track down that Error and see if it's the same. Now, it's my understanding you should be able to run a newer card with an older App, such as running any of the new cards with the cuda50 App. But, this App will not work even though it doesn't include the older sm30. The line used in the App that fails with this Error is; NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 Right now I'm running the Normal compile in 15.6 with driver 7.5.30 to see if the 750Ti Overflows are still present. |
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 |
Well, I don't have a Mac Laptop, so, it would be difficult to test. The people at Beta are showing the entries though; The bind texture to array does not work unless there is a an exiting pre compiled array address present. The sm must be specified in the code. I noticed that when I started running 780 and cuda 6.5. 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 |
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 |
Highert gencode -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_30,code=compute_30 The bold item is to generate a general PTX for any sm_30 or higher. 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 |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
I see. Does it have to be a multiple of 10 or can it be something like, -gencode arch=compute_37,code=compute_37 or -gencode arch=compute_52,code=compute_52 I suppose that means if someone with a 1080 tries to run an App compiled with the following line it will fail? NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
For a trial build, isolation of issues rather than distribution, I would limit the embedded binary and PTX code just to the one GPU spec, for 750ti: -gencode arch=compute_50,code=sm_50 Then you should still get a hybrid binary, but with only 5.0 PTX code, and 5.0 binary. If still does something weird, then possibly looking at a cuda toolkit/library bug of some sort (possible), or a problem with the generated & embedded binary, or the driver that loads it. There is an environment variable (iirc FORCE_PTX_JIT=1, or similar), that will force drivers to compile the PTX from forward compatible embedded source in the executable. (As opposed to just on first run when no match on embedded binaries is found). From forced JIT compilation on, the binary would reside in the driver cache, and may or may not have more success than the build time embedded binaries. If forcing JIT compilation changes nothing, then less likely a toolkit issue. If it does change the situation in any functional way, then there is a system, driver, toolkit or library problem of some sort, for which the registered developer portal might need a visit. "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. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Back to the inconclusive GBT validations, could someone please post the links to these tasks that have Extreme AC Peaks? http://setiathome.berkeley.edu/result.php?resultid=5142839275 http://setiathome.berkeley.edu/result.php?resultid=5138991329 http://setiathome.berkeley.edu/result.php?resultid=5143457034 http://setiathome.berkeley.edu/result.php?resultid=5143131338 http://setiathome.berkeley.edu/result.php?resultid=5143118882 TIA |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14672 Credit: 200,643,578 RAC: 874 |
http://boinc2.ssl.berkeley.edu/sah/download_fanout/3d2/blc5_2bit_guppi_57449_45355_HIP81348_0017.14390.416.17.26.21.vlar http://boinc2.ssl.berkeley.edu/sah/download_fanout/1ce/21au10ag.26901.20545.14.41.41 http://boinc2.ssl.berkeley.edu/sah/download_fanout/214/blc5_2bit_guppi_57449_43932_HIP78775_0013.26700.831.18.27.53.vlar http://boinc2.ssl.berkeley.edu/sah/download_fanout/35/11au16aa.28481.85822.12.39.56 http://boinc2.ssl.berkeley.edu/sah/download_fanout/3a/blc5_2bit_guppi_57449_45695_HIP81348_OFF_0018.29291.831.17.26.236.vlar |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Thanks Richard. BTW, the latest Error I'm getting with LibreOffice 4.2.8.2 is; BASIC syntax error. That's after setting the security to Low (Not Recommended) Updating Libcurl3 Installing JAVA7 |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14672 Credit: 200,643,578 RAC: 874 |
Shouldn't have any Java dependency. Is that an exact literal copy of the (double) symbol parenthesis-period? Does it give an error line number or function name? I'll have a scan through the code and see what I can find. |
©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.