[OfxHost] tiling + thread disabling

[Eloi Du Bois]

Hi,


I'm writing a plugin where I set:
desc.setSupportsTiles(false);
desc.setRenderThreadSafety(OFX::eRenderUnsafe);

in the void PluginFactory::describe( OFX::ImageEffectDescriptor& desc ) function.

Then, I create a graph that containing 3 connected nodes using the tuttleofx host code.
inputbuffer -> plugin -> outputbuffer

The problem I'm having is that the process is requesting a multithreaded + tiled processing of my plugin process, which I was not expecting.

Is there any trick or thing I'm missing?

It's hard for me to code an example with the lib only, so if you don't mind, first I'd like your opinion.

Many thanks,
Best regards,
Eloi du Bois.

[arnaud.ma...@free.fr]

Hello Eloi ;-)

Nice to see active users ;-)
I think you can test to set similar options than Reader/Writer in Tuttle.
Lot of them depends of libraries to decode the image in the entire part, without tiling.

In the case of the AudioVideo Plugin, you have also the threading disabled (due to the importance of the image order to encode...)

You have here: https://github.com/tuttleofx/TuttleOFX/blob/develop/plugins/image/io/Raw/src/reader/RawReaderPluginFactory.cpp#L58
an example for a reader.
Looking on AudioVideo: https://github.com/tuttleofx/TuttleOFX/blob/develop/plugins/image/io/AudioVideo/src/reader/AVReaderPluginFactory.cpp#L76
I think you can set that:

desc.setRenderThreadSafety(OFX::eRenderInstanceSafe);
desc.setHostFrameThreading(false);
desc.setSupportsMultiResolution(false);
desc.setSupportsMultipleClipDepths(true);
desc.setSupportsMultipleClipPARs(true);
desc.setSupportsTiles(false);


Tell us if it's better with that ;-)

Cheers,
Marc-Antoine


----- Mail original -----
De: "Eloi Du Bois" <eloi.d...@gmail.com>
À: "tuttleofx-dev" <tuttle...@googlegroups.com>
Envoyé: Mardi 22 Août 2017 17:23:07
Objet: [tuttleofx-dev] [OfxHost] tiling + thread disabling

--

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "tuttleofx-dev".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse tuttleofx-de...@googlegroups.com .
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout .

[arnaud.ma...@free.fr]

Hi Eloi,

Can you try to add also to disable tiling on clip:
dstClip->setSupportsTiles(false);

as it's done here: https://github.com/tuttleofx/TuttleOFX/blob/develop/plugins/image/io/AudioVideo/src/reader/AVReaderPluginFactory.cpp#L96

Marc-Antoine


----- Mail original -----
De: "Eloi Du Bois" <eloi.d...@gmail.com>

À: "arnaud marcantoine" <arnaud.ma...@free.fr>
Envoyé: Mardi 22 Août 2017 23:59:38
Objet: Re: [tuttleofx-dev] [OfxHost] tiling + thread disabling




Hi Arnaud,


Unfortunately, the proposed solution is not helping,

Here is a bit more log (my image size is 1931x1900):

Running 1 test case...
[2017-08-22 16:52:52.959746] [0x00005b50] [trace] [OFX to Gil] Row distance fr
om image 30896 bytes
[2017-08-22 16:52:52.960746] [0x00005b50] [trace] [OFX to Gil] Tile view, row
size = 30896
[2017-08-22 16:52:52.960746] [0x00005b50] [trace] [OFX to Gil] Tile is equal t
o the full view
[2017-08-22 16:52:52.962746] [0x00005b50] [trace] [OFX to Gil] Full view, row
size = 30896
[2017-08-22 16:52:52.967747] [0x00005b50] [trace] [OFX to Gil] Image orientati
on independant
[2017-08-22 16:52:52.968747] [0x00005b50] [trace] [OFX to Gil] Row distance fr
om image 30896 bytes
[2017-08-22 16:52:52.970748] [0x00005b50] [trace] [OFX to Gil] Tile view, row
size = 30896
[2017-08-22 16:52:52.971748] [0x00005b50] [trace] [OFX to Gil] Tile is equal t
o the full view
[2017-08-22 16:52:52.973748] [0x00005b50] [trace] [OFX to Gil] Full view, row
size = 30896
[2017-08-22 16:52:52.976749] [0x00005b50] [trace] [OFX to Gil] Image orientati
on independant

I put a std::cout of the procWindowRoW in my multiThreadProcessImages function, I am expecting only 4 lines, but it seems that there is a tiling + multithreading active:
procWindowRoW.x1: 0
procWindowRoW.x1: 0
procWindowRoW.x2: 1931
procWindowRoW.y1: 95
procWindowRoW.x1: 0
procWindowRoW.x2: 1931
procWindowRoW.y1: 570
procWindowRoW.y2: 665
procWindowRoW.x1: 0
procWindowRoW.x2: 1931
procWindowRoW.y1: 190
procWindowRoW.y2: 285
procWindowRoW.x1: 0
procWindowRoW.x2: 1931
procWindowRoW.y1: 1615procWindowRoW.x1: 0
procWindowRoW.x2: 1931
procWindowRoW.y1: 1425
procWindowRoW.y2: 1520
procWindowRoW.x1: 0
procWindowRoW.x2: 1931
procWindowRoW.y1: 1520
procWindowRoW.y2: 1615


Tell me if you want a code example reproducing the problem,



2017-08-22 16:21 GMT-05:00 < arnaud.ma...@free.fr > :

[Eloi Du Bois]

Hi Arnaud,

Thank you for your answer,

This is already activated and put as false. I also checked on the inputbuffer and outputbuffer, they are set as false on the clips. Unfortunately, it's not working.

Thanks for your help,

Cheers,

Eloi.

Virus-free. www.avast.com

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse tuttleofx-dev+unsubscribe@googlegroups.com .

[Clément Champetier]

Hi Eloi, 

It seems you correctly set your plugin. Maybe this is a host issue... Did you try to use your plugin on a different OFX host? To reduce the scope of where to look at?

Actually, I think that in your case, the Tuttle host cannot find a compatible way to run your graph : input/output buffers may have some limitation...

Cheers,

Clement

[Eloi Du Bois]

Hi again,

I made a small example that reproduces the problem,

I hope this will help,

You will see many lines with 'Pass num .....', and this is not expected (I'm expecting one line, meaning one compute).

Many thanks,

[Fabien Castan]

Hi Eloi,

Sorry for the delay, I didn't received the email due to a configuration error in my account on the mailing list.

Your problem is on the plugin side and not on the host side.

By default, the utility class for plugin processor creates multiple RoI and process them in parallel.

So you just have to call: `this->setNoMultiThreading();` from your `DummyProcess` constructor to disable this behavior as it's done in all IO plugins.

For instance, in the video writer plugin: https://github.com/tuttleofx/TuttleOFX/blob/ca7eb4c22ecbd47a2e2ae55fa7f45c56a3dd3675/plugins/image/io/AudioVideo/src/writer/AVWriterProcess.tcc#L25

Best,

[Eloi Du Bois]

Hi Fabien,

Thank you very much, this is fixing my problem :D

However, I think this should be a default behavior when:
    eRenderUnsafe,       /**< @brief can only render a single instance at any one time */
    eRenderInstanceSafe, /**< @brief can call a single render on an instance, but can render multiple instances simultaneously */

is set.

Am I wrong in the interpretation of those flags?

Thanks,

[Fabien Castan]

Thank you very much, this is fixing my problem :D

Great.

However, I think this should be a default behavior when:
    eRenderUnsafe,       /**< @brief can only render a single instance at any one time */
    eRenderInstanceSafe, /**< @brief can call a single render on an instance, but can render multiple instances simultaneously */ 

is set.

Am I wrong in the interpretation of those flags?

It is not really related. These parameters are about thread safety between independant renderings. So if you want to allow the host to run multiple renderings of your node in parallel (at different time or on different node instances, etc.).

But setNoMultiThreading() is only inside the plugin. It is only about local multi-threading from a single rendering call from the host.

So you can disable the multi-threading from the host (if you rely on a global variable for instance), and then implement a preprocessing step that use this gobal variable in setup and then use local multi-threading for the real computation...

Maybe the bad choice in the API is to have the default value at true. It may have been better to have a default value at false and explicitely ask for it instead of explicitely disabling it.

[Eloi Du Bois]

Ok, I see: intra vs inter frame multithreading.

Yes, false as default is a safer choice. On my side, for certain processes I prefer using Halide for the multithreading, that's why I am not using Tuttle's intra-frame multithreading. It's a useful feature though.

Another question related to this one:

When the intra-frame multithreading is enabled, inside my process function, shall I use:
    OfxRectI procWindowOutput = this->translateRoWToOutputClipCoordinates( procWindowRoW );

 and then crop both srcView and dstView?

Many thanks,

[Fabien Castan]

Another question related to this one:

When the intra-frame multithreading is enabled, inside my process function, shall I use:
    OfxRectI procWindowOutput = this->translateRoWToOutputClipCoordinates( procWindowRoW );

 and then crop both srcView and dstView?

It's implemented here in this base classe:

https://github.com/tuttleofx/TuttleOFX/blob/develop/libraries/tuttle/src/tuttle/plugin/ImageProcessor.hpp#L143

Each thread receive an RoI to compute which are regular subparts of the RoD (which can have negative coordinates, etc.).

Then it depends on many things, if your plugin change the RoD of the output, if it changes the RoI propagation on the input clips, etc.