Fusion page: Major performance issue with MediaIn v Loader

Get answers to your questions about color grading, editing and finishing with DaVinci Resolve.
  • Author
  • Message
Offline
User avatar

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Fusion page: Major performance issue with MediaIn v Loader

PostSun Jun 21, 2020 9:46 pm

I'm putting this in the Resolve forum because it's specific to the Fusion page in Resolve; the problem does not apply to standalone Fusion Studio.

Issue: MediaIn nodes loading image files (tested PNG, JPG and TGA) are killing performance for me in Resolve's Fusion page. Switching to Loader nodes (pointing to the exact same files) magically causes the performance to return to normal, and matches Fusion Studio.

Edited on 23rd August 2020 and 13th September 2021: Based on the discussions of this thread, it has been shown that:

1. This issue happens with an still image being loaded by a MediaIn node in Resolve's Fusion page, of any format (eg JPG, PNG, TGA, TIFF).

2. It happens regardless of the source of the MediaIn, ie whether it's dragged direct from the Media Pool, or whether it's timeline media.

3. The issue is related to caching. It would appear that MediaIn nodes do not cache single-frame still images, whereas the Loader node fully caches this in RAM.

You can spot the difference immediately by looking at the green cache bar: it will never fill for a MediaIn, whereas a Loader will cache the entire timeline range instantly.

Therefore a single-frame still image accessed via MediaIn is re-processed on every frame - as if it was video footage or an image sequence - where the same image loaded via Loader is processed once, then cached for the full composition range. This accounts for the vast performance difference seen, especially when high resolution images are used.

4. As well as the significant performance problems noted in this post, this issue can also cause out-of-VRAM issues, especially for users with 4GB or less VRAM. It's also been shown to cause significantly higher GPU usage.

5. The issue is not connected to the fact that MediaIn nodes default to Float32: when depth is matched between a Loader node and a MediaIn, the Loader will always perform better, usually significantly better.

Since I first found and reported this issue, I have heard from at least 6 other people (on top of those who have posted in the thread) that they were experiencing performance and/or stability problems in Resolve's Fusion page that were resolved by replacing their MediaIn nodes for Loaders.

Original post continues:

Here's a simple node layout that exhibits the issue:
Image

The layout shown is using two MediaIn nodes to load two large image files from the MediaPool. Both files are 6000x4000. One is a PNG, the other a TGA. The TGA file is a greyscale height map for the PNG.

This will get 2 - 2.3 FPS when I watch the Renderer3D:
Image

I see even worse performance if I add the Fusion comp to a Timeline and render it via Deliver. Rendering 150 frames from the composition shown to ProRes 422 took 103 seconds, an average of 1.45 FPS.

If I then swap both MediaIn nodes for two Loaders, loading the exact same files from disk, performance will return to its expected level of 30 FPS. If I replace only one of the MediaIn, performance is still very bad.

I've prepared a sample project that quickly demonstrates the issue:

Link to download ResolveFusionMediaInPerformanceTest.zip from Google Drive

The ZIP contains a DRP, one PNG and one TGA file. The project contents are:
Image

  • FusionMediaInTest contains the node layout shown in the first screenshot. It accesses the provided PNG and TGA files through MediaIn nodes, and gives 2.2 FPS when monitoring the Renderer3D
  • FusionLoaderTest contains the some structure except MediaIn nodes are replaced with Loader nodes, accessing the exact same files on disk. This gives me 30 FPS when monitoring the Renderer3D
Last edited by TheBloke on Tue Dec 14, 2021 6:59 am, edited 7 times in total.
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline
User avatar

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Re: Fusion page: Major performance issue with MediaIn v Load

PostMon Jun 22, 2020 8:37 am

This morning I did another quick test, and confirmed that the issue seems to exist with all images.

New test:
* Testing TestCard.png and TestCard.jpg , which are of size 1920x1080 (same as project).
* Simple non-3D composition:
Image

* Result: With MediaIn, playback is 6-7 FPS.
Image

With Loader, playback is 30, but actually it's much faster than that: the whole of the 1000 frame composition caches in about a second when a Loader node is used.

I had previously wondered if the issue was specific to large images, ie larger than the project resolution. This test indicates that seemingly it's any and all images.

Unless I have some major misconfiguration of Resolve (please do let me know), this seems to me to be a very serious issue. In short, MediaIn nodes are majorly defective for image files at the moment. Thankfully there's an easy workaround, but it took me a long time to come to that realisation, so I can imagine this is going to be affecting a lot of other people without them knowing what the problem is, or how to fix it.

Thanks.
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline
User avatar

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Jun 24, 2020 2:26 pm

One more data point: The issue occurs identically if one adds an image to a timeline, then opens Fusion on that image clip. In other words, it exists in the 'standard' use case as well, and not only if one drags extra images from the Media Pool or disk into a composition to make extra MediaIn nodes.

Example 1920x1080 30 FPS timeline, containing one 1920x1080 PNG image:
Image

Open Fusion on this timeline, create the following simple node layout (see below for code):
Image

Result: Time to render a 30 second timeline via Deliver page = 119 seconds (7.56 FPS)

Replace the MediaIn with a Loader node that loads the same image from disk, and time to render the same 30 second timeline via Deliver = 5 seconds (180 FPS)

Based on this test, Loader node is approx 23 times faster than the MediaIn node! (when still images are involved.)

Tested on Resolve Studio 16.2.3.015 on macOS 10.14.6.

Node layout used for the test:
Code: Select all
{
   Tools = ordered() {
      MediaIn1 = MediaIn {
         ExtentSet = true,
         ViewInfo = OperatorInfo { Pos = { 660, 148.5 } },
         CustomData = {
            MediaProps = {
               MEDIA_HEIGHT = 1080,
               MEDIA_WIDTH = 1920,
               MEDIA_START_FRAME = 0,
               MEDIA_SRC_FRAME_RATE = 30,
               MEDIA_NUM_FRAMES = 150,
               MEDIA_NUM_LAYERS = 0,
               MEDIA_NAME = "TestCard.png",
               MEDIA_LAYER_DESC = {
               },
               MEDIA_PAR = 1,
               MEDIA_PATH = "/Volumes/data/projects/Resolve/TestCard.png",
               MEDIA_FORMAT_TYPE = "PNG",
               MEDIA_MARK_IN = 0,
               MEDIA_MARK_OUT = 149
            }
         },
         Inputs = {
            ClipTimeEnd = Input { Value = 149 },
            Layer = Input { Value = "0" },
            ["Gamut.SLogVersion"] = Input { Value = FuID { "SLog2" } },
            GlobalOut = Input { Value = 149 }
         }
      },
      Duplicate1 = Fuse.Duplicate {
         ViewInfo = OperatorInfo { Pos = { 770, 148.5 } },
         Inputs = {
            Copies = Input { Value = 125 },
            Background = Input {
               Source = "Output",
               SourceOp = "MediaIn1"
            },
            JitterAxis = Input { Value = { -0.1551, 0 } },
            RandomSeed = Input { Value = 26024 },
            Center = Input { Value = { 0.2952, 0.362 } },
            JitterCenter = Input { Value = { -0.0459, -0.1428 } }
         }
      },
      Glow1 = Glow {
         ViewInfo = OperatorInfo { Pos = { 880, 148.5 } },
         Inputs = {
            Blend = Input { Value = 0.2 },
            XGlowSize = Input { Value = 7.5 },
            Glow = Input { Value = 0.654 },
            Filter = Input { Value = FuID { "Fast Gaussian" } },
            Input = Input {
               Source = "Output",
               SourceOp = "Duplicate1"
            }
         }
      },
      Sharpen1 = Sharpen {
         CtrlWZoom = false,
         ViewInfo = OperatorInfo { Pos = { 990, 148.5 } },
         Inputs = {
            Input = Input {
               Source = "Output",
               SourceOp = "Glow1"
            },
            XAmount = Input { Value = 100 }
         }
      },
      MediaOut1 = MediaOut {
         ViewInfo = OperatorInfo { Pos = { 1210, 148.5 } },
         Inputs = {
            Input = Input {
               Source = "Output",
               SourceOp = "Sharpen1"
            },
            Index = Input { Value = "0" }
         }
      }
   }
}
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Jul 15, 2020 8:55 am

This is something I realized awhile back, too.

MediaIn nodes essentially pick up from different parts of Resolve's render pipeline so it's always downstream to a lot of other Resolve code. How much code it's downstream to depends on a lot of things.

Since Resolve's graphics pipeline is exclusively 32-bit, MediaIn nodes always convert the source media to 32-bit instead of using it's native format.

MediaIns that reference clips in the Media Pool are still downstream to all the bit-depth conversion and any Clip Attribute processing. That includes any input sizing presets, flipping, flopping, rotation, frame rate interpretation, deinterlacing, and of course super scaling, noise reduction, sharpness, and LUT processing.

If you create a comp using a Fusion Clip then each MediaIn is essentially downstream from the entire Resolve graphics pipeline. Timeline parsing, Input sizing, Edit sizing, EditFX, PreClip grades, Clip grades, PostClip grades, Timeline grades, Output sizing, Transitions and other Fusion compositions can all come before that MediaIn node.

By comparison Loader nodes allow Fusion to access the source media directly. Loader nodes are also faster for video. I just created a project using MediaIn nodes that's similar to the one I messaged you about.

Image

As you can see, the playback speed was about 1.3 frames/sec.

Resolve 16 Studio's Loaders can't import things that aren't picture sequences and I don't have access to Fusion Studio 16 so I had to copy the composition into Fusion 9 to use Loaders.

Image

Performance still isn't stellar but 4.2 frames/sec is a hell of a lot better.
Offline

Jim Simon

  • Posts: 29809
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Jul 15, 2020 1:02 pm

I brought a PNG into a timeline, moved over to Fusion, added a Transform and keyframed Size.

Without Caching, I got 24 fps playback on the Edit page. Got 40 to 50 fps when rendering out on Deliver using a much older GTX 960.

Studio 16.2.4 for Windows.
My Biases:

You NEED training.
You NEED a desktop.
You NEED a calibrated (non-computer) display.
Offline
User avatar

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Jul 15, 2020 2:16 pm

Jim Simon wrote:I brought a PNG into a timeline, moved over to Fusion, added a Transform and keyframed Size.

Without Caching, I got 24 fps playback on the Edit page. Got 40 to 50 fps when rendering out on Deliver using a much older GTX 960.

Studio 16.2.4 for Windows.
I just retested Studio 16.2.4 on macOS and the problem remains.

However yes, I do not see it with a single Transform node. I placed a 2 minute, 30 FPS Fusion Comp on a Timeline, and tested MediaIn vs Loader passed into a single Transform, keyframed to scale from 1 to 100 over the 2 minutes. Render times were 30-40 seconds with no obvious difference between MediaIn vs Loader.

So Transform doesn't seem to show the issue. I quickly tested a single Resize node, and there was also no noticeable difference there.

However the issue is easy to demonstrate with a slightly more complex node flow.

If you'd like to recreate what I'm seeing, try these simple steps:

0. Download this 1920x1080 test image: https://www.flickr.com/photos/marksmanuk/3098983708
1. Create a new blank project
2. Import that image into the Media Pool
3. Create a Fusion Composition of around 2 minutes length, drag it on to a Timeline.
4. Drag that test card image into the Composition, so it appears as MediaIn
5. Create the following three nodes, and put them between the MediaIn and MediaOut, as shown here:
Image

Nodes:
Code: Select all
{
   Tools = ordered() {
      Glow1 = Glow {
         Inputs = {
            Blend = Input { Value = 0.2, },
            Filter = Input { Value = FuID { "Fast Gaussian" }, },
            XGlowSize = Input { Value = 7.5, },
            Glow = Input { Value = 0.654, },
            Input = Input {
               SourceOp = "Duplicate1",
               Source = "Output",
            },
         },
         ViewInfo = OperatorInfo { Pos = { 825, 148.5 } },
      },
      Sharpen1 = Sharpen {
         Inputs = {
            XAmount = Input { Value = 100, },
            Input = Input {
               SourceOp = "Glow1",
               Source = "Output",
            },
         },
         ViewInfo = OperatorInfo { Pos = { 935, 148.5 } },
      },
      Duplicate1 = Fuse.Duplicate {
         Inputs = {
            Copies = Input { Value = 125, },
            Center = Input { Value = { 0.2952, 0.362 }, },
            RandomSeed = Input { Value = 26024, },
            JitterCenter = Input { Value = { -0.0459, -0.1428 }, },
            JitterAxis = Input { Value = { -0.1551, 0 }, },
         },
         ViewInfo = OperatorInfo { Pos = { 715, 148.5 } },
      }
   }
}

6. Play in Fusion, and expect to see FPS below 10; it's 7.5 for me. Deliver the Timeline, and see similar FPS. To render a 2 minute comp took me 7:51 which is 7.64 FPS.
7. Now replace the MediaIn node with a Loader node, that loads the exact same image direct from disk
8. When I deliver the same 2 minute timeline with the comp using a Loader, it delivered in 21 seconds - 171 FPS.

That's a synthetic test, but I first noticed the issue on a real project, where I had two 6000x4000 images involved in a Fusion 3D scene. One was placed on an ImagePlane, and the other was used to Displace3D that plane. Using the OpenGL renderer I was getting 3.3 FPS when using MediaIn nodes to load those images. Swapping out for Loader increased that performance to 20+ FPS.
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline
User avatar

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Jul 15, 2020 2:18 pm

Hi Mark,

Mark Grgurev wrote:MediaIn nodes essentially pick up from different parts of Resolve's render pipeline so it's always downstream to a lot of other Resolve code. How much code it's downstream to depends on a lot of things.

Since Resolve's graphics pipeline is exclusively 32-bit, MediaIn nodes always convert the source media to 32-bit instead of using it's native format.
Yeah that's a good point, and I agree that it's Resolve's render pipeline that is somehow causing this issue.

But I do still believe that it is a bug, not just a necessary result of how Resolve handles images.

As described in the post to Jim, I'm testing in a simple test project. It involves a single 1920x1080 PNG image, dragged directly into a Fusion Composition via MediaIn. I can see the issue immediately when hitting Play within Fusion, which doesn't pass through any Timeline transforms or similar. I can also add that Comp to a Timeline and Deliver, which does pass through Timeline code, but gives basically exactly the same performance. There's no color grades or anything else.

This results in playback of around 7.5 FPS. Swapping it for a Loader gave me 170-180 FPS, a 20+ fold difference.

I can't see how such a vast performance difference could possibly be down to int8 vs float32 alone, or any of the standard Clip Attribute stuff Resolve does.

If that pipeline was really that slow, wouldn't it show for videos also? I've not detected any significant difference in video processing performance when comparing Resolve Studio using MediaIn to Fusion Studio using Loader.

Based on your post I earlier did a couple further tests:
1. I went back to that project, and added a ChangeDepth node after the MediaIn, dropping the source image to int8.
Image

This did increase performance.. from 7.5 to 8.5 FPS :)

2. I loaded Fusion Studio, and tried the opposite: I used a Loader to load the same image, and then added a ChangeDepth node that converted it up to float32. Then I also tried just editing the Loader to set the Format to float32 directly.

This gave me 58 FPS. Lower than the 180 I saw before, but still 6.8 times faster than Resolve processing int8.

So I remain convinced that there's some nasty performance bug here. It's very likely related to the Resolve rendering pipeline, but it's not the float32 vs int8 difference alone, and I can't see how it can be providing anything like the intended performance.

Also, just to be clear that it's not only me seeing this. Since I opened this thread I've had two people say they've seen significant performance increases from swapping MediaIn nodes to Loader for their images.
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline

Jim Simon

  • Posts: 29809
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Jul 15, 2020 2:54 pm

TheBloke wrote:the issue is easy to demonstrate with a slightly more complex node flow.


Maybe try disabling those nodes in various combinations, see if any one node shows up as the cause.
My Biases:

You NEED training.
You NEED a desktop.
You NEED a calibrated (non-computer) display.
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Jul 15, 2020 7:45 pm

Jim Simon wrote:Maybe try disabling those nodes in various combinations, see if any one node shows up as the cause.

He and I are both seeing differences in performance between Loader and MediaIn despite having completely different node trees. It's definitely down to Loaders vs MediaIn

TheBloke wrote:Yeah that's a good point, and I agree that it's Resolve's render pipeline that is somehow causing this issue.

But I do still believe that it is a bug, not just a necessary result of how Resolve handles images.


I'm a little perplexed by why it would result in such a large difference as well but I guess my overall point was that I don't think the MediaIn node will ever match the performance of the Loader node.

TheBloke wrote:As described in the post to Jim, I'm testing in a simple test project. It involves a single 1920x1080 PNG image, dragged directly into a Fusion Composition via MediaIn. I can see the issue immediately when hitting Play within Fusion, which doesn't pass through any Timeline transforms or similar. I can also add that Comp to a Timeline and Deliver, which does pass through Timeline code, but gives basically exactly the same performance. There's no color grades or anything else.


Bringing a composition into the timeline from the Media Pool wouldn't change where the MediaIn sits within Resolve's pipeline so that's as expected.

TheBloke wrote:This results in playback of around 7.5 FPS. Swapping it for a Loader gave me 170-180 FPS, a 20+ fold difference.


Still images seem to see a much larger increase in performance when using loaders than video. I would have thought there would be less of a difference since it should just go through Resolve's pipeline once then just cache the image in memory.

My current theory is that the MediaIn isn't necessarily aware that it's getting an image. It's getting the media post Clip Attribute processing, so maybe it sees everything as video and Fusion can't optimize for it properly?

In the comp you made with the testcard, you can see that Both enable looping which suggests that MediaIn is at least somewhat aware that it's image but look at the Global In/Out areas of both nodes.

Image
The Loader sees it as 1 frame.

Image
The MediaIn sees it as 150 frames. You can see that there's a small sliver of green. I wasn't sure what that was so I played around with some stuff. I checked the image's Clip Attributes in the Media Pool and saw that it's frame rate was set as 30 fps. When I changed it to 24 fps, that green area became smaller. Then when I changed it to 1 fps, it disappeared (prob just under the handle). So it looks like MediaIns see images as 1 second videos at whatever frame rate they're interpreted as.

Image
Next I set the the MediaIn's Global In/Outs to 0 still and it doesn't seem to show the blue bar that the Loader node shows. Not really sure what that means. Changing these settings also didn't improve performance any.

TheBloke wrote:I can't see how such a vast performance difference could possibly be down to int8 vs float32 alone, or any of the standard Clip Attribute stuff Resolve does.


I actually mentioned that in my original response but I took it out because looked messy and I felt like you would find that out anyway lol Yea, I definitely don't think it has to do strictly with bit-depth conversion.

TheBloke wrote:If that pipeline was really that slow, wouldn't it show for videos also? I've not detected any significant difference in video processing performance when comparing Resolve Studio using MediaIn to Fusion Studio using Loader.


That's interesting. Wouldn't that suggest that the difference in performance I was seeing for video is just Fusion 9 being faster that Fusion Studio 16 and Resolve 16 then? I was seeing a 3.2x performance increase in Fusion 9.

Edit: Looks like that might be a possibility. Just saw this topic that brought up how slow the CustomTool is in Fusion 16 compared to Fusion 9. Apparently performance improved significantly in todays update (the example comp runs at 22 fps for me) but it's still way slower than Fusion 9 which runs it at 54 fps.



TheBloke wrote:Based on your post I earlier did a couple further tests:
1. I went back to that project, and added a ChangeDepth node after the MediaIn, dropping the source image to int8.

This did increase performance.. from 7.5 to 8.5 FPS :)

2. I loaded Fusion Studio, and tried the opposite: I used a Loader to load the same image, and then added a ChangeDepth node that converted it up to float32. Then I also tried just editing the Loader to set the Format to float32 directly.

This gave me 58 FPS. Lower than the 180 I saw before, but still 6.8 times faster than Resolve processing int8.


Weird lol When I did the same in my test last night, it actually dropped performance which is what I expected given that it's adding an extra conversion. Now by adding a ChangeDepth in your example I'm seeing performance increase.

TheBloke wrote:So I remain convinced that there's some nasty performance bug here. It's very likely related to the Resolve rendering pipeline, but it's not the float32 vs int8 difference alone, and I can't see how it can be providing anything like the intended performance.


I'm not so convinced it's bug. It feels like too obvious of a bug for BMD not to have caught. If the MediaIn nodes are just as fast as Fusion Studio 16's Loaders with video but much slower with stills then the fact that Resolve's Loaders can only import stills would make it seem like its something they know about.

Not trying to sound conspiratorial, I'm just doubling down on my thought that Fusion doesn't really know when MediaIn is feeding it a still. In fact, I don't really even know if Resolve is aware of what is or isn't a still image past a certain point in it's pipeline since it will allow you to apply everything from Stabilization to Retiming on an image.

I found another difference between Loaders and MediaIns just now that could potentially be a clue as to their behavioral differences but I don't know because it isn't mentioned in the manual.

Make sure at least one frame of the node tree has been rendered then hover over both nodes.

Image

Notice that the MedianIns say "Depth 32bit float (GPU)" while the Loaders say "Depth 32bit float (Mem)". I'm assuming that means that MediaIns are storing assets in GPU memory while Loaders use system memory.

Could you check to see if Fusion Studio has anything similar? If Fusion Studio's Loaders show GPU for video and Mem for stills then that means Loaders have a special-cases for stills and video while MediaIns treat them generically. If both show Mem than that means that where they're stored could be the entire reason for the performance differences.

TheBloke wrote:Also, just to be clear that it's not only me seeing this. Since I opened this thread I've had two people say they've seen significant performance increases from swapping MediaIn nodes to Loader for their images.


Myself included.
Offline
User avatar

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Re: Fusion page: Major performance issue with MediaIn v Load

PostThu Jul 16, 2020 11:07 am

Ah ha! You may well be onto something here, Mark. As you predicted, Fusion Studio shows Mem for both nodes.

The right-hand Loader is a ProRes Mov made from the same test card image:
Image

So that's a clear difference between the two methods and it could well be the culprit. Still images are constantly being refreshed in VRAM or something like that?

I'm a little perplexed by why it would result in such a large difference as well but I guess my overall point was that I don't think the MediaIn node will ever match the performance of the Loader node.
I suppose it would be reasonable to expect a few % points difference, but anything getting into high double digits seems to me to be a problem by definition. And a 23x discrepancy is just ludicrous.

Because if Loader can load it that fast, then MediaIn could too - if they allow altering/bypassing whatever the difference between those methods currently is. If the performance difference is some inevitable consequence of intended and useful functionality like Resolution Independence or image scaling or whatever - which I still don't really believe, given the size of the discrepancy - then there should be options to toggle those on and off for a given clip or MediaIn node.

At which point the user would clearly understand that these things come with a major performance penalty, and users who don't need those features in a given comp or for a given file - like us, in our current examples - could simply disable them. Or enable them, because I'd argue the properly performing version should be default.

Or if the answer is "If you don't want those features, use Loader", then this should be clearly documented. There should be a big red banner in the Resolve manual saying: "Images loaded via MediaIn have to be processed in the GPU VRAM because of XYZ, and this usually results in lower performance. A Loader node can be used instead in situations where you don't need XYZ."

The severity of the performance discrepancy and the absence of any such options or documentation, is what makes me believe this is a bug. Which is not to say BMD don't know about it - I hope they do now at least, else there's no point making these threads :) But it could be one of those issues that's waiting for other work to be done in the same area, or requires a rethink on how the pipeline is processed. Or it could be already fixed in the alphas of v17.

Right now I would say this is giving Resolve Fusion a bad name. Maybe most people aren't affected or just haven't noticed, but at least some people will have come away with the impression that Fusion's performance is terrible. One of the two people I mentioned as having told me they had the same issue was using Fusion for the first time, and complaining how much slower it was than After Effects. Yeah, AE, that app known to be horribly slow and inefficient. Once I told him to replace his MediaIn with Loaders, he got much more reasonable performance.

Because at the end of the day we're not talking about a performance difference between 200 and 100 FPS, ie both well above a respectable threshold. I can't see how getting 6-7 FPS on simple operations could be expected or considered acceptable.

That's interesting. Wouldn't that suggest that the difference in performance I was seeing for video is just Fusion 9 being faster that Fusion Studio 16 and Resolve 16 then? I was seeing a 3.2x performance increase in Fusion 9.


Yeah quite possible. I did a quick test in which I used ffmpeg to make a 1 minute ProRes video out of that test card PNG, accompanied by a silent WAV.

Piping that into my three node test structure (Duplicate, Glow, Sharpen), Resolve Studio and Fusion Studio both processed it at about 6.5 FPS. Slightly slower than when using the static PNG, but pretty similar - which to me seems to be interesting in and of itself. A single frame image is processed only marginally faster than a 30 FPS video? This again seems to imply that some kind of caching is not happening with images that should be, as if it's re-reading the image every frame, or re-populating it in VRAM ever frame, or whatever. (FYI: at the least it's not literally re-reading the image from disk, I checked :) )

Fusion 9 (free version) got 9.5 FPS.

Anecdotal reports I've read of Fusion 9 v 16 indicate that the former is faster for some things, the latter in other things. There's been a lot of discussion of this over on the We Suck Less forum, including a thread made this week.

Resolve Studio is generally reported to be slower than Fusion Studio (any version) - eg on the CustomTool comp you referenced, I see 32 FPS in Fusion Studio 16.2.4 but only 22 in Resolve Studio 16.2.4.

However in my own project, which uses a lot of 3D stuff, I've not so far noticed a significant difference, and I didn't again today when I did the quick test with the test card video. So I guess certain areas are affected more than others, and it may depend on where the bottleneck is - eg perhaps when the GPU is the bottleneck there's less or no difference between Resolve and Fusion Studio, but in other situations there is. Not sure yet.

RAM is one area where the will definitely be a practical difference, as Fusion Studio will usually be able to use more RAM than Resolve's Fusion page. In my case, the maximum I can allocate to Resolve is 36GB, which gives Fusion 27GB. Whereas Fusion Studio is able to use 38GB when it's run in isolation.

What I do have in Resolve is issues with Fusion performance suddenly going through the floor for no discernable reason. This happened again last night. For the first time I started a render of all three scenes of my project, involving three separate Fusion compositions. I started it rendering at midnight, and the ETA was 3.5 hours, which was expected. This morning at 9am it said it still had 3 hours remaining, and I had to cancel it and waste all of that effort (I was exporting to ProRes MOV, so the file is useless when aborted early), because I couldn't trust that it would even finish in a further 3 hours.

I restarted Resolve and started a render on two of the scenes, totalling 6 mins between them, and they completed fine at the expected performance of 2.5 - 3.5 FPS.

I've seen that before when I've started a Deliver after a long Resolve Fusion session, and learned from that to always restart Resolve before starting a Deliver of a complex Fusion comp. But last night I think I did restart Resolve shortly before starting the render. I guess I might have to render scene-by-scene in future and then combine the resulting intermediate files in a separate render. It's very frustrating to come to the computer in the morning and find that it's still not done, have to gamble as to whether leave it running multiple more hours during which I can't do any further Resolve work, and which could turn in to half a day if it continues to slow down. Or else just write off the whole night's rendering time.

There's quite a lot of work still to do on Resolve's Fusion page, I would say.
Last edited by TheBloke on Thu Jul 16, 2020 2:13 pm, edited 1 time in total.
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline

Jim Simon

  • Posts: 29809
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostThu Jul 16, 2020 1:55 pm

Mark Grgurev wrote:It's definitely down to Loaders vs MediaIn


But not exclusively, else that difference would show up in my simple test as well.

There is an undiscovered variable remaining.
My Biases:

You NEED training.
You NEED a desktop.
You NEED a calibrated (non-computer) display.
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostThu Jul 16, 2020 11:55 pm

TheBloke wrote:Ah ha! You may well be onto something here, Mark. As you predicted, Fusion Studio shows Mem for both nodes.

The right-hand Loader is a ProRes Mov made from the same test card image:
Image

So that's a clear difference between the two methods and it could well be the culprit. Still images are constantly being refreshed in VRAM or something like that?


That's actually a surprise to me. Of the two possibilities I presented I kind of was leaning toward Loaders showing Mem for Stills and GPU for videos.

TheBloke wrote:I suppose it would be reasonable to expect a few % points difference, but anything getting into high double digits seems to me to be a problem by definition. And a 23x discrepancy is just ludicrous.

Because if Loader can load it that fast, then MediaIn could too - if they allow altering/bypassing whatever the difference between those methods currently is.

If the performance difference is some inevitable consequence of intended and useful functionality like Resolution Independence or image scaling or whatever - which I still don't really believe, given the size of the discrepancy - then there should be options to toggle those on and off for a given clip or MediaIn node.


I think bypassing all the things that make MediaIn slower might also bypass the the purpose of a MediaIn node. Think of all the things Fusion attempts to do with MediaIns.

1. Links to items in the Media Pool
2. Links to clips on the timeline pre-grade
3. Links to A and B clips post-grade for transitions
4. Links to tracks post-grade

It's really the sole means of a Fusion composition integrating into parts of Resolve's graphics pipeline.

In scenario 1 it's being used like a Loader but it's functional difference is that Resolve is handling the access to the source media, applying clip attributes, and then passing the data stream to Fusion. In theory, this comes early enough in the pipeline that there might be some possibility of special-casing stills but even that's not a given because a still image could be paired with a video matte. It would really just be better to use Loaders at that point (since they're there) instead of further complicating MediaIn.

In scenarios 3 and 4, it's doing the same as 1 and 2 but it's pulling more than one clip at a point in the pipeline before the timeline grade but after post-clip grades. You couldn't optimize for stills here because tracks need to have a temporal dimension in order to be considered tracks and and anything after transforms and EditFX are applied could have keyframes and would need to be treated like video.

Scenario 2 is same as scenario 1 the majority of the time. However if it's used on an adjustment clip or Compound Clip or Fusion clip then it's not linking to source media at all and instead inserting itself someone in the middle of Resolve's graphics pipeline after one or more clips has been graded and flattened into tracks. The manual even suggests using Compound Clips to force certain effects onto a clip ahead of import into the Fusion page.

The purpose of MediaIns, put generically, is to work as an insertion points into Resolve's graphics pipeline. That's why they're paired with MediaOut nodes which tell Fusion when to jump back to point they left Resolve's graphics pipeline. BMD just lets you use them at a point in Resolve's processing pipeline where they almost work like a Loader replacement. In actuality, Loaders and Savers are file I/O nodes while MediaIns are pipeline I/O nodes. In programming terms, they work like functions. MediaIns are the Jumps and the MediaOuts are the Returns.

Now that I think of it, that's probably why Loaders show Mem while MediaIns show GPU. File I/O operations move things from disk to system memory while Resolve's graphics pipeline is clearly storing it's results in GPU memory.

That's kind of why I'm so adamant about repositioning Fusion in Resolve's pipeline in my own topic. MediaIns are really the sole point of integration into Resolve's pipeline and project structure. The situations where they're used like Loaders are situations where Loaders would work better. The situations where they aren't used like Loaders are where they're really being used like effects. By optimizing how Fusion and Resolve interact with each other around that understanding, then they can work in an integrated way without having to actually make each other more complicated.

But anyway, this is your topic, I'm not trying to hijack it with mine lol

TheBloke wrote:At which point the user would clearly understand that these things come with a major performance penalty, and users who don't need those features in a given comp or for a given file - like us, in our current examples - could simply disable them. Or enable them, because I'd argue the properly performing version should be default.


Honestly there's a lot of problems that Resolve's interface has with communicating stuff to the user and they really need to work on that. The Color page feels particularly bad at this because it always shows you all the tools even if they can't be used on that node but there are other places that don't even have tooltips to tell you what an icon does.

TheBloke wrote:Or if the answer is "If you don't want those features, use Loader", then this should be clearly documented. There should be a big red banner in the Resolve manual saying: "Images loaded via MediaIn have to be processed in the GPU VRAM because of XYZ, and this usually results in lower performance. A Loader node can be used instead in situations where you don't need XYZ."


I just checked the manual to see if there's any mention of that. It just tries to paint the Loader and MediaIn nodes as being the same which we know isn't true. It even says that MediaIns have a Depth option and we know it doesn't.

One new thing I figured out is that, when Resolve Color Management is enabled, the MediaIn node will always convert it's output to Linear Color Space and the MediaOut always converts it back to timeline color space. Without RCM, you need to manually set the color space. I didn't actually know it does that and it means that even the MediaOut could have some small performance overhead. I just thought it was a way to specify an outpoint.

I also don't really understand that behavior. Doesn't that mean that turning on RCM has the potential to mess up existing compositions?

TheBloke wrote:The severity of the performance discrepancy and the absence of any such options or documentation, is what makes me believe this is a bug. Which is not to say BMD don't know about it - I hope they do now at least, else there's no point making these threads :) But it could be one of those issues that's waiting for other work to be done in the same area, or requires a rethink on how the pipeline is processed. Or it could be already fixed in the alphas of v17.


I guess time will tell but with how loaded (no pun intended) MediaIn nodes are, I really do feel like a good amount of that performance drop is built-in.

TheBloke wrote:Right now I would say this is giving Resolve Fusion a bad name. Maybe most people aren't affected or just haven't noticed, but at least some people will have come away with the impression that Fusion's performance is terrible.


I think it already has a bad name... at least to some extent. A lot of long-time Fusion users didn't like the new interface and I've been in a few topics where people non-Fusion users were advocating to get it out of Resolve because Resolve felt buggier to them after it was introduced. I remember one person saying that Resolve was detecting changes to a clip's Fusion composition and slowing down playback. I told him to Right Click > Reset Fusion Composition and he said he did that already and the problem persisted.

I remembering wanting to get into node-based compositing and saw that BMD had Fusion but it looked like it wasn't updated in awhile so I was really hoping they would add it to Resolve. Maybe a month later Resolve 15 was announced with Fusion integrated. I took to it very quickly and was doing fully procedural island scenes in like a month. I was ecstatic, but shortly after that I realized there was a lot of big issues with how they integrated it and realized why people were asking for stand-alone version of Fusion.

Then when I was editing for Muscle and Fitness, I ran into a few situations where an encode stopped because I accidentally made a change to a clips Fusion composition without realizing it and the encoder had some sort of issue with it.

TheBloke wrote:One of the two people I mentioned as having told me they had the same issue was using Fusion for the first time, and complaining how much slower it was than After Effects. Yeah, AE, that app known to be horribly slow and inefficient. Once I told him to replace his MediaIn with Loaders, he got much more reasonable performance.


That's shocking lol I guess I've only done one apples-to-apples comparison between After Effects and Fusion but that test showed Resolve Studio to be maybe a little quicker while using a lot less memory than AE.

TheBloke wrote:Because at the end of the day we're not talking about a performance difference between 200 and 100 FPS, ie both well above a respectable threshold. I can't see how getting 6-7 FPS on simple operations could be expected or considered acceptable.


Agreed.

TheBloke wrote:Yeah quite possible. I did a quick test in which I used ffmpeg to make a 1 minute ProRes video out of that test card PNG, accompanied by a silent WAV.

Piping that into my three node test structure (Duplicate, Glow, Sharpen), Resolve Studio and Fusion Studio both processed it at about 6.5 FPS. Slightly slower than when using the static PNG, but pretty similar - which to me seems to be interesting in and of itself. A single frame image is processed only marginally faster than a 30 FPS video? This again seems to imply that some kind of caching is not happening with images that should be, as if it's re-reading the image every frame, or re-populating it in VRAM ever frame, or whatever. (FYI: at the least it's not literally re-reading the image from disk, I checked :) )

Fusion 9 (free version) got 9.5 FPS.


Wait then what's slowing down the static PNG in Fusion Studio all of a sudden? Weren't you getting 180 fps last time around?

Or are you saying that Resolve Studio using a PNG via MediaIn was only slightly faster than both Resolve Studio and Fusion Studio using a video of the PNG, but using the PNG via Loader was still much faster. ... I know what I mean by that sentence but it hurts my brain to say aloud lol

TheBloke wrote:Resolve Studio is generally reported to be slower than Fusion Studio (any version) - eg on the CustomTool comp you referenced, I see 32 FPS in Fusion Studio 16.2.4 but only 22 in Resolve Studio 16.2.4.


As somebody whose been working on comp that uses three custom nodes to simulate foveated rendering and image reconstruction, this annoys me. That project took so long to render each frame, I would have taken any speed up I could let along a roughly 50% increase.

TheBloke wrote:RAM is one area where the will definitely be a practical difference, as Fusion Studio will usually be able to use more RAM than Resolve's Fusion page. In my case, the maximum I can allocate to Resolve is 36GB, which gives Fusion 27GB. Whereas Fusion Studio is able to use 38GB when it's run in isolation.


I almost don't get why that's a thing. I get that it needs to reserve some memory for other parts of Resolve's graphics pipeline to do their thing when playing back Fusion comps in the timeline but it really feels like that can be way more dynamically allocated.

TheBloke wrote:I restarted Resolve and started a render on two of the scenes, totalling 6 mins between them, and they completed fine at the expected performance of 2.5 - 3.5 FPS.


I think I've seen that happen before. I can only assume that the same issue that causes encodes to straight up fail when it gets to a Fusion comp is the same issue that causes issues like that.

TheBloke wrote:There's quite a lot of work still to do on Resolve's Fusion page, I would say.


I, for one, would have rather they worked on that instead of adding the Cut page lol
Last edited by Mark Grgurev on Fri Jul 17, 2020 3:38 pm, edited 1 time in total.
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostFri Jul 17, 2020 4:04 am

Jim Simon wrote:I brought a PNG into a timeline, moved over to Fusion, added a Transform and keyframed Size.

Without Caching, I got 24 fps playback on the Edit page. Got 40 to 50 fps when rendering out on Deliver using a much older GTX 960.

Studio 16.2.4 for Windows.


Jim Simon wrote:But not exclusively, else that difference would show up in my simple test as well.

There is an undiscovered variable remaining.


You didn't actually compare it to anything though. For all we know you just used a small PNG. It would be fine if did but you would also need to try the same PNG with a Loader to see if it goes even faster.

Just now I took the 6000x4000px PNG from TheBloke's project in his the original post and added it to blank Fusion composition in the Media Pool as a MediaIn. Then all I did was connect it to the MediaOut and pressed play. I got 8-12 fps. Then I swapped the MediaIn with Loader and got 111 fps.

Did the same thing again only this time I dragged the PNG into a timeline and went into it's Fusion composition. It played back at 9.2-11 fps. Swapped the MediaIn with a Loader again. 110-112 fps. I swapped back to the MediaIn and added a ChangeDepth node afterwards to bring it down to Int8 like the Loader. Played at 13-14fps. Swapped back to the Loader again and changed it to float32. Still 110-112 fps.

It's definitely a Loader vs MediaIn thing.
Offline

Jim Simon

  • Posts: 29809
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostFri Jul 17, 2020 3:29 pm

I used a 5442 x 3061 PNG and saw no difference with my simple test between MediaIn and Loader.

I then tried the Dungeon graphic, and did see a difference.

Finally I tried another of my own PNGs at around 8000 x 5000 and Resolve crashed to desktop.

So perhaps size is the "unknown" variable here.
Last edited by Jim Simon on Fri Jul 17, 2020 3:45 pm, edited 1 time in total.
My Biases:

You NEED training.
You NEED a desktop.
You NEED a calibrated (non-computer) display.
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostFri Jul 17, 2020 3:44 pm

Jim Simon wrote:I used a 5442 x 3061 PNG and saw no difference with my simple test between MediaIn and Loader.

I then tried the Dungeon graphic, and did see a difference.

Finally I tried another of my own PNGs at around 8000 x 5000 and Resolve crashed to desktop.

So perhaps size is the "unknown" variable here.


Interesting! Could you share your PNG with us?

I don't think it's a size thing. Size definitely effects performance but I just tried it with a 2048x2160 PNG and the MediaIn got me 40 fps max while the Loader got me 115.

Also I found more differences between Loaders and MediaIns

Import an image as a MediaIn, go to where it says Source Gamma Space and make sure it's Auto, then select Remove Curve. For me, it darkened. Do the same thing with a Loader and the image is unaffected.

Using GPUZ and Task Manager, I found that MediaIns use up to 10x more PCI-Express bandwidth than Loaders. In this case it was a pretty consistent 5% for the Loader. MediaIns would use ~35% while it still had memory left to fill then went up to 50% once it got to the max that is could use. It's worth noting that doing the same Loader test in Fusion 9 reported 0% PCIE usage and it's status area was showing the program as Idle.

Also I'm pretty sure that Tom manually set the MediaIns in his project to Loop because I'm not seeing that behavior on ones I bring in which more-so confirms that Fusion doesn't know it's a still. Setting it's global in/out to make it one frame long and enabling Loop seemed to reduce memory usage but the max PCI-Express usage was the same.
Offline

Jon Farrell

  • Posts: 7
  • Joined: Fri Dec 13, 2019 11:01 pm
  • Real Name: Jon Farrell

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Jul 28, 2020 2:23 am

Thank you so much for posting these findings. I was consistently getting the gpu memory problem with fusion comps when trying to composite large images and using loaders has fixed the issue. This is a great work around.
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Jul 28, 2020 10:20 am

Jon Farrell wrote:Thank you so much for posting these findings. I was consistently getting the gpu memory problem with fusion comps when trying to composite large images and using loaders has fixed the issue. This is a great work around.

Glad this thread helped you out!
Offline

Jim Simon

  • Posts: 29809
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Jul 28, 2020 9:17 pm

Mark Grgurev wrote:I just tried it with a 2048x2160 PNG and the MediaIn got me 40 fps max while the Loader got me 115.


So there must still be an unknown variable here.

I'm unable to share the PNG I used. Sorry.
My Biases:

You NEED training.
You NEED a desktop.
You NEED a calibrated (non-computer) display.
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostSun Aug 02, 2020 7:45 pm

Jim Simon wrote:So there must still be an unknown variable here.

I'm unable to share the PNG I used. Sorry.


Without us being able to test the one PNG that the Fusion page seems to be able to optimize around then I can only assume there's something flawed in your testing. I've tried a bunch of PNGs and JPG and tried changing a bunch of settings and the result is always the same.
______________________

I just found an instance where Resolve does distinguish between a still and a video clip on the timeline: you can't create a Take Selector on a still but you can on a video clip. Once a Take Selector is created, a still image can be dragged into it but once the still is chosen as a take then it breaks the Take Selector and you can't open it again on that Still clip. You're only give the option to finalize the take.

It still hands it off to Fusion as video though obviously.
Offline

rinsim

  • Posts: 20
  • Joined: Fri Apr 09, 2021 4:00 pm
  • Real Name: Simone Rinco

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Apr 28, 2021 5:49 pm

@TheBloke I have exactly the same problem. I use a lot of images in my Fusion Compositions, and all of them result in an atrociously slow playback and rendering, with resources hardy at 40%.

Your workaround of using a Loader node instead of pulling the images from the Media Pool as Media In nodes, literally changed my life and almost my relationship with my girlfriend. I owe you a drink!

This is serious and incredibly frustrating bug in Fusion (Text+ is another node which performs very very slowly considering what it does).
Offline
User avatar

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Apr 28, 2021 8:24 pm

rinsim wrote:@TheBloke I have exactly the same problem. I use a lot of images in my Fusion Compositions, and all of them result in an atrociously slow playback and rendering, with resources hardy at 40%.

Your workaround of using a Loader node instead of pulling the images from the Media Pool as Media In nodes, literally changed my life and almost my relationship with my girlfriend. I owe you a drink!

This is serious and incredibly frustrating bug in Fusion (Text+ is another node which performs very very slowly considering what it does).
Wow, I wish it'd done all those things for me - I only got an increase in render times! :)

Glad it was helpful. I agree the issue is very frustrating and really detrimental to how Resolve Fusion appears to new users. There must be a lot of people out there who think Resolve's Fusion performs appallingly and don't realise there's a straightforward workaround.

I still don't understand quite what causes this problem - whether it's a necessary result of Resolve's 32bit video pipeline or if there's also a Fusion-specific performance bug. Or both; I suspect both.

Anyway glad it's transformed your Fusion experience - and indeed your life! :)
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline
User avatar

Uli Plank

  • Posts: 21289
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Fusion page: Major performance issue with MediaIn v Load

PostThu Apr 29, 2021 2:15 am

Now this explains why I always found Fusion standalone more responsive and reliable than the integrated one.
I'm normally resorting to VFX Connect for Fusion.
No, an iGPU is not enough, and you can't use HEVC 10 bit 4:2:2 in the free version.

Studio 18.6.5, MacOS 13.6.5
MacBook M1 Pro, 16 GPU cores, 32 GB RAM and iPhone 15 Pro
Speed Editor, UltraStudio Monitor 3G, iMac 2017, eGPU
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostMon May 03, 2021 3:14 am

TheBloke wrote:I still don't understand quite what causes this problem - whether it's a necessary result of Resolve's 32bit video pipeline or if there's also a Fusion-specific performance bug. Or both; I suspect both.

Anyway glad it's transformed your Fusion experience - and indeed your life! :)


I'm pretty confident at this point that it's an inherent issue to MediaIns.
Offline
User avatar

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Re: Fusion page: Major performance issue with MediaIn v Load

PostMon Sep 13, 2021 9:04 pm

Just bumping this to bring it to the attention of people who might not be aware.

I have also since realised that there was a super simple way we could detect the huge difference that MediaIn vs Loader causes:
  1. Drag any still image to the Fusion page to create a MediaIn.
  2. Make a Loader loading the same image.
  3. Select the Loader, and look at the timeline bar; notice how it has the green RAM cache bar extending across its full length. This node is completely cached for the entire duration of the composition:
    Image
  4. Select the MediaIn. Notice that the only frame cached is the current frame. This MediaIn is going to reprocess for every single frame, just like it was video footage:
    Image
Clearly yes, this is a structural design flaw with MediaIn nodes rather than a specific bug. But at the very least I feel this should be highlighted and documented.

The performance differences really can be enormous when still images (logos etc) are used, and it gives a really bad impression of Resolve's Fusion page.
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline
User avatar

Olivier MATHIEU

  • Posts: 865
  • Joined: Thu Aug 04, 2016 1:55 pm
  • Location: Paris/Grenoble, FRANCE

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Sep 14, 2021 9:56 am

Thanks
Resolve Studio 18.6.x & Fusion Studio 18.6.x | MacOS 13.6.x | GUI : 3840 x 2160 | Ntw : 10Gb/s
MacbookPro M2 Max
Offline
User avatar

Uli Plank

  • Posts: 21289
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Sep 14, 2021 10:30 am

That's great research, thank you! Now we can only hope that it helps them fixing it.
No, an iGPU is not enough, and you can't use HEVC 10 bit 4:2:2 in the free version.

Studio 18.6.5, MacOS 13.6.5
MacBook M1 Pro, 16 GPU cores, 32 GB RAM and iPhone 15 Pro
Speed Editor, UltraStudio Monitor 3G, iMac 2017, eGPU
Offline

peterbaumann

  • Posts: 128
  • Joined: Tue Apr 16, 2019 7:23 pm
  • Real Name: Peter Baumann

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Sep 14, 2021 2:26 pm

Hmmm, so I managed to get similar results to everyone else with the original tunnel file project, but I've just tried a new fusion test with my own PNG images and I'm seeing the opposite - generally the MediaIn is performing better!

MediaIn (Small File) 17fps
MediaIn (Ultrawide File) 10fps
Loader (Small File) 14fps
Loader (Ultrawide File) 4.6fps

Link to project file: https://drive.google.com/drive/folders/ ... sp=sharing

System info:
DR Version: 17.2.2
Mac OS 10.15.7
MacBook Pro 15 Inch, 2018
2.6 GHz 6-Core Intel Core i7
32GB 2400MHz DDR4 RAM
Radeon Pro Vega 20 4GB
M1 Max Macbook Pro 16-inch (2021)
OS Monterey 12.6.1
Apple M1 Max
10-Core CPU
32-Core GPU
64GB RAM

Intel MacBook Pro 15-inch (2018)
OS Catalina 10.15.7
2.6GHz 6-Core Intel Core i7
32GB RAM
Radeon Pro Vega 20 4GB
Offline

peterbaumann

  • Posts: 128
  • Joined: Tue Apr 16, 2019 7:23 pm
  • Real Name: Peter Baumann

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Sep 14, 2021 3:05 pm

Strange, a restart of Resolve gave me different results - much quicker with Loader nodes, so I wonder if my RAM limit had been reached after trying the tunnel file, and then it didn't automatically purge the RAM when I tried a new fusion clip?

It's much faster now following a restart of Resolve, and the deliver tab exported near-instantly (2s) the first time I tried my linked above. The export times seem to be a bit all over the place though, from 2s to 11s.

I also tried a long timeline of the same Fusion clip duplicated over and over for 4mins18s. I then exported the file as an H264. Results below.

Loader export:
Total export time - 9m4s
After an initial burst, I got about 12fps average. CPU usage was in the 80-90% range, and GPU sat at around 10-13%.

MediaIn export:
Total export time - 21m42s
Pretty consistent average of 6.5-8fps throughout. CPU usage was in the 40-55% range and GPU sat at 16%.

Not sure why Resolve isn't using the full resources available though?
M1 Max Macbook Pro 16-inch (2021)
OS Monterey 12.6.1
Apple M1 Max
10-Core CPU
32-Core GPU
64GB RAM

Intel MacBook Pro 15-inch (2018)
OS Catalina 10.15.7
2.6GHz 6-Core Intel Core i7
32GB RAM
Radeon Pro Vega 20 4GB
Offline
User avatar

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Sep 14, 2021 4:23 pm

Thanks for the tests, Peter. Weird what happened on your first test - yeah maybe the RAM cache was already filled or something. I'm not quite sure how Resolve handles the Fusion RAM cache when multiple compositions are involved.

I imported your DRA and in an attempt to give a longer test, I increased the length of the Fusion Composition to 10 minutes. I didn't adjust the keyframes, so it did the zoom-in and then it just held frame there, which in the Loader case meant it rendered at very high speed for that portion. Not so for the MediaIn case of course!

In your case where you duplicated the Compositions, you effectively made X different compositions, so the RAM cache for the first one wouldn't be used for the second, and so on. So overall performance in the Loader case would be lower than in my test, both because it had to re-cache for each composition, and because my test had effectively a freeze frame for 95% of its length. The latter having much more impact on performance than the former, I would think.

Anyway, rendering out 10 minutes (14,400 frames) at 1080p to ProRes 422:

- Loader: Completed in 2:00 exactly, an average of 120 FPS.
- MediaIn: Completed in 29:24, an average of 8.16 FPS.

Image

Only a 14.7x difference this time ;)
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline
User avatar

Uli Plank

  • Posts: 21289
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Sep 14, 2021 4:42 pm

Now I finally understand why I always found the standalone version better…
No, an iGPU is not enough, and you can't use HEVC 10 bit 4:2:2 in the free version.

Studio 18.6.5, MacOS 13.6.5
MacBook M1 Pro, 16 GPU cores, 32 GB RAM and iPhone 15 Pro
Speed Editor, UltraStudio Monitor 3G, iMac 2017, eGPU
Offline
User avatar

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Sep 14, 2021 4:49 pm

Uli Plank wrote:Now I finally understand why I always found the standalone version better…
Yeah, if a person doesn't know about this issue with MediaIn on still images, it can seem like Resolve Fusion's performance is just ridiculously bad.

Once you know to avoid MediaIn for stills, I've found performance pretty comparable in v17. And unfortunately I've recently been having some performance problems in Fusion Studio that I'm not experiencing, or not as much, in Resolve. So I've come to the strange place where Resolve is actually working well and Studio isn't.

But yeah, I wonder how many people out there think Resolve Fusion is just hopeless and it turns out it's only because they had a couple of PNGs in there.

Another difference is how Resolve defaults to float32 everywhere. So if you don't think to manually change that to float16 with a ChangeDepth node, or even down to int8 in places where that's viable (no colour corrections involved etc), you're storing twice or four times as much data in RAM and VRAM as you may be in Fusion Studio. That can also make a really big difference to performance.
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline

peterbaumann

  • Posts: 128
  • Joined: Tue Apr 16, 2019 7:23 pm
  • Real Name: Peter Baumann

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Sep 14, 2021 5:28 pm

I'm glad I discovered this thread, as I've been sat trying to render screenshot animations for a few projects recently and it's been pretty painfully slow to render/cache, or doesn't cache at all.

Can you elaborate a bit on your last point? If I'm just importing screenshots (and likely don't need to do color adjustments etc.), I should drop it down to float16? Where does the float depth change node go in a flow (straight after the media file or at the end of the chain), and are there any things I should watch out for if doing that? Are there any node workflows where float32 is advantageous?
M1 Max Macbook Pro 16-inch (2021)
OS Monterey 12.6.1
Apple M1 Max
10-Core CPU
32-Core GPU
64GB RAM

Intel MacBook Pro 15-inch (2018)
OS Catalina 10.15.7
2.6GHz 6-Core Intel Core i7
32GB RAM
Radeon Pro Vega 20 4GB
Offline

Videoneth

  • Posts: 1615
  • Joined: Fri Nov 13, 2020 11:03 pm
  • Warnings: 1
  • Real Name: Maxwell Allington

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Dec 15, 2021 2:36 am

I didn't read everything, just the first comments because I had to test myself.
It looks like it improved my VFX comp by switching to a loader node for some of the images.
But I can't really tell because it's not perfect (it's a 4k comp) and there is still some stuttering when I go back to the timeline.

The Bloke, do you think that the media in with the main video com should be loaded the same way as an image? Like rendering the clip then instead of creating a fusion comp from the timeline, make an empty fusion comp and load the images and the videos with loaders? - EDIT : I just tested, I can't load a video file with a loader :/

And I agree too, it's a bug in my opinion.

You already saved me so many FPS with your script for the motion blur problem (which should still be fixed) :D

Dude, you can't imagine how many times it frustrated me. Having a framerate of 0.5 to 1 fps while rendering some of my fusion comp in the delivery page, with just basic images moving around, with motion blur too lol (granted, it was in 4k). And many times I couldn't render anything, and crashed.

Thanks
Windows 10
18.6.6
nVidia 3090 - 537.42
Offline
User avatar

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Dec 15, 2021 7:08 am

Yeah Resolve Fusion's Loader node has been crippled so it only loads image formats, not video footage. So you have to use MediaIn for video footage.

However even if the Loader could load video footage, it likely wouldn't make a performance difference. The issue with the MediaIn node and single-frame still images is that they don't get cached. A Loader node will load the still image once, then cache the pixels in RAM; no further processing is required, across the full frame range. A MediaIn will not do this caching, and thus it re-processes the image on every frame.

For single-frame still images, this makes an enormous difference. But for image sequences and video footages, it makes no difference - because they are changing on every frame anyway, and always have to be read/processed on every single frame regardless. So I noticed no performance difference using a MediaIn node to load an image sequence versus using a Loader to do the same, and if Loader nodes could load video footage (as they can in Fusion Studio), I'd expect the same result.

So just remember that any time you have a single-frame still image, always use a Loader. For image sequence you can use either MediaIn or Loader as you prefer (I'd use Loader if it's non-timeline media, but if I'm working on media on a timeline, then it has to be MediaIn and that's fine). And for video footage, it has to be MediaIn in all cases.
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline

Videoneth

  • Posts: 1615
  • Joined: Fri Nov 13, 2020 11:03 pm
  • Warnings: 1
  • Real Name: Maxwell Allington

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Dec 15, 2021 5:08 pm

I just tested another clip where I have a track node, and a simple image replacing something on a car. It's much smoother now when it plays on the fusion page (after it's cached, but the green line doesn't appear for some reason, sometimes it does).

Finally, my 3090 seems to work as intended now lol. I'm sure there are still tons of optimization BM can make.
Windows 10
18.6.6
nVidia 3090 - 537.42
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostMon Jan 24, 2022 12:44 am

Maxwellx wrote:And I agree too, it's a bug in my opinion.


It's absolutely not a bug.

All of clips in the Media Pool are 32 bit per channel video. That's why everything, including stills have frame rate, clip length, data level, Input Sizing, Input LUT, lens (which really should be a clip attribute), super scale, orientation, and a bunch of other attributes. That's also why you can't change the bit-depth they import with.

MediaIns take in arbitrary streams of this format from either the Media Pool or the Timeline. The earliest stage in the pipeline that MediaIns allow you to grab that stream is after all that aforementioned processing is applied. You can test this by importing some media as a MediaIn, then changing the clips attributes, Lens Correction, or add a LUT. You'll see the changes reflect in your composition.

Loaders, on the other hand, are reading the media directly from the disk with no hidden conversion happening.

What TheBloke mentioned is correct. Using Loaders for still images can give you an enormous speed-up and reduce memory usage but they'll have less of performance increase over MediaIns with video. However because MediaIns still apply those effects and conversations before the video is imported, they can't realistically hit the same performance highs that Loaders can and can't be as memory efficient.
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostMon Jan 24, 2022 1:05 am

peterbaumann wrote:If I'm just importing screenshots (and likely don't need to do color adjustments etc.), I should drop it down to float16?


If it's just screenshots then use Loaders since they'll bypass and video and bit-depth conversion. By default, Loaders will import images at their native bit-depth which is Int8 in most cases.

peterbaumann wrote:Where does the float depth change node go in a flow (straight after the media file or at the end of the chain),


It would be right after the MediaIn.

peterbaumann wrote:and are there any things I should watch out for if doing that?


If you see any weird banding issues then that would be a sign that maybe you need to higher precision of higher bit-depths. I would always try to work in lower bit-depths and only work at higher precision when it's needed.

A good amount of nodes don't support Int8 and will automatically convert to float16 so in those cases it might be better to only convert to float16 with the DepthChange node so you can avoid the additional conversion.

peterbaumann wrote:Are there any node workflows where float32 is advantageous?


I'm sure Float32 is useful for things like World Position buffers since it's basically mapping vertices to pixels but other than that, FP16 should be more than enough. I've actually made a thread asking for support for FP16 image processing in Resolve as a whole, not just for that reason but also because newer GPUs have support for processing 16b floats at up to twice the speed of 32b floats.
Offline
User avatar

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Jan 25, 2022 8:39 am

Mark Grgurev wrote:It's absolutely not a bug.
It's not a bug in the sense that it's working as it was designed. It is however IMHO a significant design flaw.

Mark Grgurev wrote:All of clips in the Media Pool are 32 bit per channel video. That's why everything, including stills have frame rate, clip length, data level, Input Sizing, Input LUT, lens (which really should be a clip attribute), super scale, orientation, and a bunch of other attributes. That's also why you can't change the bit-depth they import with.

MediaIns take in arbitrary streams of this format from either the Media Pool or the Timeline. The earliest stage in the pipeline that MediaIns allow you to grab that stream is after all that aforementioned processing is applied. You can test this by importing some media as a MediaIn, then changing the clips attributes, Lens Correction, or add a LUT. You'll see the changes reflect in your composition.

Loaders, on the other hand, are reading the media directly from the disk with no hidden conversion happening.
This is all true but so far as I can tell, is not the cause of this problem.

My testing indicates that the root cause of the issue is the fact that MediaIn nodes do not cache single-frame images in RAM. If standard Fusion RAM caching was added on top of the image pipeline you've described, I believe the problem would go away.

This is evidenced by the fact that I see no performance difference between Resolve loading image sequences via Loader versus MediaIn. Therefore the Resolve image pipeline is not in itself a significant bottleneck.

The problem is solely with single-frame images, which the Loader can cache to RAM after reading and processing once, but which MediaIn re-processes on every frame. I can't see why Resolve's Fusion shouldn't be able to apply RAM caching after the image pipeline; for a single frame image Resolve's image pipeline is static, in the sense that Clip Attributes and the like will always apply until changed - it's not possible for them to vary over time.

So whatever processing Resolve has to do before passing the image data to Fusion, it seems to me that at least in the case of single-frame Media Pool images, it should definitely be possible to RAM cache the result in Fusion, which I believe would solve this problem.

I can see it not being possible - or at least more complex - to apply RAM caching for single frame images dragged to Timelines, but for any image dragged direct from the Media Pool (which is already distinguished by Resolve, giving a different variant of MediaIn with frame length controls ) I can't see why it couldn't be cached.
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostThu Jan 27, 2022 1:10 am

TheBloke wrote:It's not a bug in the sense that it's working as it was designed. It is however IMHO a significant design flaw.

I would agree but I would say it's just one of many unwanted results that came from Fusion being poorly integrated into Resolve.

TheBloke wrote:My testing indicates that the root cause of the issue is the fact that MediaIn nodes do not cache single-frame images in RAM. If standard Fusion RAM caching was added on top of the image pipeline you've described, I believe the problem would go away.

This is evidenced by the fact that I see no performance difference between Resolve loading image sequences via Loader versus MediaIn. Therefore the Resolve image pipeline is not in itself a significant bottleneck.

I just tested that with an FP16 EXR sequence in a 120fps Fusion comp. The Loader plays the sequence back at around 15-17fps while a MediaIn plays it at 8.3-9.7fps. Interestingly, they both import the sequence as F16 so the nearly 2x performance increase isn't the result of format conversion overhead or memory writing overhead.

For PNG sequences, they perform about the same though. I'm getting 5.8-6.6 fps with MediaIns and 5.16.4 with Loaders.

TheBloke wrote:The problem is solely with single-frame images, which the Loader can cache to RAM after reading and processing once, but which MediaIn re-processes on every frame. I can't see why Resolve's Fusion shouldn't be able to apply RAM caching after the image pipeline; for a single frame image Resolve's image pipeline is static, in the sense that Clip Attributes and the like will always apply until changed - it's not possible for them to vary over time.

So whatever processing Resolve has to do before passing the image data to Fusion, it seems to me that at least in the case of single-frame Media Pool images, it should definitely be possible to RAM cache the result in Fusion, which I believe would solve this problem.


This is all true but I don't agree with that solution. You're asking for a special case behaviour for a tool that's behaviour is already frequently misunderstood all so that it may gain the behaviour of an already existing tool but in a more round about way and without the ability to import it at a lower bit-depth.

It feels like it would just be patching up the result of a problem instead of fixing the cause of the problem.

MediaIns should not be positioned as a Loader alternative. They should just treated as what they are: pipeline hook that differ in behaviour based on the role of the composition.

Let Loaders import video, images, and image sequences and let Resolve create Loaders when you drag something into a composition from the Media Pool. You get the exact functionality you want but MediaIns don't have to pretend they do anything other than pointing to arbitrary video streams based on the composition's role.

TheBloke wrote:I can see it not being possible - or at least more complex - to apply RAM caching for single frame images dragged to Timelines, but for any image dragged direct from the Media Pool (which is already distinguished by Resolve, giving a different variant of MediaIn with frame length controls ) I can't see why it couldn't be cached.


If you view an image in the source viewer on the Edit page you can still scrub through it like a clip. You can also create annotations at different points and each will have it's own time stamp from 00:00:00:000 to 00:00:00:001. So really it's just a very short clip that's one frame long.

Also it's not giving you a different version of the MediaIn. It's the same MediaIn it's just showing you different parameters because they're linked to something different.

Add an image to a timeline, then go into that clip's composition and import that same image into the composition via the Media Pool. Check the properties of both. They both look the same but MediaIn2 shows an identifier in the Media ID field but MediaIn1 is blank. Now drag in some unrelated media. It could be a video or a still, it doesn't matter. Now go to it's MediaID and clear it. It will now show the same output as MediaIn1.

This is because MediaIns you dragged into the composition are pre-linked to media that's external to the composition but local to the project. MediaIns that are blank are just referring to the thing that directly preceded the composition's processing which, since this is an effect composition, is the clip it's attached to.

Adding a blank MediaIn to a Fusion Composition clip doesn't do anything because it is it's own clip. Come to think of it, they could just make a MediaIns behaviour in a Fusion Composition just work like an Adjustment Clip. Then they could combine the Adjustment Clip and Fusion Composition objects.
Offline

Videoneth

  • Posts: 1615
  • Joined: Fri Nov 13, 2020 11:03 pm
  • Warnings: 1
  • Real Name: Maxwell Allington

Re: Fusion page: Major performance issue with MediaIn v Load

PostFri Jan 28, 2022 2:41 pm

I used the term "bug" because I don't know anything about the code behind it. So for the general public, it "looks like" a bug. Maybe it's a design flaw, maybe not.

Maybe I missed something (the discussion is interesting anyway), but at the end of the day, the difference of perfs between a loader and something coming from the media pool is not documented anywhere.

I can only talk for myself, but I struggled a lot of last year with very poor performances. Trying to animate pictures, with effects on top of it.

Now it's more enjoyable to work with Fusion in Resolve, even with a 3090 I see the difference.

At the end of the day, it would be nice to get the performances of Fusion in Resolve closer to Fusion standalone.
Windows 10
18.6.6
nVidia 3090 - 537.42
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostSat Jan 29, 2022 12:56 am

Maxwellx wrote:Maybe I missed something (the discussion is interesting anyway), but at the end of the day, the difference of perfs between a loader and something coming from the media pool is not documented anywhere.


That's correct. The documentation on the MediaIn node is very unclear. The only note that really even infers that it's different from the Loader node is where it says "NOTE: Although a MediaIn tool is located in the I/O section of the Effects Library, it is not used as a method to import clips."

Maxwellx wrote:At the end of the day, it would be nice to get the performances of Fusion in Resolve closer to Fusion standalone.


I whole-heartedly agree, though I'd like them to go a step further and make it so that the stand-alone version of Fusion won't have a purpose any more and they're going to have to restructure a lot to do that now.

They need to take Fusion compositions out the project file . Then they need to treat them as re-usable assets hroughout the project that can be modified with exposed settings from each composition. Stuff like Fusion Clips and the default Fusion Effects on every clip in the timeline serve no real purpose and the Fusion page shouldn't be treated as the Color page's advanced mode.

That would allow someone who just wants to use Fusion to set that Fusion page to their default, hide the bottom bar, and use it just like stand-alone Fusion. No need to have a project open. They could make any Fusion Effects Titles, Transitions, Clips, or anything without needing to know anything about the project. But if they did want to modify a composition in the context of a timeline, they could just open a project, set a position on the timeline, and add a MediaIn to the composition that sees through to the timeline just like an Adjustment Clip.

It's less complex, it requires less repeated work, it's safer, it's easier to understand, and you aren't losing any features.
Offline
User avatar

Paul R. Williams

  • Posts: 96
  • Joined: Fri Mar 21, 2014 10:51 am
  • Location: Frankfurt am Main, Germany

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Feb 08, 2022 10:03 am

This excellent thread illustrates the large processing delays when using MediaIn versus Loader nodes.
I have a composition where I used a Saver node to "cache" an intermediate result. Using a Loader node to continue the processing worked fine. In a different fusion composition starting with the .exr sequence imported into the media pool and added to a timeline, the MediaIn node consumed memory to the extent that Resolve crashed the system.
NOTE: Within Resolve Fusion the Saver will only export .exr files! Because the original media was 4K this requires plenty of (fast SSD) storage.
Paul R. Williams
    BMPC4K, URSA EF 4K, URSA Mini Pro 4.6K (EF/PL), BMPCC 6K Pro
    SanDisk SSDs & Lexar CFast & Samsung T5 & T7
    SmallRig rigging elements
    iMacPro (2017) 3.2 GHz Intel Xeon W/32 GB/Radeon Pro Vega 64 16 GB
Offline

Beace88

  • Posts: 9
  • Joined: Wed Jun 29, 2022 3:48 pm
  • Real Name: Zach Chase

Re: Fusion page: Major performance issue with MediaIn v Load

PostThu Jun 30, 2022 7:48 pm

Wow, I have to say this saved me in a big way. I have been racking my brain over this last week trying to figure out why the hell my latest fusion comp with about 7-8 6240 x 3512 images was taking an hour to render about 15 seconds, and many times crashing. I had just posted a thread about this, thinking it was some effect I added or some result of a faulty node tree. I haven't actually applied all of the loaders to update the video yet, but I feel that I finally have a worthwhile solution, and a way to speed up my entire video by replacing any MediaIn's with Loaders.

Thanks so much for opening this discussion because I literally have scoured the internet and have not found anything to help explain this issue. I feel that if it's not going to be fixed soon, it needs to be pinned to the top of the forum, or something of that nature. The reality is, most people are likely to be using images in some form in their comps, and for the render to be slowed down that badly is critical.
Offline

Videoneth

  • Posts: 1615
  • Joined: Fri Nov 13, 2020 11:03 pm
  • Warnings: 1
  • Real Name: Maxwell Allington

Re: Fusion page: Major performance issue with MediaIn v Load

PostSat Jul 02, 2022 2:08 pm

TheBloke, did you saw a difference with the v. 18?
Windows 10
18.6.6
nVidia 3090 - 537.42
Offline

Ilkka Rosma

  • Posts: 10
  • Joined: Sat Jun 17, 2017 5:01 pm

Re: Fusion page: Major performance issue with MediaIn v Load

PostSun Oct 16, 2022 11:40 pm

Yep, thanks a bunch from me too. The laggy performance was driving me up the wall. Replacing the MediaIn nodes with Loaders finally restored my sanity. Apparently this also means v18 didn’t bring about much change in this regard.
Offline
User avatar

Sean Nelson

  • Posts: 758
  • Joined: Sun Feb 07, 2021 9:48 pm
  • Location: Vancouver, Canada
  • Real Name: Sean Nelson

Re: Fusion page: Major performance issue with MediaIn v Load

PostMon Oct 17, 2022 1:37 am

It seems that a common stumbling block in Fusion is the use of images of much higher resolution than they really need to be. If you've got several 6240 x 3512 images and you're bringing them into an HD project, you end up wasting a huge amount of space. Resolve processes pixels as 32-bit floating-point numbers, one for each of 4 channels of each pixel - so a 6240 x 3512 image consumes 350 MBytes of storage. Compare that to an image which has been pre-scaled to HD size before being loaded into Fusion which takes only about 1/10th as much storage.

And then with a node tree of several stages the amount of data is multiplied again, and it doesn't take very long to exhaust video ram, which means Resolve has to keep swapping image data in and out as it performs the processing for all of the nodes in the tree.

I don't know the technical details of Loader vs. Media In, but given the performance difference I suspect what's happening is that image data being delivered to Fusion as Media In has already been pre-scaled to the resolution of the timeline, while Loader media comes in "as is". That would certainly explain a lot of the performance difference for large images. If that's true, I suspect the answer would be to pre-scale the images to the size needed for the composition.
DR Studio 18.6.4 Build 6, Win10Pro x64 22H2/19045.3570
Asus C246 Pro Motherboard, Xeon E-2278G@3.4GHz, 64GB ECC RAM
GeForce 3060 12GB, "Studio" driver 512.15
OS,Library: 1TB NVMe SSD - Project,Cache: 1TB NVMe SSD
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Nov 09, 2022 4:23 am

Sean Nelson wrote:It seems that a common stumbling block in Fusion is the use of images of much higher resolution than they really need to be. If you've got several 6240 x 3512 images and you're bringing them into an HD project, you end up wasting a huge amount of space. Resolve processes pixels as 32-bit floating-point numbers, one for each of 4 channels of each pixel - so a 6240 x 3512 image consumes 350 MBytes of storage. Compare that to an image which has been pre-scaled to HD size before being loaded into Fusion which takes only about 1/10th as much storage.


If a 6240 x 3512 image, I'm assuming you mean still image, is brought into Fusion via a loader then it will use 88-175 MB of RAM because it'll be brought in as either 8bpc or 16bpc and the same frame will be re-used . If you bring it via a MediaIn from the Media Pool then it will be 32bpc, it'll still be the same resolution, and it'll be converted to a video. In other words it would use at least 350 MB. If the clip is 10 seconds at 24 fps then that MediaIn would use 350 MB x 24 fps x 10 seconds... or 85GBs while the Loader will still use 88-175MB in all.

The only time that a MediaIn is pre-scaled is if you convert a clip or clips into a Fusion Clip. That's because the MediaIns aren't pointing to clips, they're pointing to tracks within the Fusion Clip. The Fusion clip is just a special kind of Compound Clip. So doing that will lower the resolution of the image but it will still take up 31MB x 24fps x 10 seconds which is 7.4GB

Sean Nelson wrote:I don't know the technical details of Loader vs. Media In, but given the performance difference I suspect what's happening is that image data being delivered to Fusion as Media In has already been pre-scaled to the resolution of the timeline, while Loader media comes in "as is". That would certainly explain a lot of the performance difference for large images. If that's true, I suspect the answer would be to pre-scale the images to the size needed for the composition.


A Loader directly accesses the file from disk.

A MediaIn is basically a video stream from processing stage in Resolve's image processing pipeline. That's why there isn't as much of a difference between a MediaIn and Loader when they're both dealing with video. A loader actually supports still images and video while a MediaIn only supports video.
Offline

TheRealTomHM

  • Posts: 3
  • Joined: Fri Jan 13, 2023 12:13 pm
  • Real Name: Tom Holder

Re: Fusion page: Major performance issue with MediaIn v Load

PostTue Jan 17, 2023 5:42 pm

Sean Nelson wrote:It seems that a common stumbling block in Fusion is the use of images of much higher resolution than they really need to be. If you've got several 6240 x 3512 images and you're bringing them into an HD project, you end up wasting a huge amount of space.


I guess it depends on what you're trying to achieve with these images. For me, I needed images at a higher resolution than the timeline as I was creating a composition where I was zooming in and out.
Offline
User avatar

Sean Nelson

  • Posts: 758
  • Joined: Sun Feb 07, 2021 9:48 pm
  • Location: Vancouver, Canada
  • Real Name: Sean Nelson

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Jan 18, 2023 9:57 pm

TheRealTomHM wrote:
Sean Nelson wrote:I guess it depends on what you're trying to achieve with these images. For me, I needed images at a higher resolution than the timeline as I was creating a composition where I was zooming in and out.

Nothing wrong with that. It's just that some folks just grab an image and drop it into the composition without stopping to think about resolution, and in some cases with high resolution cameras that can create a huge amount of data that Resolve has to sling around - especially if there are effects being applied to the pipeline that the image is part of.
DR Studio 18.6.4 Build 6, Win10Pro x64 22H2/19045.3570
Asus C246 Pro Motherboard, Xeon E-2278G@3.4GHz, 64GB ECC RAM
GeForce 3060 12GB, "Studio" driver 512.15
OS,Library: 1TB NVMe SSD - Project,Cache: 1TB NVMe SSD
Offline

Videoneth

  • Posts: 1615
  • Joined: Fri Nov 13, 2020 11:03 pm
  • Warnings: 1
  • Real Name: Maxwell Allington

Re: Fusion page: Major performance issue with MediaIn v Load

PostWed Jan 18, 2023 11:23 pm

I'm curious, did something changed?
Or using a loader is still the way to go?
Windows 10
18.6.6
nVidia 3090 - 537.42
Next

Return to DaVinci Resolve

Who is online

Users browsing this forum: bbqrooster, kb888bk, RedRider14 and 160 guests