Well then, let's put the full discussion online.
My goof will mess up threading in the archive, but we'll
have to live with that...
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch.com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
---------- Forwarded message ----------
Date: Wed, 12 Jun 2002 15:25:31 -0700
From: Greg Ward <[email protected]>
To: Georg Mischler <[email protected]>
Subject: Re: [Radiance-dev] CVS, ANSI, C++
Hi schorsch,
Did you mean to make our discussion private, or did you want this on the
dev-list? I think others might be interested. I'll leave it to you to
copy there if you like...
From: Georg Mischler <[email protected]>
Date: Wed Jun 12, 2002 12:17:57 PM US/Pacific
To: Greg Ward <[email protected]>
Subject: Re: [Radiance-dev] CVS, ANSI, C++Greg Ward wrote:
Ewww. Can't we just say that if you want to do parallel rendering, you
need to install Unix?Hehe...
If you were asking me for my purely emotional response, then
you'd probably like my answer better than the one you'll actually
get. But I think we should face reality and accept that in the
near future, most people using Radiance will be sitting in front
of Windows boxes.They may well be sending long simulations to some linux cluster
in the basement, but their CAD system will probably run under
Windows, and having to switch back and forth more of a pain than
working with the "wrong" system all the time. Others will really
distribute stuff across their Windows network, as not everybody
may have the funding for establishing a parallel infrastructure
just for Radiance.
Having dealt just a little with Windows networks, I have to say that my
interest in supporting them is identically 0 over all time and space.
I'll leave it to you and others who think it worthwhile.
Maybe what we really need is some kind of switch that allows to
access different locking mechanisms depending on the situation. I
didn't check in detail, but I assume there are two functions, one
for fetching ambient data and one for storing it. Such a very
narrow interface lends itself relatively well to this approach.
It's not that I can easily pull a good file or server based
locking strategy out of my ears, but I think it would be worth a
little effort. We have had enough problems with NFS locking in
the past to appreciate the advantages that a working and truly
portable solution will bring.
Another reason to use a file lock manager rather than a server process
besides simplicity is that the lock manager is robust to individual
systems going down (or should be), whereas everything dies if your
server process dies. What about Chas' suggestion of offering Samba as a
substitute lock manager?
The Radiance sources are currently littered with hundreds of
instances of preprocessor symbols referencing more than a dozen
individual operating systems. This has almost worked yesterday,OK, that's a bit of an exaggeration.
I wasn't really exaggerating that much as far as the numbers go.
But of course I didn't check how many of those are really still
needed or could be eliminated in other ways. I'm not sure, for
example, how many of the MSDOS special cases are really still
required on modern Windows systems, and most of the UNIX
conditionals may fall away with the reverse argument. Those and
BSD seem to be responsible for more than half the OS specific code.I also didn't mean to insinuate that we need autoconv right now
and at any price. I think we'll know more about what we really
need after ANSIfication, as this may already eliminate quite a
few dependencies. If we then end up with so little that a
homebrew script gets us the same result, so much the better. The
differences between BSD and SYSV have been reduced to a large
degree by the ongoing implementation of the posix standards by
most vendors.
It's true that there are quite a few BSD and MSDOS conditionals in
there, and I would recommend these be replaced by isolating the
corresponding system calls with a system-independent interface as
necessary. I agree that a closer inspecition may determine that most of
these are no longer needed.
Prototypes and the elimination of global variables will make the
*internal* interfaces of Radiance a lot clearer and more obvious
than they are right now.I support this suggestion whole-heartedly. The global variables
currently in use in the renderers could be eliminated with a single
structure and a reference to it in the ray struct. In principle, the
bulk of the renderer could then be consolidated into a library, which
could be multi-threaded with a bit more work....I was actually thinking about a slightly finer granularity, but I
guess we'll see what makes sense when we get there. One of the
more interesting tasks might turn out to be the elimination of
exit() calls in code that is considered part of a library. I
don't think there's any part of Radiance that currently hesitates
to kill the whole process whenever something goes wrong, which
would be very surprising for a program using such a library.
Ah, yes. I agree -- although I usually call quit(), which then calls
exit() if it isn't overridden by the calling program. The only way to
avoid exit() is with a long jump, however, and this is not a generally
recommended practice, so it remains a problem. In general, it is safest
to call the renderer as a subprocess, which is how it is handled in
rholo.
I realize that most of you
haven't seen those sources yet, so you'll simply have to take my
word for it...I haven't seen this code, either, and from what you say, I'm not sure I
want to...Well, it's C++ code for Windows, apparently written by someone
who didn't bother to read the very decent documentation about the
system APIs coming with his compiler and IDE. I'm clearly no
expert in Windows programming (let alone in C++), but there's no
feeling of loneliness in that corner...I thought I had defined an interface for rview pretty well
in rt/driver.h. This is where I began when I wrote different drivers.
(There was a little-used NeWS driver at one time, as well as one for
Suntools -- anyone remember those systems?) As for ximage, this
program
was meant to be replaced in its entirety, not built upon. I assume
that's what they did for Windows, but I don't know.I couldn't say for sure. My primary fight was on the Windows
side, to turn the whole thing into a conforming and well behaved
program (with at least partial success). As far as I remember
right now, they directly hooked into the raytracing routines.One of the trickier problems is how to make the raytracer return
prematurely out of its recursive ambient calculations upon user
input. The lack of this possibility (and thus often significantly
delayed response) can also be quite annoying with ximage. On Windows
this becomes a serious issue, as you can't just kill a program
without the risk of losing a bunch of system resources.I'm not sure if I understand the concept behind driver.h
correctly yet. It looks like it wants to do all the event
handling itself, and reduces the "driver" to subordinate tasks
like providing mouse coordinates etc. Modern window management
systems rather lend itself to the opposite approach, where the
user interface runs the event loop and calls the simulation code
in the background (possible in a seperate thread). This makes it
possible to offer menus and other interaction possibilities,
which gives the user better control about what happens.
It sounds like you understand it fairly well.
The possibility to interrupt the simulation at any point in its
recursion is mandatory to garantee this responsiveness. As far
as I could figure out, this possibility isn't currently
implemented (and the implementation in winimage is not as clean
as it should be). I haven't checked if the holodeck stuff does
anything different in that regard.
Rholo also hangs on a long ambient calculation sometimes, as it has to
wait for at least one ray value to return before it can respond to the
driver process. Since it is a separate process, however, the driver is
free to display menus and move around the scene, even if it can't get
the rays it wants from the holodeck server. This could be fixed with a
better call to select() that included the driver process, but I never
bothered with it because it was more complicated and the most I was
waiting was 10 seconds or so for the calculation to catch up. (I tend
to be more patient with my own software.)
If the ambient calculation is the only barrier to responsiveness in
rview, it wouldn't be too difficult to query the value of some variable
set asynchronously by the caller and make a hasty retreat. However,
we'd have to work long and hard before we got the renderer code into
thread-safe shape. Another option is to use the Unix signal facility to
send an interrupt to the rendering process, causing premature
termination of any ambient calculation in progress. This wouldn't
require much coding effort at all.
Another, possibly better solution would be to have the renderer call a
global "checkInput()" routine every so many rays, which is the way rview
is _supposed_ to work but doesn't, simply because the call to
checkInput() is handled at too high a level. If we moved this into the
low-level raytrace() routine, I think we'd have responsiveness licked
without having to change to a background rendering process. I might
even give this a go to try it out.
The programming
interface for image display is the Radiance picture format!Hmmm... and reinvent all the tonemapping stuff?
Not necessarily. The tone-mapping stuff is all incorporated into a nice
set of library routines, which are even written in ANSI-C! (They were
the last thing I wrote before leaving LBNL.) It's not too difficult to
use them from a new program. I use them a lot in Photophile, the HDR
image browser I'm developing.
-Greg