|
On the topic of OS problems, let me add one to the pile. So far, I've not been able to successfully get an 8K floating-point texture to convert to a pyramidal tiled .map file on Windows 32-bit. This actually seems like kind of a big deal, since the most common floating point images are environment maps, and those tend to be upwards of 6 or 12K. (For example, I have some 12K ones I'm supposed to be rendering right now).
4K images work fine. 8K 8-bit images also work fine.
I'd hop over to a 64-bit machine, but I guess the .map files won't work then, right? Will Linux work?
Why doesn't imf_copy write directly into the allocated file?
- Andy
On 1/3/08, Halfdan Ingvarsson <hingvars(at)softimage.com> wrote:
This is actually an OS problem and is the same as if you
had your page/swap file on the network. If you're using Linux with NFS and
caching enabled, it works quite ok since the network copy is transparently
copied to the local drive and mapped from there. The same cannot be said for
many other network drive implementations and especially not CIFS on
Windows.
- ½
With -p and -r the images will cache
even if they are located on a network drive. The problem is that MR will
constantly stream data from the map file as it's required for
rendering.
If you have a small subject within screen space that only
occupies a few buckets then this will not be an issue. But if the opposite is
true and you are rendering on a farm with lots of machines you will notice high
bandwidth demand on both the the file server and network.
With 100 nodes rendering full frame subjects with 5GB
of pyramidal / tiled textures the network becomes nearly
unusable and render times skyrocket. I've seen render times drop from 1+hours to
+/-10 minutes after re-locating all the textures locally onto the rendernode.
Votch-
|
