Return-Path: Received: from mail-lb0-f169.google.com ([209.85.217.169] verified) by media-motion.tv (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 4901183 for ae-list@media-motion.tv; Fri, 16 Nov 2012 05:16:53 +0100 Received: by mail-lb0-f169.google.com with SMTP id gk1so1656493lbb.28 for ; Thu, 15 Nov 2012 20:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Sqe97kerlCl/hPvrEkH8VlOAuJmlc81ynY8fQ7Tkt2Q=; b=afPdyFcVVyrbkO00tXVnFYD7HxGK98FuPOh0+GEDbA5naDmxLDO7EXqs7mOpUUGwl5 vivnbXnuh3Jb4Zar6m3bMezn65H4V42XVKNLgCnhZikvgVVq2UAmkkWD/0y+5iVM0ksn sWRr9STkduNVDIkej8c/qjE8kyD5ICazBBdB5pDTqNFijgfiaApihcKJrslJ0qavL7xC WOXp4Anc73nZmbhU6AyQNiPqxJ2l/tAF5U8YN0LG9IHL3bLyDLVewHF+x7h48X+rNYp5 4WUJQSoLhAh0tY6eFVzvAiUwcAcvfNIBQtMxE7EPxRG61+VYLb6ezwTAhPaJF8CQyAgJ 38rQ== MIME-Version: 1.0 Received: by 10.112.26.130 with SMTP id l2mr1490990lbg.41.1353039613200; Thu, 15 Nov 2012 20:20:13 -0800 (PST) Received: by 10.112.135.41 with HTTP; Thu, 15 Nov 2012 20:20:12 -0800 (PST) Received: by 10.112.135.41 with HTTP; Thu, 15 Nov 2012 20:20:12 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 23:20:12 -0500 Message-ID: Subject: Re: [AE] [OT] Intel's 50-core Xeon Phi Processor From: Teddy Gage To: mylenium@mylenium.de, After Effects Mail List Content-Type: multipart/alternative; boundary=bcaec55555a0830b4604ce951512 --bcaec55555a0830b4604ce951512 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Don't forget fluid simulation and other dynamic particles. Real flow can utilize hundreds of CPUs with very low memory overhead. I've always wanted to test out a Maximus setup, now maybe I could afford a phi. On Nov 15, 2012 10:34 PM, "mylenium@mylenium.de" wrote: > ** > Not sure what the fuss is about. Your normal Xeon processor has 8MB of L= 3 > caches and you don't store image buffers in that, either. From what littl= e > reading I have done on the Phi card, internally all memory management and > syncing is handled by the processors themselves via ring buses and crossb= ar > switches in groups of 2, 4 or 8 cores, but that only really includes the > caches and the internal processing queue. Also by the time you would > process data on the card it would long be pre-segmented and unlike graphi= cs > cards, there would be no persistent buffers requiring extensive amounts o= f > memory. The rest would be handled in the system memory and the beauty of = it > is that since the Phi card uses native x86/SSE etc. commands, there is no > need for any extra data conversions or explicitly shuffling stuff around > beyond what your system already does, anyway. Of course on some level it > still has similar requirements like CUDA in terms of parallelizing stuff, > but as Greg said, the biggest issue for the card at this point will be > limited PCI transfer speeds. That's why primarily it will make inroads in > science first most likely as well as 3D renderers that already to data > segmentation/ bucketing/ tiling and by comparison the processing outweigh= s > the data transfers. I wouldn't expect it to be relevant for anything else > soon. Where intel will take this technology is another question consideri= ng > how they have been mucking around for years, but generally I would not > expect them to follow the same road that CUDA has. > > Mylenium > > [Pour Myl=E8ne, ange sur terre] > ----------------------------------------- > www.mylenium.de > > Steve Oakley hat am 15. November 2012 um 23:15 > geschrieben: > > my math says each CPU would get 161mb of RAM.... despite what intel says, > writing code to work well in this environment would not really be much > different than CUDA. you certainly could not run an OS + App + App data o= n > each core. thats fantasy. you could probably write a renderer to fit into > that space and have some image buffers.... but when you watch AE eat a > couple gigs for large deep color renders, their model pretty much doesn't > work. At best, you instead would need to MP render each frame, tiling it = up > and feeding each CPU a chunk of it. very different than what intel is > pitching. you'd need more like 64gb or 128gb to really make it work they > way they say. > > > S > > On Nov 15, 2012, at 4:06 PM, Byron Nash < byronnash@gmail.com> wrote: > > So, in theory would a multi-threaded renderer like Mental Ray be able to > utilize all those coprocessor cores? If so, I imagine you would need a lo= t > of RAM in the machine. > > > On Thu, Nov 15, 2012 at 11:20 AM, Greg Balint wrote: > > Yes, but the 8Gb on-board can be accessed at 320Gb/s whilst the rest of > your System RAM can only be accessed by those cores on the PCIe 2.0 card = at > 16GB/sec. Sounds like a bottleneck, but current modules Peak Transfer Rat= es > are only around 17Gb/s tops, and that's for DDR3-2133 RAM. The biggest > issue would be considering the RAM bus would also be the same bus used f= or > Storage writing and reading, and instruction transit. and what memory > controller would control those 50 CPUs access to your RAM through your PC= Ie > 2.0 bus.. sounds like it could be a nightmare for applications such as AE > with constant I/O and instructions being sent.. > > I'd hope one day I can just go purchase a $1500-$2000 card, and basically > get an internal render-farm.. but I think software would need to catch up > to that concept and it would need to go mainstream before we'd really see= a > lot of applications for it.. I do see the potential, and it seems to > pretty much be a given-future.. "Core-Boards" will probably end up being > the next step up from the OnBoard Chips. In the future, it'll all be abo= ut > OC'ing the CoreBoard and the Motherboard being the controller of that > CoreBoard. > > Just think.. at some point, there'll probably be configurable RAM options > on the CoreBoards, and then we'd need Integrated Video for these > CoreBoards.. > > Basically building a full System Build on a Board that goes in your Full > System Build... then you can Cross-fire those boards together in one Case= .. > > Turtles all the way down... > > > ///Greg Balint > //Art Director / Motion Graphics Designer > /321.514.4839delRAZOR.com/ > > On 11/15/2012 9:58 AM, mylenium@mylenium.de wrote: > > It's my understanding that it will appear as just another processor to > the system and thus will share the system's memory. Those 8GB are more or > less just its internal caches. > > Mylenium > > [Pour Myl=E8ne, ange sur terre] > ----------------------------------------- > www.mylenium.de > > mike cardeiro hat am 15. > November 2012 um 15:32 geschrieben: > > sounds cool...wonder why they are only allocating 8gb of ram (did you > ever think you'd see the day when you said *only* 8 gigs of ram) > > Mike Cardeiro > Editor/Animator/Compositor > D4 Creative Group - Philadelphia, PA > > http://www.michaelcardeiro.com/resume/ > http://www.youtube.com/user/mcardeiro > > > > > ------------------------------ > *From:* Satya G Meka (Lists) > *To:* After Effects Mail List > *Sent:* Thursday, November 15, 2012 9:22 AM > *Subject:* [AE] [OT] Intel's 50-core Xeon Phi Processor > > Fellow Ae-Listers, > > You might find this interesting. > > http://www.drdobbs.com/parallel/intels-50-core-xeon-phi-the-new-era-of-i/= 240105810?donkey > > I do wish it competes directly with GPUs in the future. > > regards, > Satya. > > > > > > > > --bcaec55555a0830b4604ce951512 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Don't forget fluid simulation and other dynamic particle= s. Real flow can utilize hundreds of CPUs with very low memory overhead. I&= #39;ve always wanted to test out a Maximus setup, now maybe I could afford = a phi.

On Nov 15, 2012 10:34 PM, "mylenium@mylenium.de" <mylenium@mylenium.de> wrote:
=20
=20 =20 =20 =20
Not sure what the fuss is about. Your normal Xeon processor has 8MB of L= 3 caches and you don't store image buffers in that, either. From what l= ittle reading I have done on the Phi card, internally all memory management= and syncing is handled by the processors themselves via ring buses and cro= ssbar switches in groups of 2, 4 or 8 cores, but that only really includes = the caches and the internal processing queue. Also by the time you would pr= ocess data on the card it would long be pre-segmented and unlike graphics c= ards, there would be no persistent buffers requiring extensive amounts of m= emory. The rest would be handled in the system memory and the beauty of it = is that since the Phi card uses native x86/SSE etc. commands, there is no n= eed for any extra data conversions or explicitly shuffling stuff around bey= ond what your system already does, anyway. Of course on some level it still= has similar requirements like CUDA in terms of parallelizing stuff, but as= Greg said, the biggest issue for the card at this point will be limited PC= I transfer speeds. That's why primarily it will make inroads in science= first most likely as well as 3D renderers that already to data segmentatio= n/ bucketing/ tiling and by comparison the processing outweighs the data tr= ansfers. I wouldn't expect it to be relevant for anything else soon. Wh= ere intel will take this technology is another question considering how the= y have been mucking around for years, but generally I would not expect them= to follow the same road that CUDA has.
=20
=A0
=20
Mylenium
=20
=A0
=20
[Pour Myl=E8ne, ange sur terre]
-----------------------------------------
www.mylenium.de=
=20

Steve Oakley <steveo@practicali.com> hat am 15. November 2012 um 23:15 ges= chrieben:
=20
=20
my math says each CPU would get 161mb of RAM.... despite what intel say= s, writing code to work well in this environment would not really be much d= ifferent than CUDA. you certainly could not run an OS + App + App data on e= ach core. thats fantasy. you could probably write a renderer to fit into th= at space and have some image buffers.... but when you watch AE eat a couple= gigs for large deep color renders, their model pretty much doesn't wor= k. At best, you instead would need to MP render each frame, tiling it up an= d feeding each CPU a chunk of it. very different than what intel is pitchin= g. you'd need more like 64gb or 128gb to really make it work they way t= hey say.=20
=A0
=20
=A0
=20
S
=20

=20
=20
On Nov 15, 2012, at 4:06 PM, Byron Nash < byronnash@g= mail.com> wrote:
=20
=20
So, in theory would a multi-threaded renderer like Mental Ray be abl= e to utilize all those coprocessor cores? If so, I imagine you would need a= lot of RAM in the machine.=20


=20
On Thu, Nov 15, 2012 at 11:20 AM, Greg Balint=20 <g= reg@delrazor.com> wrote:
=20
=20
=20
Yes, but the 8Gb on-board can be accessed at 320Gb/s whilst the= rest of your System RAM can only be accessed by those cores on the PCIe 2.= 0 card at 16GB/sec. Sounds like a bottleneck, but current modules Peak Tran= sfer Rates are only around 17Gb/s tops, and that's for DDR3-2133 RAM. T= he biggest issue would be=A0 considering the RAM bus would also be the same= bus used for Storage writing and reading, and instruction transit. and wha= t memory controller would control those 50 CPUs access to your RAM through = your PCIe 2.0 bus.. sounds like it could be a nightmare for applications su= ch as AE with constant I/O and instructions being sent..=20
=20
I'd hope one day I can just go purchase a $1500-$2000 = card, and basically get an internal render-farm.. but I think software woul= d need to catch up to that concept and it would need to go mainstream befor= e we'd really see a lot of applications for it..=A0 I do see the potent= ial, and it seems to pretty much be a given-future.. "Core-Boards"= ; will probably end up being the next step up from the OnBoard Chips.=A0 In= the future, it'll all be about OC'ing the CoreBoard and the Mother= board being the controller of that CoreBoard.
=20
Just think.. at some point, there'll probably be confi= gurable RAM options on the CoreBoards, and then we'd need Integrated Vi= deo for these CoreBoards..=A0=20
=20
Basically building a full System Build on a Board that goe= s in your Full System Build... then you can Cross-fire those boards togethe= r in one Case..=20
=20
Turtles all the way down...


= =20 
///Greg Balint
//Art Director / Motion Graphics Designer
/321.514.4839
delRAZOR.com/
= =20
=20
On 11/15/2012 9:58 AM,=20 myl= enium@mylenium.de wrote:
=20
=20
=20
=20
=20
=20
It's my understanding that it will appear as just anothe= r processor to the system and thus will share the system's memory. Thos= e 8GB are more or less just its internal caches.
=20
=A0
=20
Mylenium
=20
=A0
=20
[Pour Myl=E8ne, ange sur terre]=20
-----------------------------------------=20
=20 www.my= lenium.de
=20

mike cardeiro=20 <= ;mcardeiro@yahoo.com> hat am 15. November 2012 um 15:32 geschrieben:
=20
=20
=20
=20
sounds cool...wonder why they are only allocating 8= gb of ram (did you ever think you'd see the day when you said *only* 8 = gigs of ram)
=20

=20
=20
Mike Cardeiro
Editor/Animator/Compositor=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
D4 Creative Group - Philade= lphia, PA=A0=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
http://www.michael= cardeiro.com/resume/
http:/= /www.youtube.com/user/mcardeiro
=20

=20
=20
=A0
=20

=20
=20
=20
=20
From: Satya G Meka (L= ists) <lists@rowb= yte.com>
To: After Effects= Mail List <= ;AE-List@media-motion.tv>
Sent: Thursday, November 15, 2012 9:22 AM
Subject: [AE] [OT= ] Intel's 50-core Xeon Phi Processor
=20
=20
=20
Fellow Ae-Listers,
=20
=A0
=20
You might find this interesting.
=20 =20
=A0
=20
I do wish it competes directly with GPUs in the futu= re.
=20
=A0
=20
regards,
=20
Satya.
=20
=A0
=20
=20
=20
=20
=20
=20
=20
=20
=20
=A0
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=A0
=20
--bcaec55555a0830b4604ce951512--