 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How should a multithreaded povray work?
I guess the user specifies how many threads he/she wants, then what?
Should the threads render lines, or should it devide to picture in to
'imageheight devided by threads' blocks and render them?
/j
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 25 May 1999 14:30:43 +0200 (CDT), Jan Danielsson wrote:
>How should a multithreaded povray work?
>
>I guess the user specifies how many threads he/she wants, then what?
>
>Should the threads render lines, or should it devide to picture in to
>'imageheight devided by threads' blocks and render them?
Ignoring for a moment how hard any multithreaded design will be to
implement in practice, I think a thread should always just do whichever
scanline is next when it gets ready to go. For one thing, this will
help minimize the amount of rendered information that is hanging
around in memory without having been written to the file. For another,
it will do a more effective job of balancing the load between the
threads. Skyvase, for example, spends most of its time in the bottom
half of the image.
You could, of course, run a low-resolution test render first and
assign blocks of the image based on the histogram results.
Okay, now let's stop ignoring how hard a multithreaded design is. Can
I ask all of you "we need SMP so we need threads" people what's wrong
with plain ol' fork? Yeah, Winblows doesn't support fork natively,
but that seems like something Mickeysoft should fix. Or just install
a real OS on your fancy SMP machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <374aa7a5.0@news.povray.org> , par### [at] fwi com (Ron Parker)
wrote:
> Okay, now let's stop ignoring how hard a multithreaded design is. Can
> I ask all of you "we need SMP so we need threads" people what's wrong
> with plain ol' fork? Yeah, Winblows doesn't support fork natively,
> but that seems like something Mickeysoft should fix. Or just install
> a real OS on your fancy SMP machine.
NT is POSIX compliant, and maybe Windows 2001 will be as well :-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 25 May 1999 18:03:03 +0200, Thorsten Froehlich wrote:
>In article <374aa7a5.0@news.povray.org> , par### [at] fwicom (Ron Parker)
>wrote:
>
>> Okay, now let's stop ignoring how hard a multithreaded design is. Can
>> I ask all of you "we need SMP so we need threads" people what's wrong
>> with plain ol' fork? Yeah, Winblows doesn't support fork natively,
>> but that seems like something Mickeysoft should fix. Or just install
>> a real OS on your fancy SMP machine.
>
>NT is POSIX compliant, and maybe Windows 2001 will be as well :-)
I'm running Win2K (AKA NT5) on this machine right now, as it happens,
writing device drivers and other hacks. So I'm somewhat familiar with
it...
Yes, NT has a POSIX compliant subsystem. Presumably, one could build
a version of POV that runs in the POSIX subsystem. It wouldn't have
the Windows GUI, though, because the POSIX and Win32 subsystems are
completely independent from each other. And of course it wouldn't
run on Win9x, which still seems pretty popular for some reason.
If one wanted an SMP POV on any Windows machine, though, one could
build the theoretical Unix SMP version (one using fork, of course)
with the Cygwin toolkit. It does have a usable implementation of
fork. With a little extra work you could even tie such an
implementation to the existing GUI (though you couldn't distribute
the resulting product.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> And of course it wouldn't
> run on Win9x, which still seems pretty popular for some reason.
hehe, in my case, I'm running win 95 from the reason of... Size. the installed
size of 95 compared to either NT workstation(not an alternative due to driver
problems) and 98 is big. I hope win2k will address this a bit...
don't bother responding to this, since the discussion would probably end up in
the OS wars. and I'm too OT as it is.
--
//Spider -- [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
And the meek'll inherit what they damn well please
Get ahead, go figure, go ahead and pull the trigger
Everything under the gun
--"Sisters Of Mercy" -- "Under The Gun"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
[...]
>Okay, now let's stop ignoring how hard a multithreaded design is.
Are you talking about 'multithreading in general', or 'rewriting povray'?
Since I have written many multithreaded applications of various types I do
not have any problems controlling threads. However; if you're talking about
povray... You may be right. But I have some ideas. I don't think it should be
too hard.
>Can I ask all of you "we need SMP so we need threads" people what's wrong
>with plain ol' fork?
And I ask; what's wrong with threads? (Now ask me what's wrong with forks; We
could do this until the sun explodes :-)
I'm choosing threads because:
1) They are excellently implemented in OS/2.
2) They are native to OS/2.
3) If I remember correctly, the emx-package implements fork. However, I am
not a big fan of emx, and I have a compiler I like which only handles
threads... so.....
>Yeah, Winblows doesn't support fork natively,
>but that seems like something Mickeysoft should fix. Or just install
>a real OS on your fancy SMP machine.
Windows? Who's talking about Windows? I'm an OS/2 developer.
I would like to make a portable povray which would be SMP-aware. However; I
have lots of experince with threads, but _very_ little with forks..
/j
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Certain types of image processing routines are almost trivial to break into
SMP threads under NT, especially if you can get all the performance from
just partitioning the image. It can be done using only a thread control
structure, ResumeThread, SuspendThread, and Sleep functions and wrappers
around the needed image processing routines. Alternating scanlines is
better because it minimizes paging at the various cache levels.
This doesn't give a very general solution but works great under NT and the
code can run fine in Win98. It only gets messy when the multiple threads
have to access the same data, that is, if the changes made by one thread
depend on the changes made by the other thread. Then the synchronization to
avoid exceptions destroys the performance or exception handling itself
becomes too complicated to manage. If the core routines can be individually
treated, that's where all the performance gain is anyway.
--
Tim Hutcheson
w4l### [at] bellsouthnet
Ron Parker <par### [at] fwicom> wrote in message
news:374aa7a5.0@news.povray.org...
> On Tue, 25 May 1999 14:30:43 +0200 (CDT), Jan Danielsson wrote:
> >How should a multithreaded povray work?
> >
> >I guess the user specifies how many threads he/she wants, then what?
> >
> >Should the threads render lines, or should it devide to picture in to
> >'imageheight devided by threads' blocks and render them?
>
> Ignoring for a moment how hard any multithreaded design will be to
> implement in practice, I think a thread should always just do whichever
> scanline is next when it gets ready to go. For one thing, this will
> help minimize the amount of rendered information that is hanging
> around in memory without having been written to the file. For another,
> it will do a more effective job of balancing the load between the
> threads. Skyvase, for example, spends most of its time in the bottom
> half of the image.
>
> You could, of course, run a low-resolution test render first and
> assign blocks of the image based on the histogram results.
>
> Okay, now let's stop ignoring how hard a multithreaded design is. Can
> I ask all of you "we need SMP so we need threads" people what's wrong
> with plain ol' fork? Yeah, Winblows doesn't support fork natively,
> but that seems like something Mickeysoft should fix. Or just install
> a real OS on your fancy SMP machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 25 May 1999 20:37:49 +0200 (CDT), Jan Danielsson wrote:
>[...]
>>Okay, now let's stop ignoring how hard a multithreaded design is.
>
>Are you talking about 'multithreading in general', or 'rewriting povray'?
I'm talking about rewriting povray.
>>Can I ask all of you "we need SMP so we need threads" people what's wrong
>>with plain ol' fork?
>
>And I ask; what's wrong with threads? (Now ask me what's wrong with forks; We
>could do this until the sun explodes :-)
"What's wrong with forks?" I asked you first. :)
No, really, the main problem with threads is that POV has a lot of global
variables that are changed during a render. If you can locate all of them
and make them threadsafe, then you'll be fine. I did some of this when I
wrote my motion-blur hack, but there are a lot more that didn't affect me
but would affect an attempt at multithreading.
I have nothing against threads in general; I love the flexibility they give
me (along with asynchronous I/O.) I just think a forking model would be
easier to implement given what we have to work with, because it copies all
of the variables into another process space for the other processor.
Oh, and sorry if I appeared to imply that you were a Windows programmer. I
was just trying to defuse the most likely response to my question, not
necessarily from you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25 May 1999 12:53:38 -0500, Ron Parker wrote:
>And of course it wouldn't
>run on Win9x, which still seems pretty popular for some reason.
Ron, you're an idiot. Win9x doesn't support SMP anyway.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 25 May 1999 14:48:58 -0500, Tim Hutcheson wrote:
>Certain types of image processing routines are almost trivial to break into
>SMP threads under NT, especially if you can get all the performance from
>just partitioning the image. It can be done using only a thread control
>structure, ResumeThread, SuspendThread, and Sleep functions and wrappers
>around the needed image processing routines. Alternating scanlines is
>better because it minimizes paging at the various cache levels.
>
>This doesn't give a very general solution but works great under NT and the
>code can run fine in Win98. It only gets messy when the multiple threads
>have to access the same data, that is, if the changes made by one thread
>depend on the changes made by the other thread. Then the synchronization to
>avoid exceptions destroys the performance or exception handling itself
>becomes too complicated to manage. If the core routines can be individually
>treated, that's where all the performance gain is anyway.
Raytracing in general is very parallelizable. It's just POV in specific
that's a tough nut to crack, because the design did not anticipate threading.
Fix all of the global variables and other weirdness (like variable reuse)
and then it would be a fairly easy task.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
