New Coproccesors = Desktop Renderfarms?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
  11 November 2012
http://semiaccurate.com/2012/11/12/...for-a-xeon-phi/

For those who are interested in what it takes to code for xeonphi

bottom line is, that any kind of multithreaded code (hence every raytracer) is already acceleratable by this tech. But for "substantial speedups", a single line of code would be enough for optimisation.

I don't know if there's some sort of catch here. Real world tests will clarify things soon.
__________________
"Any intelligent fool can make things bigger, more complex & more violent..." Einstein
 
  11 November 2012
Do we even have any renderers that can use that hardware? Besides the GPU renderers, since those cards don't do very good that way.
__________________
The Z-Axis
 
  11 November 2012
Originally Posted by darthviper107: Do we even have any renderers that can use that hardware? Besides the GPU renderers, since those cards don't do very good that way.


Nobody has publicly announced Xeon Phi support so far.

But knowing Intel, they probably gave a few of the important render engine manufacturers Xeon Phi sample boards well in advance of mass production starting.

Or maybe they gave them just a "Xeon Phi Software Compiler", so they can start getting used to Phi programming without having an actual Xeon Phi hardware board at hand.

Time will clarify all this...
 
  11 November 2012
Originally Posted by mustique: http://semiaccurate.com/2012/11/12/...for-a-xeon-phi/

For those who are interested in what it takes to code for xeonphi

bottom line is, that any kind of multithreaded code (hence every raytracer) is already acceleratable by this tech. But for "substantial speedups", a single line of code would be enough for optimisation.

I don't know if there's some sort of catch here. Real world tests will clarify things soon.


Well, that article really is quite simplistic. You can definitely use OpenMP to parallelize a for() loop like that, but this has been true for many years (as in, you might use OpenMP or some other threading library to parallelize code on CPUs as well, and it might be similarly easy to do).

But this fails to take into account a lot of things. There's a reason getting good threaded performance (ie, scaling) out of many applications is hard, and it has a lot to do with the fact that most applications are not in fact collections of tight, independent loops that you could simply parallelize without thinking about it. On the software side, sometimes the unit of parallelization is large (think a renderer which parallelizes on the ray-tracing for each pixel. There's tons going on for that one pixel in any production renderer). Even if the workload is what some would term "embarrassingly parallel" (again, rendering is a typical example of this) you run into problems of hardware and software limitations - memory bandwidth, cache coherency, shared data structures whose access must be serialized, portions of the code that can't be parallelized, etc.

What the Xeon Phi enables is the use of tools and paradigms that have been worked on for a very long time in a "compute" (as in the GPGPU sense) setting. No need to mess around with a new(-ish) programming language like CUDA.

The best analogy is to consider a Phi card inside a computer to be a rack of servers. Phi internally runs a Linux distro, and you can "log in" to that as if it were a remote computer and execute your code there. It will look like a massively parallel server, of course - 60 cores! But there's no "secret sauce" in Phi that auto-magically parallelizes code, if you run a single threaded application on Phi it will still run on a single thread (ie, Phi core). If your code is poorly threaded, it will still run poorly on Phi - probably more so when compared to a desktop CPU, where each core is probably much much faster.

Cheers!

Jorge
 
  11 November 2012
Cool, thanks for the explanation Jorge.

Is it fair to say that these work like the Tesla cards?

-AJ
__________________
 
  11 November 2012
Originally Posted by AJ1: Is it fair to say that these work like the Tesla cards?


Yes and no.

Yes, its a many-cored coprocessor card aimed at accelerating computations, like Tesla.

No, it doesn't run on CUDA or OpenCL code. It uses regular X86 code/instructions.

So while it is aimed at the same use as Tesla, it functions more like many X86 processors jammed together on a card.
 
  11 November 2012
Originally Posted by DePaint:
No, it doesn't run on CUDA or OpenCL code. It uses regular X86 code/instructions.



OpenCL runs on normal a x86-cpu already. For instance VrayRT can already utilize the cpu for OpenCL-Rendering.

I heard you can also run CUDA on standard x86 architecture...
 
  11 November 2012
It's not strictly like a tesla, nor the similarity to a tesla would be predicated on what library you use to write for it anyway.
It does try to shift a market that right now is looking at teslas though, but the offer is different.

It's a lot more similar to a networked renderfarm with the networking bottleneck reduced significantly by the connectivity being internal instead of cabled. It even has discrete unit management through TCP/IP.

The breakthrough isn't in how fast it is or any of that, the breakthrough is the sheer amount of units it can pack into a certain volume and at what power cost.

It's clearly aimed at computational centres first, and the potential push in the future for cloud resourcing, which might one day move to super global, far away large aggregations to a much denser cloud of smaller units in closer reach.
IE: every building gets one much like ISPs and telcos now provide some buildings with what are basically fully fledged servers and routing smaller bandwidth users inside that building.

Also, unlike the Tesla, this isn't a very large set of small and relatively specialised units, it's a smaller set of more generally purposed units that can take on more, be virtualised and managed more efficiently, and try to make the main CPU become the coordination centre and shoulder unit for a larger network of other units contained in these cards.

In a way it's Larrabee making a comeback.
Its consequences will at some point reach end users, I'm sure, but I doubt the first couple years are intended to produce anything you'd feel the need for at home.
On top of that, the moment enough development is done for it in the form of infrastructure and actual software, that also allows for the home CPUs to keep scaling horizontally in width rather than try to hit higher in cycles, which are fast approaching the physical limitations of the materials involved and become harder every year to beat and manufacture competitively.
__________________
Come, Join the Cult http://www.cultofrig.com - Rigging from First Principles
 
  11 November 2012
i tried to google up some photos of the old 486 DX 66 parallel rendering expansion cards we use to use (mid '90s) with Digital Arts (DGS) without success.. i saw my linked in profile listed, which is kinda scary (guess i should get rid of that old crap).

this all reminds me of those days when you could stick a bunch of them in a box to offload rendering... wouldn't that be fun to do again?
 
  11 November 2012
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 05:57 PM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.