 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
> But I thought POV doesn't support dual CPUs?
>
Running POV-Ray on a multiprocessor system would be the same as running
on several independent machines - you would start several render
processes for using all available processors.
--
Christoph Hormann
http://www.tu-bs.de/~y0013390/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
>
> That's true if I follow the philosophy of running seperate instances of pov on
> seperate machines, but surely it would be possible to modify POV to run in some
> multi-threaded configuration (say with each ray on a seperate thread) which
> could then be farmed out to the different processors?
>
> Has anyone attempted such a thing? Is there software/OS's available that will
> let a network of PCs emulate a multi-processor system? I confess I've never
> programmed anything like that and I've never looked at POV's source, so I'd be
> very curious to know how difficult it would be to do something like that.
This has been discussed a lot already - first of all a use of
multithreading inside POV-Ray will not have any significant advantage
for distributed renders on a cluster of several machines - even if you
use a system emulating a single multiprocessor machine the communication
overhead would require a completely different design than on a true SMP
machine (and you would have the same trouble with techniques that are
difficult to parallelize as with an external implementation).
But much more important is that there is no way to implement
multithreading in a portable manner - not even for the three 'official'
platforms. So if you want to attempt implementing such a system (which
would be pretty hard on the current POV-Ray source anyway) you would
have to implement several platform specific variants.
--
Christoph Hormann
http://www.tu-bs.de/~y0013390/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Running POV-Ray on a multiprocessor system would be the same as running
> on several independent machines - you would start several render
> processes for using all available processors.
And hope your not using radioasity....
--
Rick
Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037
PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> But I thought POV doesn't support dual CPUs?
It doesn't, but you will be able to render 2 halfs of an image (depending on
image) or 2 images, or render on one cpu and still be able to use the PC as
normal.
--
Rick
Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037
PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, I get the point now. If I'm going for a multi-PC system it's actually
cheaper to have half as many PCs all with dual processors. That's some good
advice and I'm currently checking the online shops to figure out where the sweet
spot is between speed and money :)
--
Tek
www.evilsuperbrain.com
"Rick [Kitty5]" <ric### [at] kitty5 com> wrote in message
news:4066a47c@news.povray.org...
> > But I thought POV doesn't support dual CPUs?
>
> It doesn't, but you will be able to render 2 halfs of an image (depending on
> image) or 2 images, or render on one cpu and still be able to use the PC as
> normal.
>
> --
> Rick
>
> Kitty5 NewMedia http://Kitty5.com
> POV-Ray News & Resources http://Povray.co.uk
> TEL : (+44) 0845 1083740 - ICQ : 15776037
>
> PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
laurent.artaud[AT]free.fr <"laurent.artaud[AT]free.fr"> wrote:
> > This is true for the *CPU*. However, it's not the CPU which handles
> > the floating point code, but the FPU.
> > The FPU is completely separate from the CPU. The FPU has eight 80-bit
> Well, you seems to mix CPU and ALU:
No, I'm not. We were discussing whether the FPU can handle chunks of
data larger than 32 bits. You claimed that the *FPU* of Athlon XP can't
because it's internally 32-bit. I casted doubt about this. As an argument
you said that the CPU and the ALU of Athlon XP is 32 bits architecture.
I commented that the FPU has nothing to do with those.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Among other things, "laurent.artaud[AT]free.fr" wrote:
>>>Even if the Athlon-XP's FPU is able to use 64 bits double precision
>>>floats
>>
>> What do you mean "if"?
>
> Ah?
> Sorry, I'm not a native English speaker, so I may have used the wrong
> saying.
> I was NOT trying to say that I do not think the FPU able to work on 64
> bits double precision floats. In fact, I KNOW that it can work on 80
> bits long double floats, as any x87 compatible FPU must.
Maybe "Even though the Athlon-XP's FPU ..." would be more appropriate? :)
--
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> No, I'm not. We were discussing whether the FPU can handle chunks of
> data larger than 32 bits. You claimed that the *FPU* of Athlon XP can't
> because it's internally 32-bit. I casted doubt about this. As an argument
Well, re-read my posts: I _NEVER_ SAID THAT THE _FPU_ WAS 32 BITS!
--
Laurent ARTAUD (lau### [at] freefr)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>>Even if the Athlon-XP's FPU is able to use 64 bits double precision
>>>>floats
>
>
> Maybe "Even though the Athlon-XP's FPU ..." would be more appropriate? :)
>
Thanks.
Regards,
--
Laurent ARTAUD (lau### [at] freefr)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Among other things, Tek wrote:
> So, what I want to know is: What hardware & OS configuration will give the
> fastest povray rendering performance? And how much work would it take to
> get it all running?
If you're going to use this system only for rendering, I'd probably go for a
linux (or similar) machine, where you can disable all kinds of processes
and servers not needed. Besides, you don't really need an expensive
3D-videocard, or a 5.1-soundcard, or a flat monitor... just some processor,
ram and HD, and a netcard. You can control this machine through the net and
use some KVM switch when needed.
Now, I guess you would need a good compiler too... So, I'd narrow the
question to: what combination of processor and compiler would give the best
performance for under linux?
But I'm no expert... :)
--
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
