Isn't it easier to run second MLVApp in Background and make communication between the Main MLVApp and the Background copies (Instead of doing it manually in my case , I mean split the work between MLVApps copies from XX frame to XX frame) ? for good Multiprocessing and Multithreading at the same time without re-coding algorithms , Or you just want good algorithms for these things for not complicate the things more ? Not sure I am not a coder.
This is more or less what we did in past. Not with MLVApp copies, but with copies of pipelines. Partially you must allow access only to one single pipeline to certain memory spaces (e.g. file reading, parameter settings,...), so you'll have to lock and unlock some sections, this makes the game very difficult. Hard to explain in an easy way for non-SW-developpers. It is way easier if the user runs multiple instances of a program manually.
Another Question about only single threaded stages in the pipeline , These single threaded stages must be single threaded ? or more knowledge required to get it working multithreaded properly ? . .
These are algorithms implemented for being single threaded. Examples are Dual-ISO, Recursive Bilateral Filter "RBF" (for highlights, shadows, clarity and denoiser). Maybe it is possible to get it multithreaded somehow - but not with our existing code. So someone should understand how that has to work and write a own multithreaded implementation.
Edit: especially for the RBF filter it would bring a lot of speed. I found this algorithm here:
https://github.com/Fig1024/OP_RBF There are ways for getting it faster (see diagrams). Problem: the algorithm is for RGB24 (3x8bit) by standard. With some effort I managed to get it to RGB48 (3x16bit) with some changes in the code. But this luck I just had for the simplest "standard/original implementation", not for the SSE and AVX versions. And - really - I have no idea at all how that works.
Show Posts
