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 >> > >
layers_vs_shuffles.nk
Description: Binary data
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
