Hi Greg,
are you refering to memory sharing between forked subprocesses?
I see only one sole function (OOC_SortRecurse()) using fork().
My first choice would probably be to use threads in place of subprocesses.
Another alternative would be to make the memory sharing explicit.
But then, so far I only see the forked subprocesses actually sharing file
handles, which Windows can do as well. Threds might still be a good idea in
this case, though.
Of course, I may still be missing some other trickery, but on the surface
this looks like a manageable porting task.
@Roland will have to supply some test cases though, so we can verify that
the ported version still does what it's supposed to do. Let's hope he
returns soon from his ski resort (or tropical island) where he seems to be
hanging out at the moment...
-schorsch
···
Am 2018-01-09 02:21, schrieb Gregory J. Ward:
Hi Schorsch,
Many thanks for working on this.
My memory is that a Windows version of the out-of-core photon-mapping
code is on Roland's back-burner, and likely to remain there for the
indefinite future. The code relies heavily on memory sharing and the
Unix fork() function in its current configuration, and changing that
is not an insignificant amount of work.Cheers,
-GregFrom: Georg Mischler <[email protected]>
Date: January 8, 2018 4:15:16 PM PSTA closer check revealed:
Cmake simply ignores the ooc stuff alltogether
The Rmakefile builds object files from all the oocxxx.c files,
but not for pmapooc.c.And finally in the sources, I found why:
pmapdata.c #includes pmapooc.c (or alternatively pmapkdt.c), depending
on -DPMAP_OOC.
No provisions to actually set the latter, though.but that's an easy enough excercise...
After a bit of digging about which files actually need that define,
The SCons build now supports OOC for Pmap, with a configuration option
aptly named - PMAP_OOC.
It is enabled by default on unixoid systems and unavailable on Windows.The latter is because the code actively refuses to build on Windows.
@Roland
Are you still hibernating?
Are there technically difficult reasons for this, or did you just
not get around to fixing and testing it on Windows yet?
At a quick glance through the code I didn't notice any particularly
platform dependent stuff, but of course I may have missed something.-schorsch
Am 2018-01-08 16:03, schrieb Guglielmetti, Robert:
Hi Georg! Long time. We are about done with a re-write of the Cmake
build system as well, which allows us to do automated build/test/CI on
our GitHub mirror of the Radiance CVS repo. Exciting times!
There was some shuffling around of the pmap includes. It’s been
building for us on Windows since late summer 2017, I’ll have to look
and see what we are doing, unless Roland/Greg know offhand.
- Rob
On 1/8/18, 6:44 AM, "Georg Mischler" <[email protected]> wrote:
Hello everybody,
As it is starting to turn into a new year's tradition, I've just
updated the SCons build system once again.
Good news 1:
With Scons 3.1 (probably since 3.0), despite what the documentation
says, it works very nicely with Python 3.x (3.6 in my case).
After some adaptions from my side, this means that all the Python
code in the Radiance distribution is now compatible with both
Python 2.7 and 3.x.
Good news 2:
Microsoft has fixed their Universal CRT (didn't check in which version).
This means that the line-end-eating bug in pipes is gone, and we can
reliably build Radiance with the current Visual Studio tools again.
I have now completely switched to VS 2017 myself.
Open Issue:
There's a buch of code relating to "out of core octree" building
for Pmap. Most of this compiles fine, except for pmapooc.c, which
is missing some header file includes. Unfortunately, that seems to
be the central cornerstone binding all the others together...
@Roland:
Can you share some insight whether this is supposed to be working,
or still a work in progress that I should ignore for the moment?
Or alternatively, am I doing anything wrong for making it work?
Cheers
-schorsch