NVIDIA SHIELD! I can't wait to run SETI on it!

Message boards : Number crunching : NVIDIA SHIELD! I can't wait to run SETI on it!
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile GTP

Send message
Joined: 5 Jul 99
Posts: 67
Credit: 137,504,906
RAC: 0
United States
Message 1648991 - Posted: 4 Mar 2015, 5:17:30 UTC

Looks like a cheap cruncher, any thoughts?

https://gigaom.com/2015/03/03/nvidia-reveals-shield-a-199-console-for-4k-tv-and-gaming/

All the best,
Aaron Lephart
ID: 1648991 · Report as offensive
Profile Cliff Harding
Volunteer tester
Avatar

Send message
Joined: 18 Aug 99
Posts: 1432
Credit: 110,967,840
RAC: 67
United States
Message 1649109 - Posted: 4 Mar 2015, 12:31:34 UTC

Guru3D.com put this up on their site this morning, and the short video sounds like Maximus Prime. http://www.guru3d.com/news-story/nvidia-announces-shield-console.html


I don't buy computers, I build them!!
ID: 1649109 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1649112 - Posted: 4 Mar 2015, 12:49:22 UTC - in response to Message 1648991.  

Multibeam support (at least) for that could be relatively quick, since it should I guess run Cuda natively (taking the specs at face value). Should manage OpenCL too, though I haven't read the Tegra SDK details on that. For My Nexus 9, I'm having to look at the viability of a Renderscript port as well, because Google decided to go with their own language instead of using Cuda and/or OpenCL.

So early days, but could be a nice thing. One kicker would seem to be having 256 cores (which would be 2 Maxwell multiprocessors), it'd be very low power, but not necessarily a slouch (even considering the slower ARM architecture memory subsystems, done for low power and cost).
"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: 1649112 · Report as offensive
Profile ivan
Volunteer tester
Avatar

Send message
Joined: 5 Mar 01
Posts: 783
Credit: 348,560,338
RAC: 223
United Kingdom
Message 1649410 - Posted: 5 Mar 2015, 3:55:13 UTC - in response to Message 1649112.  

Multibeam support (at least) for that could be relatively quick, since it should I guess run Cuda natively (taking the specs at face value). Should manage OpenCL too, though I haven't read the Tegra SDK details on that. For My Nexus 9, I'm having to look at the viability of a Renderscript port as well, because Google decided to go with their own language instead of using Cuda and/or OpenCL.

Guess it's time to ask (again) if anyone's managed to get MB CPU tasks running on a Tegra TK1 Jetson. I got the CUDA version running relatively easily, and my digital hologram reconstruction, but when I tried the CPU version -- it runs fine manually, but crashes when run as a BOINC task. I should really look at it again but at the moment I'm up in my all in assigators trying to bridge the gap between xxxx IT and yyy scientists to get yyy@Home running for volunteer computing. (Of course, most of you know what xxxx and yyy are, but I'd better be circumspect.) With a little bit of luck, we'll have things ready for the public in late autumn; with a lot of luck, earlier!
ID: 1649410 · Report as offensive
Claggy
Volunteer tester

Send message
Joined: 5 Jul 99
Posts: 4654
Credit: 47,537,079
RAC: 4
United Kingdom
Message 1649431 - Posted: 5 Mar 2015, 5:09:58 UTC - in response to Message 1649410.  

Multibeam support (at least) for that could be relatively quick, since it should I guess run Cuda natively (taking the specs at face value). Should manage OpenCL too, though I haven't read the Tegra SDK details on that. For My Nexus 9, I'm having to look at the viability of a Renderscript port as well, because Google decided to go with their own language instead of using Cuda and/or OpenCL.

Guess it's time to ask (again) if anyone's managed to get MB CPU tasks running on a Tegra TK1 Jetson. I got the CUDA version running relatively easily, and my digital hologram reconstruction, but when I tried the CPU version -- it runs fine manually, but crashes when run as a BOINC task. I should really look at it again but at the moment I'm up in my all in assigators trying to bridge the gap between xxxx IT and yyy scientists to get yyy@Home running for volunteer computing. (Of course, most of you know what xxxx and yyy are, but I'd better be circumspect.) With a little bit of luck, we'll have things ready for the public in late autumn; with a lot of luck, earlier!

I've managed to do workarounds to get Armv7 to compile on Linux, and another workaround to the softfloat specific Neon and VFP rountines to not get called on Linux too, (Armv6 is still a work in progress),
Raistmer has committed my workarounds to the Seti Source tree at r2858, and Gianfranco Costamagna to the Debian source tree at 7.28_svn2781:

https://setisvn.ssl.berkeley.edu/trac/timeline

http://anonscm.debian.org/cgit/pkg-boinc/boinc-app-seti.git

r2858 works, not tried the Debian version yet, hopefully i'll get it running on one of my Parallellas today:

https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa

Claggy
ID: 1649431 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1649500 - Posted: 5 Mar 2015, 8:44:04 UTC - in response to Message 1649431.  

That "runs standalone, crashes under BOINC" issue becoming common it seems.
Same situation describes TBar in his thread about OS X build (not ARM but x86 BTW). Similar issue had few Eric's Android builds on SETI beta (ARM) (runs OK standalone, crashes with signal 11 or another while running live). Perhaps one needs to understand differencies in app's used processing path for standalone and live (under BOINC) operation to successfully overcome this issue.
ID: 1649500 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1649507 - Posted: 5 Mar 2015, 9:04:02 UTC - in response to Message 1649500.  
Last modified: 5 Mar 2015, 9:06:42 UTC

That "runs standalone, crashes under BOINC" issue becoming common it seems.
Same situation describes TBar in his thread about OS X build (not ARM but x86 BTW). Similar issue had few Eric's Android builds on SETI beta (ARM) (runs OK standalone, crashes with signal 11 or another while running live). Perhaps one needs to understand differencies in app's used processing path for standalone and live (under BOINC) operation to successfully overcome this issue.

Presumably, 'running live' means 'running as an anonymous platform application' under app_info.xml

On a hunch, try putting

<api_version>6.1.0</api_version>

into the app_version section of app_info, as in the example in https://boinc.berkeley.edu/wiki/Anonymous_platform.

(Edit - this suggestion really aimed at TBar's OS X problem, but it's free to try on other platforms as well)
ID: 1649507 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1649512 - Posted: 5 Mar 2015, 9:17:11 UTC - in response to Message 1649507.  


Presumably, 'running live' means 'running as an anonymous platform application' under app_info.xml

Running live meant running with interaction with BOINC. Mentioned issues with Android apps on beta were for "stock" runs. But indeed what we can not do with stock we can with anonymous_platform. Maybe there are few different issues some of them could be fixed by downgrading to older communication protocol.
For completness could you briefly point changes between that 6.1.0 API and current one?
ID: 1649512 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1649519 - Posted: 5 Mar 2015, 10:17:49 UTC - in response to Message 1649512.  
Last modified: 5 Mar 2015, 11:06:15 UTC

Presumably, 'running live' means 'running as an anonymous platform application' under app_info.xml

Running live meant running with interaction with BOINC. Mentioned issues with Android apps on beta were for "stock" runs. But indeed what we can not do with stock we can with anonymous_platform. Maybe there are few different issues some of them could be fixed by downgrading to older communication protocol.
For completness could you briefly point changes between that 6.1.0 API and current one?

No, it's the difference between the 6.1.0 API and the previous one.

BOINC v5 and before used shared memory for communication between the client and the application. Starting with v6 in about 2007, that was changed to memory-mapped files. The BOINC client needs to know which communication model to use when it starts the application: as we know from bench testing, free-running Windows applications post reports about the inaccessibility of shared memory when they start up.

The rather cludgy <api_version> construct in app_version simply tells the client to use the newer v6 convention when starting the application, instead of the (default) shared memory approach.

All of this makes not the blindest speck of difference in Windows, because there isn't a system-provided shared memory segment (BOINC creates its own when needed). But it does matter on *nix-type systems, and most particularly on OS X. Because of this:

http://www.spy-hill.net/help/apple/SharedMemory.html

"The default configuration for shared memory on a Mac is best described as 'minimal'". Especially on multi-core computers, it rapidly runs out, and signal 11 indicates memory access problems. Running OS X applications in v6 communications mode just might help to eliminate one source of signal 11 errors.

Edit - refer also to Questions and Answers : Macintosh : Increase the number of concurrent tasks beyond 8, which is what started me on this research in the first place.
ID: 1649519 · Report as offensive

Message boards : Number crunching : NVIDIA SHIELD! I can't wait to run SETI on it!


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