Skip to main content
Richard Rosenman
Richard Rosenman
Inspiring
October 19, 2023
Answered

Multithreading vs MFR (SDK)

  • October 19, 2023
  • 1 reply
  • 294 views

Hi gang;

 

I am about to start looking at implementing MFR (Multi Frame Rendering) for my plug-in and I have a question.

 

My understanding is that MFR allocates system CPU cores to frames. So if your system has 4 cores, it renders 4 frames concurrently for previews, renders, etc.

 

If this is the case, I assume it's a bad idea to implement multithreading into plugins as they will conflict, no? It sounds like it should be EITHER multithreading OR MFR? A multithreaded plug-in would use the same cores AE would use for MFR, presumably at the same time (not good!).

 

Am I correct in my assumption? It also sounds like, given a choice between the two, MFR might be the better way to go as it seems not only easier to integrate, but also more compatible with the AE pipelije? I saw that most included plugins are now MFR enabled so it appears to be the new norm.

 

Please advise.

 

Thanks,

Richard

    This topic has been closed for replies.
    Correct answer shachar carmi

    Well... It's both. Mfr and mt seem as if they shouldn't live together, but they do.

    On the rendering pipeline of a single frame, not all steps are multi-threadable, that's where mfr shines. However, the parts that are multi-threadable are usually critical and high performance. Such code bits tend to be cpu cache friendly, and therefore make the most of the cpu during their time slots. Other bits may be cache hostile and therefore leave the cpu waiting for ram to be fetched.

    All that means that mixing mfr with mt doesn't necessarily cause competition between mfr and mt threads.

     

    When using the iteration callbacks, i guess ae can prioritize mfr and mt threads, but i don't know if it's done or not.

     

    Other factors include plugins that are not mfr enabled, and those relying on gpu to render. So the linear approach of "one core per frame" doesnt always (and probably often) apply.

     

    In any case, the ae engineeing team tested these scenarios extensively, and have arrived at the current mechanism. I trust they made decisions that are optimal for the wide range of rendering scenarios ae encounters...

    1 reply

    S
    Community Expert
    shachar carmiCommunity ExpertCorrect answer
    Community Expert
    October 19, 2023

    Well... It's both. Mfr and mt seem as if they shouldn't live together, but they do.

    On the rendering pipeline of a single frame, not all steps are multi-threadable, that's where mfr shines. However, the parts that are multi-threadable are usually critical and high performance. Such code bits tend to be cpu cache friendly, and therefore make the most of the cpu during their time slots. Other bits may be cache hostile and therefore leave the cpu waiting for ram to be fetched.

    All that means that mixing mfr with mt doesn't necessarily cause competition between mfr and mt threads.

     

    When using the iteration callbacks, i guess ae can prioritize mfr and mt threads, but i don't know if it's done or not.

     

    Other factors include plugins that are not mfr enabled, and those relying on gpu to render. So the linear approach of "one core per frame" doesnt always (and probably often) apply.

     

    In any case, the ae engineeing team tested these scenarios extensively, and have arrived at the current mechanism. I trust they made decisions that are optimal for the wide range of rendering scenarios ae encounters...

      Firefly Community Gallery
      Adobe Firefly

      Remix with Firefly Community Gallery

      Thousands of free creations to fall in love with and remix in Firefly.

      Explore now
      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices