Thanks Ivan, That's some really good info. I'll check it out. Ryan
On Tue, Sep 6, 2011 at 2:06 AM, Ivan Busquets <[email protected]>wrote: > Hi, > > Found the script I sent a while back as an example of picking layers in > merges using up more resources. > Just tried it in 6.3, and I still get similar results. > > Script attached for reference. Try viewing/rendering each of the two groups > while keeping an eye on memory usage of your Nuke process. > > Cheers, > Ivan > > > > On Mon, Sep 5, 2011 at 11:42 AM, Ivan Busquets <[email protected]>wrote: > >> Another thing is it sounds like you are shuffling out the channels to the >>> rgb before you merge them. This also does quite a hit in speed. It is far >>> faster to merge and pick the channels you need rather then shuffling them >>> out first. >>> >> >> That's interesting. My experience has usually been quite the opposite. I >> find the same operations done in Merges after shuffling to rgb are faster, >> and definitely use less resources, than picking the relevant layers inside >> the Merge nodes. >> >> Back in v5, I sent a script to support as an example of this behavior, >> more specifically how using layers within the Merge nodes caused memory >> usage to go through the roof (and not respect the memory limit in the >> preferences). At the time, this was logged as a memory leak bug. I don't >> think this was ever resolved, but to be fair this is probably less of an >> issue nowadays with higher-specced workstations. >> >> Hearing that you find it faster to pick layers in a merge node than >> shuffling & merging makes me very curious, though. I wonder if, given enough >> memory (so it's not depleted by the mentioned leak/overhead), some scripts >> may indeed run faster that way. Do you have any examples? >> >> And going back to the original topic, my experience with multi-channel exr >> files is: >> >> - Separate exr sequences for each aov/layer is faster than a single >> multi-channel exr, yes. As you mentioned, exr stores additional >> channels/layers in an interleaved fashion, so the reader has to step through >> all of them before going to the next scanline, even if you're not using them >> all. Even if you read each layer separately and copy them all into layers in >> your script (so you get the equivalent of a multi-channel exr), this is >> still faster than using a multi-channel exr file. >> >> - When merging different layers coming from the same stream, I find >> performance to be better when shuffling layers to rgba and keeping merges to >> operate on rgba. (although this is the opposite of what Deke said, so your >> mileage may vary) >> >> Cheers, >> Ivan >> >> On Thu, Sep 1, 2011 at 1:55 PM, Deke Kincaid <[email protected]>wrote: >> >>> Exr files are interleaved. So when you look at some scanlines, you need >>> to read in every single channel in the EXR from those scanlines even if you >>> only need one of them. So if you have a multichannel file with 40 channels >>> but you only use rgba and one or two matte channels, then your going to >>> incur a large hit. >>> >>> Another thing is it sounds like you are shuffling out the channels to the >>> rgb before you merge them. This also does quite a hit in speed. It is far >>> faster to merge and pick the channels you need rather then shuffling them >>> out first. >>> >>> -deke >>> >>> On Thu, Sep 1, 2011 at 12:37, Ryan O'Phelan <[email protected]>wrote: >>> >>>> Recently I've been trying to evaluate the load of nuke renders on our >>>> file server, and ran a few tests comparing multichannel vs. >>>> non-multichannel >>>> reads, and my initial test results were opposite of what I was expecting. >>>> My tests showed that multichannel comps rendered about 20-25% slower, >>>> and made about 25% more load on the server in terms of disk reads. I was >>>> expecting the opposite, since there are fewer files being called with >>>> multichannel reads. >>>> >>>> For what it's worth, all reads were zip1 compressed EXRs and I tested >>>> real comps, as well as extremely simplified comps where the multichannel >>>> files were branched and then fed into a contact sheet. I was monitoring >>>> performance using the performance monitor on the file server using only 20 >>>> nodes and with almost nobody using the server. >>>> >>>> Can anyone explain this? Or am I wrong and need to redo these tests? >>>> >>>> Thanks, >>>> Ryan >>>> >>>> >>>> >>>> _______________________________________________ >>>> Nuke-users mailing list >>>> [email protected], http://forums.thefoundry.co.uk/ >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>> >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >> > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
