Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Stop-start staccato rendering in Resolve

H

Hywel Phillips

Well-known member
Joined
Nov 14, 2010
Messages
75
Reaction score
0
Points
0
Hi All,

I just bought and kitted out a refurb MacPro (I need to get work done and can't wait for new one from Apple). It runs Resolve significantly quicker than my old one, but I've noticed that the rendering is very staccato. I don't have a RED Rocket yet as it would have cost as much as the base MacPro, and I need to do more than just transcode RED footage on the Mac so had to concentrate on general processing power.

It renders a short burst of frames, then hesitates, then renders a short burst, then hesitates. The FPS goes something like
4.5 - 2.5 - 0.0 - 4.5 - 2.5 - 0.0

Does anyone have an idea why this might be? It isn't a complaint, the stuff is transcoding much faster than it used to, but there's obviously some bottleneck somewhere and I'd just like to understand what the limiting factor might be.

MacPro 5,1 12 core 2.93 GHz, 48 GB RAM, OS X 10.8.2, Radeon 5870 (GUI, slot 1), Quadro 4000 Mac (Render, slot 2. Run from a power splitter but seems to be OK), Resolve lite 9.0.1, 4K HD or 3K HD Scarlet 25 fps 6:1 footage. Read from and written to a software RAID 0 striped 2 x 512 GB SSD, separate SSD Boot drive and RAID 1 2 x 4 TB storage drives, not being used in this workflow. Output is 1920 x 1080 25 fps ProRes 422 HQ, debayer and resample set to max quality in the Resolve deliver pane.

CPU use runs at about 70%, which is pretty good over 24 cores (monitor shows the second one in each pair to be less highly used- suppose that means hyperthreading isn't working as well as it might on some tasks). RAM usage is only about half.

I don't understand why some frames would be slower to render than the one immediately before. My best guess is because it is filling up some fast memory (GPU VRAM?) and having to dump it back out and read fresh data in every few frames?

Anyone got any thoughts?

Hywel.
 
I understand that without RED Rocket I'm not going to get much faster- but I was wondering what causes the rendering to proceed in fits and starts like that. I'd naively have assumed that the system would settle down and process frames at a steady rate, which it doesn't- it processes several frames in quick succession over the course of a second or two, then doesn't process any for a second or two, and so on. Since the REDcode RAW files don't use inter-frame compression as far as I know, I don't understand why the system doesn't settle down to process at a steady speed.

These are not complex grades BTW- some basic settings in the RED decoding, plus a little tweak of curves and levels, an oval power window with curves to produce a vignette, and maybe a few tweaks to saturation vs luma. No more than three nodes and none of them doing anything hugely complex.

Cheers, Hywel.
 
Hywel Phillips said:
Resolve lite 9.0.1, 4K HD or 3K HD Scarlet 25 fps 6:1 footage. Read from and written to a software RAID 0 striped 2 x 512 GB SSD, separate SSD Boot drive and RAID 1 2 x 4 TB storage drives, not being used in this workflow. Output is 1920 x 1080 25 fps ProRes 422 HQ, debayer and resample set to max quality in the Resolve deliver pane.
Click to expand...
If the final result is going to be 1920x1080, why not just work in 2K DPX log? I've done that quite often for Resolve-based projects, and it runs very well. It's still not quite real time during the final render (and we do have a second GPU), but it typically doesn't take more than 130% or 140% of run time, maybe 90 minutes for a 1-hour show. And I've definitely had up to 9 or 10 nodes on certain complex shots.

We've also done 444 HQ ProRes for certain reality projects, and those look fine (to me, anyway). The footage came from a mixture of sources, so when you've got Red, Sony, and 7D all in the same scene, any talk of stick with R3D's kind of goes out the window. Budgetary factors require us to get the show done in 8-10 hours, so the workflow has to be compressed in order to fit the client's available schedule.

Note also that the full version of Resolve provides more options (and one would assume faster performance).
 
I've seen this variable render speed on R3d. Not too concerned about it though as long as it doesn't fail. You might want to try a single gtx 570 2.5 gb instead of the 4000/5870. They're only about $320 online, and you'll save a pci slot and probably get better performance. That power splitter is a dicey solution...
 
Yeh, the 5870/4000 combo was unplanned. I ordered a refurb MacPro which was supposed to have come with a 5770, but the one that arrived had a 5870 in the slot. And hence no spare power connector for the 4000. Shrug. I figured the way I use the machine, probably only one of the two cards is going to be running at full chat at a time- if I'm rendering in Resolve I basically shut the screen down and go away for a couple of hours while it chugs through.

As for working in 2K DPX log, it doesn't fit the rest of my workflow, which is round trip to FCPX. Hence the decision to stick to ProRes throughout.

But I will look at a 570 gtx when I've paid off the credit card bill from the Mac :-)

Cheers, Hywel.
 
rather than keeping the 5870, sell that too, and get the previous ATI model (can't remember which number) that uses only a single power rail. I'm sure you can pick it up for pocket change. That way you'll have the GUI & GPU cards separate, but also not using more power than your mac pro is designed for.
 
Just for fun, try to render as Single Clip (used to be called Target). I realize it's not an option for you, but at least you will see if writing individual source clips is the problem.
 
You must log in or register to reply here.
Back
Top