 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I know, this might have been asked quite often. But is there a listing
of POV versions running on multiprocessor platfoms?
I'm especially thinking of a dual celeron solution.
What OS do I need (NT,Linux,...)?
Any suggestions. Anyone already made experiences with this matter?
Karl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Karl Pelzer wrote:
>
> I know, this might have been asked quite often. But is there a listing
> of POV versions running on multiprocessor platfoms?
> I'm especially thinking of a dual celeron solution.
> What OS do I need (NT,Linux,...)?
> Any suggestions. Anyone already made experiences with this matter?
>
> Karl
You can find some information about running POV-Ray on multiple processors
here -
http://www.students.tut.fi/~warp/povVFAQ/languageVFAQ.html#multiprocessor
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> You can find some information about running POV-Ray on multiple processors
> here -
>
> http://www.students.tut.fi/~warp/povVFAQ/languageVFAQ.html#multiprocessor
>
> --
> Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Thanks Ken.
Again you saved me. This article is mostly about NT. It seems to be easy
to let two copies of POV render the same time (O.K. some restrictions).
But this might be useful for animations. One copy renders the even
frames and the other copy of POV renders the odd frames.
Anyone here made experiences with linux or with a multithreaded version
of POV?
Karl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 29 Feb 2000 08:19:31 +0100, Karl Pelzer
<Kar### [at] t-online de> wrote:
>I know, this might have been asked quite often. But is there a listing
>of POV versions running on multiprocessor platfoms?
>I'm especially thinking of a dual celeron solution.
>What OS do I need (NT,Linux,...)?
>Any suggestions. Anyone already made experiences with this matter?
>
>Karl
Being the lazy bum that I am, I'll just copy & paste from a reply I
send to the exact same question a couple of days ago. Here we go...
POV-Ray is indeed currently incapable of making use of SMPs.
There have been PVM ports of POV-Ray but I don't think a 3.1 one
is available let alone MegaPOV.
But, there is always a workaround :) If you can't take advantage of
multithreading, do so with multitasking. Run two instances of POV
and give each of them a separate portion of the image. Depending
on the image, one part may take significantly longer to render than
the other, imposing some difficulties. There are three basic ways to
split up the work:
1. Give the top half of the image to one instance of POV and the
bottom half -- to the other one.
2. The same, but use left/right halves instead.
3. Make one instance render the odd lines and the other instance --
the even lines. To do so, type this in the command line (the INI file
won't work because both files share a single povray.ini):
+uf +kfi0 +kff1 +ef0
and this in the command line of the second instance of POV:
+uf +kfi0 +kff1 +sf1
This will make two images, say output0.tga and output1.tga . The
first one will contain the even lines and the second one will contain
the odd lines. Open the images in a paint program and deinterlace
them.
I hope this works OK for you.
Peter Popov
pet### [at] usanet
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote:
<large snip>
>
> I hope this works OK for you.
>
<snip>
Thanks.
But honestly I'm not satisfied yet. Your solution goes into the same
direction as the ideas found with Ken's link.
Thanks again though!
Karl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 01 Mar 2000 22:09:46 +0100, Karl Pelzer wrote:
>But honestly I'm not satisfied yet.
THERE IS NO MULTITHREADED VERSION OF POV-RAY. PERIOD.
If you really must know why, go read one of the dozens of threads over in
povray.programming, or even in this very group, that cover that topic in
excruciating detail. The short version, though, is that coding properly
for multiple threads isn't as easy as Microsoft wants you to believe it is.
Besides, process switches are nearly as fast as thread switches, so what's
the problem with the solutions presented so far?
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1 Mar 2000 16:49:28 -0500, ron### [at] povrayorg (Ron Parker)
wrote:
>On Wed, 01 Mar 2000 22:09:46 +0100, Karl Pelzer wrote:
>
>>But honestly I'm not satisfied yet.
>
>THERE IS NO MULTITHREADED VERSION OF POV-RAY. PERIOD.
Gee, these keyboards are getting crappier every day. Ron's caps lock
key got stuck, and the darn thing isn't even three months old.
>If you really must know why, go read one of the dozens of threads over in
>povray.programming, or even in this very group, that cover that topic in
>excruciating detail. The short version, though, is that coding properly
>for multiple threads isn't as easy as Microsoft wants you to believe it is.
I believe the problem lies in basically having to redesign everything
from scratch, which the Team would not be likely to do solely for the
sake of multi-threadedness.
>Besides, process switches are nearly as fast as thread switches, so what's
>the problem with the solutions presented so far?
Memory consumption? I believe two threads can share the same memory
(for reading at least) but not so for two processes.
Peter Popov
pet### [at] usanet
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 02 Mar 2000 00:40:47 +0200, Peter Popov wrote:
>Gee, these keyboards are getting crappier every day. Ron's caps lock
>key got stuck, and the darn thing isn't even three months old.
Actually, that keyboard is more like two years old. But believe it
or not, I didn't use caps lock to type that line.
>I believe the problem lies in basically having to redesign everything
>from scratch, which the Team would not be likely to do solely for the
>sake of multi-threadedness.
Pretty much. Mainly, the problem lies in the overuse of global variables.
Since that's such a bad idea anyway, we're working on getting them under
control for "a future release" but it still might not be easy to do
multiple threads, due to the fact that there is no standardized way to
do multiple threads across all supported operating systems.
>Memory consumption? I believe two threads can share the same memory
>(for reading at least) but not so for two processes.
Two threads in the same process share all the same memory; this is
the main problem: they can trample on each other's global variables.
Having variables local to a specific thread is actually somewhat
complicated, at least in Windows.
Two processes should be able to share an executable image, but I
wouldn't be the least bit surprised to hear that this isn't implemented
on Windows-based operating systems, or at least those before W2K. I
know I was surprised to find out there's essentially no memory
protection on executable code (though I went through the motions and
VirtualProtect'd the pages I needed to modify anyway, just for the
sake of safety. They may one day actually make that code do something.)
Two processes can opt to share a read/write region of memory, at least
in Windows, by using memory-mapped files, but this is fraught with
danger in that some versions of Windows will map them to the same
address in different processes (9x, Millennium) and some will map
them to completely different addresses (NT 4 and 2000). This is a
problem if you elect to store any pointers in the shared memory, as
they'd only be valid in one process. The workaround is relatively
simple, but it's still a pain to have to think about such things.
Worse, if you do your development on 9x, you'd never know the problem
existed. Even Microsoft has fallen prey to this caveat in one of
their more specialized development tools. (Though to be fair, the
tool was for working with a feature that didn't exist on NT in a
publicly released version at the time. Unfortunately, I was using
an unreleased (i.e. not even beta) version, and I needed the tools.)
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On a dual processor NT machine (NT v4) you can run 2 copies of POVRay at the
same time with minimal interference. To minimize CPU thrashing I'd suggest
you use the set affinity command via the task manager processes tab.
--
Jim
Check out my web site http://www.kressworks.com/
Ron Parker <ron### [at] povrayorg> wrote in message
news:slr### [at] parkerrfwicom...
> On Thu, 02 Mar 2000 00:40:47 +0200, Peter Popov wrote:
> >Gee, these keyboards are getting crappier every day. Ron's caps lock
> >key got stuck, and the darn thing isn't even three months old.
>
> Actually, that keyboard is more like two years old. But believe it
> or not, I didn't use caps lock to type that line.
>
> >I believe the problem lies in basically having to redesign everything
> >from scratch, which the Team would not be likely to do solely for the
> >sake of multi-threadedness.
>
> Pretty much. Mainly, the problem lies in the overuse of global variables.
> Since that's such a bad idea anyway, we're working on getting them under
> control for "a future release" but it still might not be easy to do
> multiple threads, due to the fact that there is no standardized way to
> do multiple threads across all supported operating systems.
>
> >Memory consumption? I believe two threads can share the same memory
> >(for reading at least) but not so for two processes.
>
> Two threads in the same process share all the same memory; this is
> the main problem: they can trample on each other's global variables.
> Having variables local to a specific thread is actually somewhat
> complicated, at least in Windows.
>
> Two processes should be able to share an executable image, but I
> wouldn't be the least bit surprised to hear that this isn't implemented
> on Windows-based operating systems, or at least those before W2K. I
> know I was surprised to find out there's essentially no memory
> protection on executable code (though I went through the motions and
> VirtualProtect'd the pages I needed to modify anyway, just for the
> sake of safety. They may one day actually make that code do something.)
>
> Two processes can opt to share a read/write region of memory, at least
> in Windows, by using memory-mapped files, but this is fraught with
> danger in that some versions of Windows will map them to the same
> address in different processes (9x, Millennium) and some will map
> them to completely different addresses (NT 4 and 2000). This is a
> problem if you elect to store any pointers in the shared memory, as
> they'd only be valid in one process. The workaround is relatively
> simple, but it's still a pain to have to think about such things.
> Worse, if you do your development on 9x, you'd never know the problem
> existed. Even Microsoft has fallen prey to this caveat in one of
> their more specialized development tools. (Though to be fair, the
> tool was for working with a feature that didn't exist on NT in a
> publicly released version at the time. Unfortunately, I was using
> an unreleased (i.e. not even beta) version, and I needed the tools.)
>
> --
> These are my opinions. I do NOT speak for the POV-Team.
> The superpatch: http://www2.fwi.com/~parkerr/superpatch/
> My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On Thu, 02 Mar 2000 00:40:47 +0200, Peter Popov wrote:
> >Gee, these keyboards are getting crappier every day. Ron's caps lock
> >key got stuck, and the darn thing isn't even three months old.
>
> Actually, that keyboard is more like two years old. But believe it
> or not, I didn't use caps lock to type that line.
My keyboard is 16 years old and works as well today as when I first
purchased it. About once every 2 years I pop all the keys off and
throw them into the dishwaser but other than that it has seen no
other maintenance.
True story - date code on my keyboard is 1984 (the year the world
was really supposed to end)
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
