Jump to: Board index » General » Fusion

Multi-GPU & CPU?

Learn about 3D compositing, animation, broadcast design and VFX workflows.
  • Author
  • Message
Offline

Rick Tillery

  • Posts: 30
  • Joined: Sat Nov 14, 2015 4:57 pm
  • Location: TX

Multi-GPU & CPU?

PostSat Apr 30, 2016 11:13 pm

Two questions:

1. If I configure a machine with a mobo (Intel) GPU and an add-in (AMD) GPU to use the mobo GPU for the display, will Fusion (and Resolve) use the add-in GPU for rendering? I realize it's not recommended to use two different brands of GPUs, so I'm not asking for that, but I'm assuming this will give better rendering and/or memory performance for the add-in GPU, since it's not dealing with the display (at least 500 MB/s bandwidth just for screen refresh).

2. How do I get Fusion to use the CPU in addition to the GPU for rendering frames? It's just sitting idle. I tried a bunch of settings in the OpenCL entry of Global Settings, but nothing seems to activate the CPU, even if I choose just the CPU. (Of course, I'm not certain whether I have to do something more than pause and resume a rendering to see the changes.)

Thanks,
Rick
Offline
User avatar

Chad Capeland

  • Posts: 2531
  • Joined: Mon Nov 10, 2014 9:40 pm

Re: Multi-GPU & CPU?

PostSat Apr 30, 2016 11:55 pm

You get one OpenCL processor and one OpenGL processor. The OpenGL processor runs the UI and all GL rendering. Future versions of Fusion could add support for multiple OpenCL and multiple OpenGL processors, but currently it does not.

Less than 3% of tools use OpenCL, so I wouldn't worry about it too much. Simultaneous branching will help some, as will background rendering.
Chad Capeland
Indicated, LLC
www.floweffects.com
Offline

Rick Tillery

  • Posts: 30
  • Joined: Sat Nov 14, 2015 4:57 pm
  • Location: TX

Re: Multi-GPU & CPU?

PostSun May 01, 2016 12:23 am

Chad Capeland wrote:You get one OpenCL processor and one OpenGL processor.
So I assume that means I can't use the CPU & GPU simultaneously. What about offloading the display to the mobo GPU and using only the add-in for OpenCL/OpenGL rendering? Is that possible?

Simultaneous branching will help some, as will background rendering.
I found the setting for simultaneous branching, but that didn't seem to help much. I don't see the background rendering setting in the manual. Where's that one?

Rick
Offline

Rick Tillery

  • Posts: 30
  • Joined: Sat Nov 14, 2015 4:57 pm
  • Location: TX

Re: Multi-GPU & CPU?

PostSun May 01, 2016 12:44 am

I'm seeing some conflicting information, so let me be specific:

I have a comp that consists of a FHD input with two merges in series with two different PNG bitmaps. It's that simple:
Code: Select all
          rectangle
          |      |
          v      v
VID -> merge -> merge -> SAVER
         ^        ^
         |        |
       curves   curves
         ^        ^
         |        |
        PNG      PNG


Yet, it's rendering on a 16 GB i7-4770 + 4 GB AMD R7 370 at 1.4 fps, even though the CPU barely hits 15%.

That's where I was with the two questions.

But now I can add that I downloaded an AMD System Monitor, and it shows not a blip on the GPU. Is the GPU really not used for anything?

Rick
Offline
User avatar

Chad Capeland

  • Posts: 2531
  • Joined: Mon Nov 10, 2014 9:40 pm

Re: Multi-GPU & CPU?

PostSun May 01, 2016 12:50 am

Your comp is I/O bound.

Nothing in your comp will use the GPU at all, but that's OK, as even on the CPU it would run at 100+fps.

You cannot use one GPU for OpenGL rendering and another for UI. That would introduce a lot of latency. It's POSSIBLE to have 3Rn use multiple GPU's because of the nature of it's tile rendering, but it doesn't.

Background rendering is enabled from the File menu.
Chad Capeland
Indicated, LLC
www.floweffects.com
Offline

Rick Tillery

  • Posts: 30
  • Joined: Sat Nov 14, 2015 4:57 pm
  • Location: TX

Re: Multi-GPU & CPU?

PostSun May 01, 2016 3:20 am

Chad Capeland wrote:Your comp is I/O bound.
Could you explain why you think that? It reads from one file and writes to one. The PNG files don't change, so there should be no i/o for them after the first frame.
Nothing in your comp will use the GPU at all, but that's OK, as even on the CPU it would run at 100+fps.
:o Alpha blending isn't even GPU accelerated!? Color curves don't use the GPU? That's shocking. Even my minimal knowledge of shaders could create those two operations in a few minutes.

I didn't think about how slow the mp4 decoding was in Fusion, even in the editor. I only get a few frames per second playing there which, coupled with JPEG2000 compression on the output when rendering, probably explains the speed. And the CPU isn't any higher (~15%) then either. Given that Resolve is much faster (able to handle 24 fps at full speed with ~20% CPU), I'd say they need to copy the mp4 decoder from Resolve to Fusion :D

With what source and destination formats would you expect to see 100 fps in Fusion, while maintaining minimal degradation?
You cannot use one GPU for OpenGL rendering and another for UI. That would introduce a lot of latency.
Hmm. I see that might be an issue if the UI is using the GPU (I thought I read that it uses OpenGL for the 3D there). But for the final render, I would think the ability to pipeline frames would far outweigh the transfer overhead.
It's POSSIBLE to have 3Rn use multiple GPU's because of the nature of it's tile rendering, but it doesn't.
Not sure what 3Rn is.
Background rendering is enabled from the File menu.
Thanks, I'll give that a try next time.

Rick
Offline
User avatar

Chad Capeland

  • Posts: 2531
  • Joined: Mon Nov 10, 2014 9:40 pm

Re: Multi-GPU & CPU?

PostSun May 01, 2016 4:34 am

Rick Tillery wrote:
Chad Capeland wrote:Your comp is I/O bound.
Could you explain why you think that? It reads from one file and writes to one. The PNG files don't change, so there should be no i/o for them after the first frame.


Remove the LD and SV and your comp will speed up nicely. They're what is killing performance.

Rick Tillery wrote: Alpha blending isn't even GPU accelerated!? Color curves don't use the GPU? That's shocking. Even my minimal knowledge of shaders could create those two operations in a few minutes.


Check out https://indicated.co/blackmagic-fusion-plugins/. The shaders there are quite fast. Can do 16k float footage at 60fps with dozens of nodes. Considerably faster than Resolve, even. If you want to make your own shaders, check out CustomShader3D.

Rick Tillery wrote:I didn't think about how slow the mp4 decoding was in Fusion, even in the editor. I only get a few frames per second playing there which, coupled with JPEG2000 compression on the output when rendering, probably explains the speed. And the CPU isn't any higher (~15%) then either. Given that Resolve is much faster (able to handle 24 fps at full speed with ~20% CPU), I'd say they need to copy the mp4 decoder from Resolve to Fusion :D


Fusion uses standard codecs. That's not the issue. Rather it's that each image is independent. No assumption is made about the order of requests. That means no pipelining either. That's fundamental to how Fusion works and why it scales better than Resolve. You can't copy that from Resolve, as it would break what works so well in Fusion. Can Fusion improve I/O? Sure. You can demonstrate that with plugins that do I/O with pipelining. But tradeoffs exist and ease of use and scalability has been prioritized over performance in this case. Understand, as well, that your comp is atypical. Very simple comps like that rarely run locally. Most comps will be much more complex and fast I/O will be less important.

Rick Tillery wrote:I see that might be an issue if the UI is using the GPU (I thought I read that it uses OpenGL for the 3D there). But for the final render, I would think the ability to pipeline frames would far outweigh the transfer overhead.

WYSIWYG. Fusion doesn't use a concept of "final render". It's very precise and predictable because of that. It's also a lot easier to use. There's still opportunities for multiple GPUs for OpenGL and OpenCL rendering, of course, and it would be great to see those developed, but it's still most likely that a single GPU would do all the UI and viewers.

Fun aside, the Mac Pro is only sold in multi GPU configurations, but Apple/OSX doesn't support multi GPU OpenGL applications. The second GPU can only be used for OpenCL.
Chad Capeland
Indicated, LLC
www.floweffects.com
Offline

Rick Tillery

  • Posts: 30
  • Joined: Sat Nov 14, 2015 4:57 pm
  • Location: TX

Re: Multi-GPU & CPU?

PostSun May 01, 2016 6:42 am

Chad Capeland wrote:Remove the LD and SV and your comp will speed up nicely. They're what is killing performance.
If you remove the loader and saver, you also remove the decode and encode. Given that the hard drive isn't max'ed out either (judging by the LED), it doesn't seem to be I/O bound, unless you mean memory throughput rather than storage.
Rick Tillery wrote: Alpha blending isn't even GPU accelerated!? Color curves don't use the GPU? That's shocking. Even my minimal knowledge of shaders could create those two operations in a few minutes.
Check out https://indicated.co/blackmagic-fusion-plugins/. The shaders there are quite fast. Can do 16k float footage at 60fps with dozens of nodes. Considerably faster than Resolve, even. If you want to make your own shaders, check out CustomShader3D.
All would be nice, but I guess I'll have to take your word for it, since that doesn't work with free Fusion, right?
Rick Tillery wrote:I didn't think about how slow the mp4 decoding was in Fusion, even in the editor. I only get a few frames per second playing there which, coupled with JPEG2000 compression on the output when rendering, probably explains the speed. And the CPU isn't any higher (~15%) then either. Given that Resolve is much faster (able to handle 24 fps at full speed with ~20% CPU), I'd say they need to copy the mp4 decoder from Resolve to Fusion :D

Fusion uses standard codecs. That's not the issue. Rather it's that each image is independent. No assumption is made about the order of requests. That means no pipelining either. That's fundamental to how Fusion works and why it scales better than Resolve. You can't copy that from Resolve, as it would break what works so well in Fusion.
You certainly know more about these products that I do, but I do have a bit of experience with this type of CODEC, and similar types of limitations at the hardware (RAM) level (i.e. systems where a single access has high overhead, while subsequent accesses have much reduced penalties). Any design that makes completely independent accesses to such a stream is fundamentally flawed when dealing with interframe CODECs like MPEG. That might explain the push for intraframe-only CODECs...except, I converted the video to DNxHD, which is all intraframe, and got essentially the same speed. Again, CPU very lightly used, and HD not being taxed.

Interesting discussion. It really makes me wish I could go back to working on video processing and editors as I did a number of years ago. (http://graphics.github.io/bltsville/) Too bad I can't get such a job locally any more.

Rick

Return to Fusion

Who is online

Users browsing this forum: No registered users and 3 guests