Georgly, Why is that? Please explain.
Steve -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Georgiy Osipov Sent: Thursday, June 14, 2012 2:09 AM To: Nuke plug-in development discussion Subject: Re: [Nuke-dev] need advice about single-thread engine() call Be careful, do not read input imaged in _open() method. It can create serious problems for example with OFX plugins. 2012/6/7 Steven Booth <[email protected]>: > Ah! Got it. I tend to do such things in the _open method, actually, > and then use the threaded, parallel engine calls to actually render > the data computed in open. > > > > Steve > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of Kin > Ming Mike WONG > Sent: Wednesday, June 06, 2012 10:25 PM > To: Nuke plug-in development discussion > Subject: Re: [Nuke-dev] need advice about single-thread engine() call > > > > hi steve, > > > > about "typical", i was referring to using the { Guard guard(_lock); } > approach to achieve a single threaded engine() call, sorry for the > confusion. > > > > it's because I need to do a parallel reduction on the image data using > existing tbb processing function, so it's important to get the > tile/image processed as quickly as possible by upstream nodes from my > single-threaded > engine() call and then forward the data to my processor. any > suggestion on this ? > > thanks, > > mike > > > > On Wed, Jun 6, 2012 at 10:56 PM, Steven Booth <[email protected]> wrote: > > Mike, > > > > Each node is implemented as a separate class, and each has a unique > instantiation of the associated engine method. It is therefore not > the case that a single, one-threadded node will cause all nodes above > it to operate in single-threaded mode. That presumes there is one and > only one node connected to each output, which may not be the case. It > is, however, true that your single-threadded node will create a > bottleneck, slowing down whatever path your node is in. > > > > Although it is true that you can request Tiles in multi-threadded > mode, if you're only going to process it in a single thread, it won't > speed things up. > > > > It's a bit strange, though, that you call a single-threadded engine > 'typical', because the normal methodology is multi-threaded. > > > > Might I ask why you need to process things single-threadded in your node? > > > > Steve > > > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of > mike.artixels > Sent: Wednesday, June 06, 2012 4:38 AM > To: [email protected] > Subject: [Nuke-dev] need advice about single-thread engine() call > > > > Hello everyone, > > I have a small plug-in which relies on typical single thread engine() > call using Guard to do some pre-processing of the upstream image data, > and if I understand correctly, this single threaded call will simply > turn every upstream nodes running single-threadedly too .... so everything > slows down. > > Is there any trick that I could pull data from upstream multi-threaded > ? or am I missing or misunderstood anything here .... > > many thanks !! > > Mike > > (CONFIDENTIALITY NOTICE: The information contained in this email may > be confidential and/or privileged. This email is intended to be > reviewed by only the individual or organization named above. If you > are not the intended recipient, or an authorized representative of the > intended recipient, you are hereby notified that any review, > dissemination or copying of this email, or the information contained > herein is strictly prohibited. If you have received this communication > in error, please notify the sender by return email and delete this > email from your system. Thank You.) > > > > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > > > > (CONFIDENTIALITY NOTICE: The information contained in this email may > be confidential and/or privileged. This email is intended to be > reviewed by only the individual or organization named above. If you > are not the intended recipient, or an authorized representative of the > intended recipient, you are hereby notified that any review, > dissemination or copying of this email, or the information contained > herein is strictly prohibited. If you have received this communication > in error, please notify the sender by return email and delete this > email from your system. Thank You.) > > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev (CONFIDENTIALITY NOTICE: The information contained in this email may be confidential and/or privileged. This email is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient, or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email, or the information contained herein is strictly prohibited. If you have received this communication in error, please notify the sender by return email and delete this email from your system. Thank You.) _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
