Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Opinions: Does the New Mac Pro qualify as a Workstation?
- Thread starter Dr. Stealth
- Start date
- Sort by reaction score
Yep, that's been the trend for 3 to 5 years now. LW3D for example had F-Prime from Steve Worley (partial GI & Radiosity real time preview and render engine) for gee, about 7 or 8 years I think. In late 2009 NewTek tasked us to develop and integrate it's now not-so-new real-time VPR (Virtual Preview Renderer) previewer which does GI, Radiosity, real-time anaglyph stereoscopic interocular previews, real-time 'red-blue' anaglyphic separations, our node based shaders, and a few other goodies. Combined with the new Virtual Studio and Interchange Tools makes it incredibly interesting. VS/IT essentially allows one to control the lights, camera and CA with HIDs like a playstation controller or even linked to real-world camera. So you can act as an actual cameraman, puppeteer, gaff&grips, or etc. on a virtual set with both live actors (MoCaped using NevronMotion Tools) and props and virtual ones - all in real-time. I think Rob made a demo of this somewhere.
http://www.ustream.tv/recorded/36316735 <-- With NevronMotion in LW 11.5 IIRC
LW Native (I think also version 11.5) showing just the VS/IT:
You can see the VPR in action is all three of those I think - the bottom two for sure.
Last edited:
you say that as if it's an insult but i'm sure you're completely comfortable sitting around thinking no one will need more than 4GHz :/
the problem is, however, the reason everyone is so seemingly comfortable with this (basically) topped out clock speed is because you all simply put the race on amount of cpus.. and applying all the same exact logic behind it.. 'hell yeah baby! we're still drag racing wheeeee~'
make it bigger.. add more hardware.. and after that.. add some more.. screw it
there are better solutions available.. i'm sorry
Last edited:
those kind of videos, nobody wants to see around here.. it's like they don't (or don't want to?) believe it
Yup! this and the other 4 or 5 threads like it are just chalk-full of these "reality deniers" - weirdest thing I've ever seen. People misusing/misunderstanding hardware with incomprehensibly irrational workflows attempting to force everyone onto their own personal bash-wagon. It seems to only be 4 or 5 guys but they're the broken records in most such threads - repeating the same (incorrect) opinions over and over even after being shown the facts and potentials... UG!
I haven't checked specifically but it seems like it might be the same "group" who were just a month ago saying the MP line was dead and gone (also over and over and over). So now Apple offers a workstation a little ahead of the curve and it's bash-wagon-zilla.
Funny to watch. Annoying and frustrating to try and participate.
Last edited:
yeah.. it's weird.
at the end of the day though, it's just a bunch of dudes sitting around talking shlt on the interwebs about something that ranks around ten-million on the what's_really_important scale..
ie- having fun
yeah.. it's weird.
at the end of the day though, it's just a bunch of dudes sitting around talking shlt on the interwebs about something that ranks around ten-million on the what's_really_important scale..
ie- having fun
tru-dat.
Not quite. I'm saying that the definition is reasonably morphable on the down-in-the-weeds specifics, but what a Workstation pragmatically is, is the 'desktop' solution for the top tier of the Use Cases which results in differentiation.
For example, everyone's PC needs data storage ... but for those with what I'll call 'Storage Centric Workstations', instead of the average consumer's 1TB single HDD, there's 10x as much.
Similarly, everyone's PC needs RAM ... but for the 'RAM Centric Workstation', instead of 4GB, there's 32GB or more.
For visual display-centric, instead of one 22" display, there's a pair of 27's (or more).
For computing horsepower, instead of a dual-core CPU, there's more cores, higher clocks, etc.
For GPU, ... etc. For HDDs vs SSDs, ... etc. This "in the weeds" list can go on and on.
Because higher levels of capabilities aren't free is why we need to acknowledge mission tailoring and equipment morphability: to be a "Workstation" doesn't pedantically have to require exceeding average in every single category/metric.
Insofar as how many of them (and by how much), that's a gray area, but it is almost certainly going to be more than just one of them. FWIW, perhaps a useful way to look at this is analogous to a High School report card: the GPA just needs to be clearly above average (call it a B average), which means that it is okay to have a few C's...and unlike High School, someone getting straight A's except for one C, doesn't disqualify them from being on the 'Workstation Honor Roll'.
-hh
You never really debunked that some people might want >12 processors. When 3-4 people gave you a bunch of examples of programs and activities that would benefit, you literally said their opinion is "wrong" and started circlejerking with Flat-Five about how wrong everyone is.
That is not "debunking" as far as I know.
Yeah, that's debunking... well not the way you make it sound tho. I saw one person post examples, beaker7. And MVC added one app to the list. The only one that actually made any sense was RealFlow - and only for a few operations. All the others they work better net-rendering off the main system. And that's where it's debunked. Seriously, as I mentioned to Mr. Stealth here, insisting on configuring your workstation to render projects locally (on it) or just doing so anyway would get you fired from any studio on the planet. That's not my opinion, that my experience and common sense from having owned and operated a very successful studio and from having worked inside a few dozen others. I tried to say it in a funny way as to not offend but pressed to it, it's the cold hard truth. And doing the same with a bedroom boutique is just as ridiculous! Cost, Power, actual Project ETA, DoL, all suffer doing it that way. It's such a misconceived notion it deserves a "debunked" classification.
Sorry if this is an obvious question, but as someone who doesn't know a lot about commercial rendering software, I curious about render farms versus local attached cards on Thunderbolt. I'm guessing (but please correct me if I'm wrong) that render farms are networked at no faster than 10Gb ethernet (perhaps even 1Gb). And as modern GPUs have quite a lot of very high speed memory, would it really be a problem to render using a bunch of cards attached to 20Gb Thunderbolt 2? I'm really asking is there a fundamental problem shunting the workload out to the cards over TB vs. a network? (I know it would be faster over PCIe 3 - I'm just asking isn't there just as much bottleneck with a render farm as with TB)
It all depends on if the data can be splitted in small independent unit to be individually processed. The problem of performance arrive when one unit needs data from one or many other units that aren't in the same memory address space, because then it has to play musical chair with the data.
RAM -> CPU -> TB -> ExtGPU_1 -> TB -> CPU -> RAM -> CPU -> TB -> ExtGPU_2 -> ect...ect...
TB = x4 PCIe and thing can get slower if you daysie chain devices and both are competing for the wire.
Compared to
RAM -> CPU -> GPU_1 -> CPU -> RAM -> CPU -> GPU_2 ->...
Here the two GPU are x16.
This situation shouldn't happen on small and simple renders but on heavy complex scene it will happen.
Thanks, but how does the TB compare to the traffic that would need to go over the network on a render farm. Ie wouldn't there be RAM -> CPU -> Network -> CPU on slave machine -> GPU etc.
I'm just wondering how a render farm splits up the task and how it sends the component parts between slave machines. (I may be completely misunderstanding how a render farm works -
)Thanks, but how does the TB compare to the traffic that would need to go over the network on a render farm. Ie wouldn't there be RAM -> CPU -> Network -> CPU on slave machine -> GPU etc.
I'm just wondering how a render farm splits up the task and how it sends the component parts between slave machines. (I may be completely misunderstanding how a render farm works -
You asked if TB would be a bottleneck, I told you it could be.
Over network you have to factor the protocol overhead also.
It all comes to how the software that manage the render farm is written. If you just upload it to a central depository and then the system split the project in individual part to be processed independently on each node to be recombined at the end, then it should be comparable to my second schema plus the transfer time and splitting overhead. The last two can be compensated by the fact that your workstation is free for other use while the render farm does it's work. Oh, you also have to factor in the time and bandwith required to move your project and ressources to and from the render farm.
you're worrying about thunderbolt and render farms? because no, there's not going to be a bottleneck.
a typcial example of a renderfarm service:
http://www.renderrocket.com
put 2&2 together and realize you'll be getting 800 cores at your disposal over the internet.. i mean, yeah- you might want to upgrade your 56k modem if you're going to be using a renderfarm but thunderbolt speeds should be the least of your concerns..
i don't think that's debunkable.. you really want 13 cores? fine. i can accept that and it would be completely useless for me to try to argue that you don't want 13 cores.. especially when i already know you do. i.e.- i agree with you.
here's the problem though-- i want 14 cores. now what?
(and in case you're not realizing what's going on, it's this --> you are giving an argument about 13 cores as if it's somehow the nail in the coffin of the discussion... but then i turn around and give you the _exact_ same argument back but you ignore it.. you're ignoring the very thing that you're arguing to begin with.. you realize it's a bs argument when someone uses towards you but then think it's the best argument ever when you use it towards them.. that is what bs is.. it's the argument itself that has been debunked)
Please send me your copy of Maxwell that does this. Mine doesn't have this functionally and neither does the upcoming 3.0 release. Did you get your hands on 4.0?
lol.. wow. (and who is 'we' by the way?)
people argue me.. i say the same argument back as an attempt to make sure they realize what they're saying.. this makes me a troll?
really? that's your logic process? i can't wait to hear you apply that logic to "why the new mac is not a pro machine" :/
----------
is it at all possible you're using the wrong software then blaming hardware as your slowdown?
here's a video that's over 2 years old..
it's indigo which is a direct competitor to maxwell.. (meaning they're both unbiased render engines.. the slowest type but arguably the best results)
http://www.youtube.com/watch?v=-SQtyw3rEEw
are those previews not fast enough for you? just watching the video, it appears you can have a usable preview in under 5 seconds.. don't like it? switch it up and wait another 5 seconds..
if maxwell isn't going to go the gpu accelerated route and you'd rather blame apple for only offering a 12core machine then that's your prerogative i guess..
but it's actually not a very good argument as to why someone needs more than a single socket.
it's indigo which is a direct competitor to maxwell.. (meaning they're both unbiased render engines.. the slowest type but arguably the best results)
http://www.youtube.com/watch?v=-SQtyw3rEEw
are those previews not fast enough for you? just watching the video, it appears you can have a usable preview in under 5 seconds.. don't like it? switch it up and wait another 5 seconds..
if maxwell isn't going to go the gpu accelerated route and you'd rather blame apple for only offering a 12core machine then that's your prerogative i guess..
but it's actually not a very good argument as to why someone needs more than a single socket.
Last edited:
The silly repartee, the derogatory comments, the spamming of the same debunked crap over and over again, the logical fallacies... Yes that's trolling.
Again trying to tell what tools they should use when you don't know what it is the other peoples are doing.
You design skateboard ramps... Not the most demanding of task really. My company design hydro electric dams, powerlines and nuclear power stations worldwide. Do you think your workflow can be applied to my work? Really?
well, at least you're consistent in your logic.
depends.. i'm not quite clear on what you mean when you say 'my' company..
are you telling people what to do or are people telling you what to do?
Are you trying to pretend that you're also an expert on IT management also?
Oh well, back to the ignore list you go... No more time to waste on trolls.
- GPU Over TB1 & TB2
I think it would be OK but the number of GPU additions you could add over TB1 compared to TB2 would be about half (before some bottleneck reared up). We were recently shown a Tom'sHardware GPGPU benchmark where there was less than a 3% speed difference between a fast GPU in a PCIe x16 v3 card edge slot and the same card connected via TB1. I suppose that 3% is completely due to latency. I also assume that the TB port used could have had maybe 3 or so of the same GPUs connected before there would be any bottleneck issues (so maybe 6 per TB2 port?). I think GPU cores are only reasonable over TB in almost all cases - because other network types are too slow to handle the traffic. GPGPU rendered frames for CG preview and video very often render in a few seconds or less. Almost no CG (3D) applications have engines which use GPGPUs to render or assist in rendering finished animation frames - this may be changing but I'm unaware of it if so.
- CPU Over 1000BaseT (MP Ethernet)
Typically CPU based rendering engines require more than 10 seconds to complete a single frame. And much more often it's well over 5min. per frame. So a CPU based networked render farm even over 1000BaseT ethernet, almost never experiences a bottleneck. In most render managers a frame transfer time of about 0.25 to 0.5 seconds is added for each frame (including protocol and latency overheads) in the cases where the rendered outputs are targeted to the same fileserver and not stored on the node for later retrieval. So for example if each frame were rendering in 1min. and taking 0.5s to transfer you could have approximately 120 machines before there would be any noticeable contention over the network. It would probably be wiser to keep it at around 90 machines just in case but yo get the idea - no observable bottleneck unless your nodes are rendering absurdly fast.
- CPU Over TB1 & TB2
Recently there have been a number of new devices I'm not completely familiar with beyond researching their outside specifications and reading about how they are or could be used in a system. These include independent coprocessors such as the Intel Phi and a multitude of Single Board Computer (SBC) models - either of which use a PCIe card edge connection to their host system. Both the Phi's and the SBCs appear to the host computer as a complete and separate networked node or nodes over a virtual network layer. Most all these cards have their own memory, their own processors (Xeon E3 or etc.), their own attached storage (SATA3 or other - with embedded RAID 0,1,5, etc. controllers), USB3, their own display ports HDMI or other, and so on. So such cards (possibly between 12 and 24 of them on the MP6,1) sit in TB2 PCIe adapter enclosures which have their own power supplies and appear to the MP6,1 as networked CPU nodes - just like your laptop might look to it if connected and shared over ethernet.
There are also devices which act similar to ethernet hubs but using Thunderbolt instead so under the category of "CPU [based rendering] Over TB1 & TB2" I suppose those should be mentioned as well. Basically this would look and act like CPU Over 1000BaseT but be much faster. I think not interesting unless one is attempting CPU distributive renders of large video files across multiple nodes. If you're an AE or Premiere jock this may be worth looking into - I'm not sure.
- Free And Commercial CPU based Render Managers (RM).
About 7 years ago I guess it was I wrote a very long article on Render Managers and I had to stop including suggested RMs after the number got up around 30 or so. Just to say that there are probably more available today and that's a buttload! The one which sticks in my mind the most is called SquidNet simply because it can manage renders from multiple applications simultaneously across as many nodes as you're likely to ever have bankroll for. But again there are many others and many are free. The basic idea of a "good" RM is to take any part of your project you can define usually via time-line selection and with the press of a key send that portion (or the project in it's entirety) to a set of network nodes (single, partial, or multiple machines) to be rendered - where the output is typically sent to a common target folder or application. Typically then cron type BG tasks like maybe FolderWatch or something you whip up in Apple's Automator/AS automatically assemble the outputted results into whatever formats you choose.
- So as a few typical example RM workflows:
- Imagine you're doing some character animation and you really wanna know how the textures are looking in the final rendered output because your deformations are too ugly in the real-time previewer (or maybe your app does't yet have a real-time previewer). You would select the portion of the timeline you're interested in and press F18. You would then continue animating the character or continue with whatever needs to be done next. Suddenly 5 min. later your system alerts you that the render is finished and assembled into an uncompressed playable video file. Press Command+Tab to get to the finder click the preview and watch it in whatever you like - useful for that format. Delete or choose not to and go back to animating. Your system did all that rendering and all you were interrupted with was basically just a key-press. No slow-down, no nothing. If your assets are HUGE sometimes an initial render job will incur a slight amount of system lag as it needs to send all the assets associated with your project or selection to all of the nodes (machines) which will be involved in rendering it. With 1000BaseT that happens at about 100MB/s tho so usually it's nothing to worry about.
- You're faced with the task of cleaning up the motions on 100 different MoCaped scenes (clips, takes, whatever). You load the 1st, get it clean (about 20min.), and press F19 which sends the scene and all the assets to your render nodes. You load the second and start cleaning it. If the 1st is done rendering you can check it out as in example one or just continue cleaning all the scenes - as you wish. Your scenes are rendered at the same time while you did all that motion cleanup work - with no slowdown and no interruptions to your workflow. By the time you have finished with scene 100 likely at least 80 or so of the rendering jobs will have completed and you can start checking them out. Probably by the time you have checked out all of those 80 the other 20 will have finished up. Perfect. You did all your work in 3 days while you were awake and could catch any problems - and you never had to worry about your system hanging for a render nor sit and wait for one to complete before you could begin editing the next.
- You have to animate a character over and timed to a multi-layered video which you know is going to take hours to finish compiling. You load up AE or eyeon's Fusion do the edits (1hour because you had 2 GPUs and could preview the FX quickly as you edited), save off a proxy (small format quick render or whatever), and press F19 to send it to the render node(s). Quit that app and load up your CA tools whatever they are (I like Motion Builder!) and start matching your character walk cycles to the pace of the parallax scroll of the proxy video. By the time you're done with the CA the video is finished so you swap out the proxy for the final and press F19 again where the final composition begins rendering. You're now sitting there with a free untasked machine. If you have more editing work you can begin that and if not you can designate it as another node to help your project finish up faster.
- Imagine you're doing some character animation and you really wanna know how the textures are looking in the final rendered output because your deformations are too ugly in the real-time previewer (or maybe your app does't yet have a real-time previewer). You would select the portion of the timeline you're interested in and press F18. You would then continue animating the character or continue with whatever needs to be done next. Suddenly 5 min. later your system alerts you that the render is finished and assembled into an uncompressed playable video file. Press Command+Tab to get to the finder click the preview and watch it in whatever you like - useful for that format. Delete or choose not to and go back to animating. Your system did all that rendering and all you were interrupted with was basically just a key-press. No slow-down, no nothing. If your assets are HUGE sometimes an initial render job will incur a slight amount of system lag as it needs to send all the assets associated with your project or selection to all of the nodes (machines) which will be involved in rendering it. With 1000BaseT that happens at about 100MB/s tho so usually it's nothing to worry about.
These informations are mainly in consideration of likely configurations involving a single artist, a MacPro 6,1 and external render nodes of some unknown number and type. I think I used character animation (CA) in all of the examples but this kind of workflow applies to many or most modern forms of compute intense visual content creation I'm aware of CAD, CG (modeling, animation, FX, etc.), Video, the lot. The machines you select as compute nodes can totally be cheap WinTel or Linux boxes if you have the windows or linux version of the rendering engines you're using and your RM supports it. They should together (1 to 3 machines), comprise the same or more horsepower than your workstation box. Typically it's considerably more but if your workstation is 12 very fast cores then just one external machine of about the same horsepower may be all that's needed - often it is.
Eh, now I have to check spelling and grammar.
Last edited: