 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
>>
>> may be http://www.mosix.org/ ?
>
> Ooh, that looks interesting!
> Now all I need is a parallel processing version of POV and lots of PCs...
>
You can also look at PovPVM, maybe after have read this paper:
http://www.oreilly.com/catalog/clusterlinux/chapter/ch09.html
--
http://tth.vaboofer.com/Cette/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
>
> In fact, what I'd want would be a way to execute pov remotely on a linux machine
> by invoking it from my windows machine.
>
Just use Putty...
http://www.chiark.greenend.org.uk/~sgtatham/putty/
--
http://tth.vaboofer.com/Cette/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
> 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 :)
I could never go back to single CPU boxen :)
Just be aware that dual CPU setups can be quite picky when it comes to RAM,
so a load of your local vendors "cheap and chearfull" probably wont cut it
(check for compatability with the vendor before you buy, and make sure the
vendor will swap any RAM that fails to perform as expected, sometimes
simply switching brands can make a world of difference)
That said, I have only built one dually that had memory related problems
(random freezes, failing specific memtest86 tests) and turning off spread
spectrum in the bios cured it.
www.2cpu.com has an excellent forum.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
>
> "John VanSickle" <evi### [at] hotmail com> wrote in message
> news:4065ABF4.A37B0EC5@hotmail.com...
> > Tek wrote:
> > >
> > > So, what do you think? What sort of system should I build?
> >
> > You aren't going to get much better performance out of a single box;
> > multi-machine rendering is your solution.
>
> Hmm... interesting. It's good to hear from someone who actually uses a
> multi-machine system in a practical way! :)
>
> Certainly that sounds like a reasonably good solution to distributing
> animations across machines, but it raises a few questions:
>
> You say you have ini files to render 12 frames and you give more ini
> files to the faster machine, why not simply have one ini file for each
> machine which renders more frames on the faster machine than the slow
> one?
The current version of POV-Ray has a bug which causes some memory not
to be freed until the whole batch of frames is finished for a given
INI. So I limit things to 12 frames at a time (that's half a second
of animation, and all of my shots are multiples of half a second in
length).
> Have you come up with a way of handling scenes that use persistent
> variables (e.g. particle systems, physics, etc)?
Everything is calculated in the scene file from scratch for each frame.
> Have you tried a similar approach on still images?
When I do a still frame I generally have the faster machine render the
whole thing.
> Have you tried partially automating the management side of things? So
> an automated process could watch the frames coming in and farm the
> next batch out to whichever machine is currently further ahead.
The present method suits my needs.
> Still, it sounds like it may be less effort than I feared. Plus it
> would be very easy to write a program/script that could automatically
> generate those ini files.
Probably. I have about 200 of the ini files, and the only edit I need
to do is to update the source file. There's probably a way to put
that in the command line and skip the editing.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr"> wrote:
>
> Well, you should prefer "http://openmosix.sourceforge.net/"...
>
I have tested pvmpovray35 with openMosix, and it works a treat. Overhead
might be higher than say a dedicated PVM or MPI cluster but admin is much
simpler, IMHO.
Matthew Grove
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr"> wrote in message
news:40667a7e$1@news.povray.org...
> > 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:
> ALU stands for Arithmetic and Logic Unit. It is the part of the chip
> that compute on integers.
> The ALU and the FPU are separate, but are both inside the CPU.
However, when people refer to a CPU being 32bit, they usually are referring
to the ALU. The FPU has been 80 bit since at least the '80s.
> Well, to know this for sure, we'll have to find an assembler programmer
> which will be able to say if it is possible to load one of the FPU
> register directly from the cache in the same number of cycles the other
> registers do.
Well, it's been a few years, but I used to do quite a bit of graphics
programming in assembly. Did you know that, for instance, the FPU registers
load so fast that games used them to load bitmaps from regular memory to
video memory? It worked about 30% faster than a standard transfer. In
fact, this was the reason MMX used the FPU registers, and so you can't use
FPU and MMX at the same time.
> If so, then the speed difference between the Athlon-XP and the Athlon-64
> is partly (they can also have improved the FPU unit...) because the last
But they didn't. Internally, the FPU is identical between the AthlonXP, 64
and FX models.
--
...Chambers
http://www.geocities.com/bdchambers79
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40686cfe$1@news.povray.org> , "Chambers"
<bdc### [at] yahoocom> wrote:
> Well, it's been a few years, but I used to do quite a bit of graphics
> programming in assembly. Did you know that, for instance, the FPU registers
> load so fast that games used them to load bitmaps from regular memory to
> video memory? It worked about 30% faster than a standard transfer. In
> fact, this was the reason MMX used the FPU registers, and so you can't use
> FPU and MMX at the same time.
That is nonsense. They are faster for copies because you execute fewer
instructions per copy and on a 64 bit bus (since the Pentium, and even with
burst transfers on a 486 bus) the maximum bandwidth is used. Further, MMX
used FPU registers simply as a kludge so operating systems and many ancient
programs would not have to be modified to save additional data when
switching contexts. This is why certain versions of Windows needed patching
later on when SSE with its additional registers was added.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:40687543$1@news.povray.org...
> In article <40686cfe$1@news.povray.org> , "Chambers"
> <bdc### [at] yahoocom> wrote:
>
> > Well, it's been a few years, but I used to do quite a bit of graphics
> > programming in assembly. Did you know that, for instance, the FPU
registers
> > load so fast that games used them to load bitmaps from regular memory to
> > video memory? It worked about 30% faster than a standard transfer. In
> > fact, this was the reason MMX used the FPU registers, and so you can't
use
> > FPU and MMX at the same time.
>
> That is nonsense. They are faster for copies because you execute fewer
> instructions per copy and on a 64 bit bus (since the Pentium, and even
with
> burst transfers on a 486 bus) the maximum bandwidth is used. Further, MMX
> used FPU registers simply as a kludge so operating systems and many
ancient
> programs would not have to be modified to save additional data when
> switching contexts. This is why certain versions of Windows needed
patching
> later on when SSE with its additional registers was added.
>
> Thorsten
Well, I only surmised. Thank you for correcting me.
It's *still* a neat hack for 486 systems to up the transfer rate :)
--
...Chambers
http://www.geocities.com/bdchambers79
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <bdc### [at] yahoocom> wrote:
> Did you know that, for instance, the FPU registers
> load so fast that games used them to load bitmaps from regular memory to
> video memory? It worked about 30% faster than a standard transfer.
This was a very widespread urban legend back in the time when Quake
was new.
The fact is that it's not true. You can test with pentiums of that time
that copying data from RAM to the video memory is not any faster using
the FPU (yes, I *did* test it explicitly instead of just trusting
internet rumors).
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:40693a11@news.povray.org...
> Chambers <bdc### [at] yahoocom> wrote:
> > Did you know that, for instance, the FPU registers
> > load so fast that games used them to load bitmaps from regular memory to
> > video memory? It worked about 30% faster than a standard transfer.
>
> This was a very widespread urban legend back in the time when Quake
> was new.
> The fact is that it's not true. You can test with pentiums of that time
> that copying data from RAM to the video memory is not any faster using
> the FPU (yes, I *did* test it explicitly instead of just trusting
> internet rumors).
Well, I never had a straight pentium to test with, but I verified myself
that it was true of the 486 line (after that I went to a K6 with MMX).
--
...Chambers
http://www.geocities.com/bdchambers79
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
