May 2011 - Pro-apps-dev - lists.apple.com

Re: OpenMP troubles
by Matt Rhodes 31 May '11

31 May '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thanks Steve. This does indeed to seem to be the problem. I'm working on implementing a workaround. Thanks for the thorough response. m On May 31, 2011, at 11:46 AM, Steve Christensen wrote: > In the cases you mentioned, your code is running on the main thread for the dialog case; and likely either the main- or a single background thread in a standalone app. Motion and FCP tend to run the -renderFrame::: methods on multiple background threads, as needed, so you could simply be running into a thread-safety issue where you have multiple concurrent threads, each calling omp_get_max_threads(). (It may appear that this should be a non-issue since it's a "get" function, the implementation may be writing state to a global/shared variable, so concurrent calls could bite you.) > > As Darrin mentioned, it sounds like it'd be safer to call omp_get_max_threads() from your plugin's -initWithAPIManager: method. And if omp_get_max_threads() is a constant value, you could just initialize it once for all instances of your plugin. If you do actually need to call it in your render method, you may need to protect it with a lock so that only once instance at a time is touching it. > > > On May 31, 2011, at 9:39 AM, Darrin Cardani wrote: > >> Matt, >> >> I'm sorry to say that I know nothing about OpenMP, so I have no idea what to suggest. I'm trying to think of safe ways you could call it on the main thread. Generally, you don't want to call [-NSObject performSelectorOnMainThread:withObject:waitUntilDone:] during a render, as you'll likely end up in a dead-lock (at least if you do waitUntilDone). When are you trying to call this? Could it be done in your -initWithAPIManager: method and cached? I'm not positive, but I think -initWithAPIManager: happens on the main thread because it's always invoked as a result of a UI action. >> >> Darrin >> >> On May 27, 2011, at 6:25 PM, Matt Rhodes wrote: >> >>> Note: This seems to be a known bug. >>> http://gcc.gnu.org/ml/gcc-bugs/2008-05/msg01145.html >>> >>> Is there a workaround? >>> >>> Thanks. >>> >>> m >>> >>> On May 27, 2011, at 6:16 PM, Matt Rhodes wrote: >>> >>>> Hey Team. >>>> >>>> Has anyone had trouble using OpenMP in an FxPlug? >>>> >>>> I have it running fine in standalone apps (Carbon and Cocoa). >>>> I also have it running in other hosts (like After Effects). >>>> >>>> But the same code is "crashing" when executed in Motion. >>>> It's failing on my first call to anything OpenMP-related, >>>> in this case: >>>> maxThreads = omp_get_max_threads() ; >>>> >>>> I'm not in an OpenMP loop, so this should execute simply. >>>> >>>> I've found that I can use OpenMP inside our modal dialog box, >>>> just not when rendering to the Motion interface (that is, during >>>> a -renderFrame call). >>>> >>>> Any help is appreciated. We'd rather not disable this rendering speed-up. > _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: OpenMP troubles
by Steve Christensen 31 May '11

31 May '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com In the cases you mentioned, your code is running on the main thread for the dialog case; and likely either the main- or a single background thread in a standalone app. Motion and FCP tend to run the -renderFrame::: methods on multiple background threads, as needed, so you could simply be running into a thread-safety issue where you have multiple concurrent threads, each calling omp_get_max_threads(). (It may appear that this should be a non-issue since it's a "get" function, the implementation may be writing state to a global/shared variable, so concurrent calls could bite you.) As Darrin mentioned, it sounds like it'd be safer to call omp_get_max_threads() from your plugin's -initWithAPIManager: method. And if omp_get_max_threads() is a constant value, you could just initialize it once for all instances of your plugin. If you do actually need to call it in your render method, you may need to protect it with a lock so that only once instance at a time is touching it. On May 31, 2011, at 9:39 AM, Darrin Cardani wrote: > Matt, > > I'm sorry to say that I know nothing about OpenMP, so I have no idea what to suggest. I'm trying to think of safe ways you could call it on the main thread. Generally, you don't want to call [-NSObject performSelectorOnMainThread:withObject:waitUntilDone:] during a render, as you'll likely end up in a dead-lock (at least if you do waitUntilDone). When are you trying to call this? Could it be done in your -initWithAPIManager: method and cached? I'm not positive, but I think -initWithAPIManager: happens on the main thread because it's always invoked as a result of a UI action. > > Darrin > > On May 27, 2011, at 6:25 PM, Matt Rhodes wrote: > >> Note: This seems to be a known bug. >> http://gcc.gnu.org/ml/gcc-bugs/2008-05/msg01145.html >> >> Is there a workaround? >> >> Thanks. >> >> m >> >> On May 27, 2011, at 6:16 PM, Matt Rhodes wrote: >> >>> Hey Team. >>> >>> Has anyone had trouble using OpenMP in an FxPlug? >>> >>> I have it running fine in standalone apps (Carbon and Cocoa). >>> I also have it running in other hosts (like After Effects). >>> >>> But the same code is "crashing" when executed in Motion. >>> It's failing on my first call to anything OpenMP-related, >>> in this case: >>> maxThreads = omp_get_max_threads() ; >>> >>> I'm not in an OpenMP loop, so this should execute simply. >>> >>> I've found that I can use OpenMP inside our modal dialog box, >>> just not when rendering to the Motion interface (that is, during >>> a -renderFrame call). >>> >>> Any help is appreciated. We'd rather not disable this rendering speed-up. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: OpenMP troubles
by Darrin Cardani 31 May '11

31 May '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: OpenMP troubles
by Paul Miller 30 May '11

30 May '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 Another Note: I'm not having this trouble in FCP - just Motion (using v4.0.3). On 5/27/2011 8:33 PM, Matt Rhodes wrote: I hit this on Avid when they rolled out a new version of Media Composer. They pointed to that bug and told me to switch to the Intel compiler. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: OpenMP troubles
by Matt Rhodes 28 May '11

28 May '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: OpenMP troubles
by Matt Rhodes 28 May '11

28 May '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

OpenMP troubles
by Matt Rhodes 28 May '11

28 May '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: getting a CPU FxPlug to down-rez in FCP?
by Paul Miller 23 May '11

23 May '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 Unfortunately, not in the "may remap time" case. We should automatically do this for the image wells - last I checked, FCP was smart enough to know when your image wells are empty, and run you RT if that was the case. Okay, thanks for clarifying. At least we know the reasons now. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… On 5/23/2011 2:14 PM, Paul Schneider wrote: Is there any way to say "99% of the time I'm RT", and switch on the non-RT code path only when needed? (I'm guessing not, but worth a shot!) But the "may remap time" situation is unfortunate. It turns out there are lots of plugins with similar usage patterns to yours. This email sent to site_archiver(a)lists.apple.com

1 0

Re: getting a CPU FxPlug to down-rez in FCP?
by Paul Schneider 23 May '11

23 May '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com > Is there any way to say "99% of the time I'm RT", and switch on the non-RT code path only when needed? (I'm guessing not, but worth a shot!) Unfortunately, not in the "may remap time" case. We should automatically do this for the image wells - last I checked, FCP was smart enough to know when your image wells are empty, and run you RT if that was the case. But the "may remap time" situation is unfortunate. It turns out there are lots of plugins with similar usage patterns to yours. On May 23, 2011, at 11:15 AM, Paul Miller wrote: >> >> Dynamic down-ressing is a feature of FCP's RT engine. There are certain features that aren't available in the RT engine, and if your plugin uses one of those features, we'll run it in another, "non-RT" codepath that doesn't do dynamic quality adjustment. If you use the FxTemporalAPI (and set the mayRemapTime flag in your poperties dict), you'll find yourself in this state. You'll also find yourself here if you have any non-empty image well parameters. > > AHA! I guess I'm guilty of two of those things, but in this case, they aren't used all the time. We have an image well that CAN be used to reference another clip, but it's used rarely. And, the first time the effect is applied, it references the first frame of the clip, and then ignores it after that. > > Is there any way to say "99% of the time I'm RT", and switch on the non-RT code path only when needed? (I'm guessing not, but worth a shot!) > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.com > > This email sent to pschneider(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: getting a CPU FxPlug to down-rez in FCP?
by Paul Miller 23 May '11

23 May '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 Dynamic down-ressing is a feature of FCP's RT engine. There are certain features that aren't available in the RT engine, and if your plugin uses one of those features, we'll run it in another, "non-RT" codepath that doesn't do dynamic quality adjustment. If you use the FxTemporalAPI (and set the mayRemapTime flag in your poperties dict), you'll find yourself in this state. You'll also find yourself here if you have any non-empty image well parameters. AHA! I guess I'm guilty of two of those things, but in this case, they aren't used all the time. We have an image well that CAN be used to reference another clip, but it's used rarely. And, the first time the effect is applied, it references the first frame of the clip, and then ignores it after that. Is there any way to say "99% of the time I'm RT", and switch on the non-RT code path only when needed? (I'm guessing not, but worth a shot!) _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0