-
Pierre Jasmin: I think V1 is just fine for now. Using
OS
can be bad particularly when the host renders multiple frames at once. Also some hosts allow you to limit how many CPU you run on, so ignoring what hosts tells you will cause trouble. Also using host provided threads has proved in other apps to render faster. In the case of one OFX host here we did have to revert to
OS
as there was somehow a significant performance degradation. In light of next gen processors (16/24/32 cores), it would probably be indicated for plugin to tell to host that I tested this and I good until 8, or 1 if I am not multi-threaded….
- Bruno Nicoletti : as it stands the plug-in itself can choose to use as many threads as the host allows it
- Pierre Jasmin : Actually would be useful to know how many frames at once an app is currently multiprocesing…
OfxStatus (*multiProcessingThreads)(unsigned int *nFramesAtOnce);
Is the proposal to create a different suite: e.g. kOfxMultiThreadSimpleSuiteV1 and kOfxMultiThreadSuiteV2 ? Basically where kOfxMultiThreadSimpleSuiteV1 does not have the mutex calls… and plugin just uses OS calls. Or simply keep kOfxMultiThreadSuiteV1 as is and if host does not support OfxMultiThreadSuiteV1 he must support kOfxMultiThreadSimpleSuiteV1 …
- Pierre Jasmin: (a year later) - New idea is perhaps what we need is an additional and different suite ofxMultiProcess whose purpose is for the host to educate the plugin about what is going on right now. The original ofxMultiThread suite was in a way sort of based on Shake explicit requirement to control the threading… and it probably still has value for easily tileable operations (for plugins that support tiling flag so they don't multithread in such context for example). Also I am seeing that background processing will become more popular as the number of cores grow, so to just use the OS system info might not hold as it would not allow an host in a 2 processors context to set to a child affinity of just the CPU of a processor etc… to prevent the background process to take over the system… Another example could be what if I want to use the GPU to do sorting while I process something else on the CPU.
In response to Pierre. The idea was to deprecate the suite entirely and just allow a plugin to use the native host APIs to spawn threads. However, the host still needs to say how many threads the plugin can use to do whatever it is it is doing. In that way you can stop a plugin over subscribing the number of cores available.
So each action would have a new property on the inArgs, kOfxPropNumberThreadsAllowed, which would be the total number of threads the plugin could launch.
The only problem I can see with this is cost of continual thread spawn/destruction. As you suggest, we could have a rev of the threading API, which is slightly tidier than the current one, which allows access to that thread pool. The host still needs to tell the plugin, on a per action basis, how many threads it is allowed to use.