Jump to content

RW on Dual quad-core MacPro


Recommended Posts

Hey I have a birthday coming up... If you were to give me one as a present I would more than happy to send you some test results. Oh, BTW, I'd also like it upgraded to 4g RAM and a 23" Display. LOL.

In all seriousness though, I bought a 2.33g MacBook Pro a few months back, and hooked up to my 'old' 20" display it's pretty powerful and certainly more than adequate for all but the biggest, bloatiet, NURBS-full, QT Anim. exports (which I bet would *still* take all night even with this latest quad-core machine). So I've been sort of waiting on the sidelines. Eventually I'll probably go for it, but not quite yet. I've got a feeling that even more power may be just around the corner... I hate jumping in just before the tub gets truly warm enough ;-)

Kevin: ROFL !!!

Edited by CipesDesign
Link to comment

Mclaugh & Others, See this link for some test results: 8-CORE BENCHMARK TESTS The most relevant statement is: Even though dual-core processors have been around for a while now, you'd still be hard-pressed to find many mainstream applications that can efficiently take advantage of both processing cores at the same time (typically referred to as a multithreaded-application). Double that number to four processing cores, and the list of supported multithreaded applications gets even shorter. Double it again to eight -- you get the idea. So, in reality I suspect that for VW users, having more cores will only be of real benefit a) when running other app's side-by-side, or b) when NNA adds multi-threading ability to the app... I'd love to hear other opinions... And I'd love to know if/when NNA plan to do so...

Link to comment

Peter,

What possible benefist do you see in VW going multithreaded?

I don't give a flying fadoo whether or not mainstream apps (office suites, browsers, mail, etc.) are multithreaded. It's not like I'm typing/clicking/designing faster than my computers can accept my input as it is, so I'm not convinced that multithreading VW (as opposed to RW) is going to provide any real benefit UNLESS it's done in a way that allows individual cores to be linked or segregated on demand so a user to work on one file in VW while another file is rendering. (Yes, I realize the technical challenges to doing that could be daunting, and that that really should be a feature of the OS rather than the program, which is why I'm not holding my breath waiting for it.)

For me, the only issue of relevance at this point is rendering speed, whether in RW or another rendering app.

RW has been multithreaded since at least 11.5. When I do a render in a RW format on my G5 Dual, I get two render lines simultaneously on-screen, and several posters who have Quad-cores report they have four render lines. So unless the Lightwave engine is limited to four concurrent threads or Nemetschek has limited the number of concurrent threads in RW, I expect there will be a significant reduction in rendering times on the octo-core MacPro compared rendering times on quad-cores.

If RW can finish rendering a FQRW animated walkthrough in 24-36 hrs on an octo-core that's currently taking 100+ hours on my G5 Dual, that's all the justification I need; if it can cut radiosity rendering times by 50%, that's even more of a bonus.

Link to comment

fsung, perhaps I should rephrase - slightly. Although multithreading works to speed up RW's renderings, what about Hidden Line, Artistic, Open GL, and all other types of rendering that we have, or might have. What about multithread support for the 'updating' (actually rendering, no?) of complex section VP's, especially those which cut through Site Models or which contain NURBS objects. What about multithread support for the updating of VP's in general. Remember those multi-VP elevations I posted on in a recent thread? Those can sometime take *minutes* to update, all while I sit and examine my navel lint ;-D. All of these processes, and I'll bet more, could benefit greatly from being multithreaded an would speed up *my* workflow enormously. What about yours? And BTW, I completely agree that speeding up animation exports could be atractive to make the new 8-cores 'worth the price of admission', however that's only *part* of what I do...

Link to comment

You guys all live up there in the rarified air ... creating rendered images that take days , weeks, and months to finish ...

lucky you have some sex appeal.

For us lowlanders ... the thought of waiting even 1 hour is queer .

When VW becomes fully multi-threaded ... only then my friends... does Mohammed come down off that mountain.

Link to comment

Interesting list, Peter, and, yes, it would be nice if those operations could be speeded up; however, most of the tasks you list are handled by the GPU rather than the CPU, so until Apple supports bridging graphics cards, multithreading VW won't make a difference. (Yes, Dual G5s and Intel Mac support multiple graphics cards, but the GPUs can't be linked for multithreading, and AFAIK, Leopard will not include the ability to bridge graphics cards.)

Link to comment

I understand that in Leopard apple are moving to multi-threading OpenGL seeing as all of the interface relies on OpenGL.

If true the system will be aware of when it can move some OpenGL processing from the video card and over to one of those spare 8 cores.

I guess we will have to wait and see.

Link to comment

Actually, OpenGL has supported multi-threaded since 10.4.7, but only ONLY on the Mac Pro platform (so not on Intel iMacs, Minis, MacBooks, or PowerPCs), and ONLY in applications that are written to support the feature. In other words, it's an opt-in technology rather than a core OS technology that developers specifically have to chose to support. I don't have a Mac Pro, so I don't know whether or not VW already supports OpenGL multithreading, but my guess is it doesn't.

I haven't seen any reports or suggestions that Leopard will bring multithreaded OpenGL to Powermacs or non-MacPro Intel Macs, so I suspect that it will be an opt-in technology until well into the 10.5.x development cycle.

IIRC, at this point, radiosity is still only single-processor aware. Given a choice in the matter, I'd vote for multithreading radiosity before OpenGL rather than vice versa.

Link to comment

From what I see on activity monitor VW is not multithreading on openGL at the moment. The advantage to attacking that before the radiosity is that it would affect the whole speed of response of the program whilst moving around the wireframe drawing; this can become very slow and clunky currently, makes a pro feel like a plus - there are quite a few other threads on this subject from the past as well as islandmon and Peter's comments above.

However if mclaugh is right then we're all barking up the wrong tree anyway, aren't we?

Link to comment
From what I see on activity monitor VW is not multithreading on openGL at the moment. The advantage to attacking that before the radiosity is that it would affect the whole speed of response of the program whilst moving around the wireframe drawing; this can become very slow and clunky currently, makes a pro feel like a plus - there are quite a few other threads on this subject from the past as well as islandmon and Peter's comments above.

Sorry, but I agree with pgym.

While it is true that multithreading OpenGL will speed up program responsiveness on Mac Pros, it provides ZERO benefit to those who aren't using Mac Pros. Multithreaded radiosity, OTOH, benefits ANYONE who does radiosity on a dual processor or dual core system, regardless of whether it's Mac or Windows.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...