General Setup Inquires: RED Workflows (Mac)

Hi,

New here and to Resolve. Done a good amount of forum searching and web searching the last few days to find definitive answers, as well as testing various setups myself with different systems, drives, preferences, project files. Still have not nailed down the source of my problems but I believe the following things are true for 14.1.x and 14.3. Please correct me if I'm mistaken:

Preferences
• Use Display For GPU Compute is no longer an option (i.e. guide needs updating)

• Use GPU for RED Debayer is no longer an option (done automatically, guide needs updating)

• RED Debayering is NOT CUDA-dependent; it works equally well in Metal

• If both GPUs in a trashcan Mac are selected in prefs, anything that CAN use them will...

Workflow
• ...if you see all CPU cores slammed during playback (Activity Monitor), it's the result of decompression not debayering.

• Even the fastest 4-core i7 and 6-core i7 / Xeon parts are not fast enough to keep up with 4K+ RED files (compression bottleneck).

• The way to know you're attempting to play back raw footage and not optimized media or proxy media, is to disable Playback > Use Optimized Media if Available. This does not disable the creation of optimized media (which is generated based on project settings and going into the cache location), it only disables its playback.

• No plugins or other software from RED are required to be installed before you attempt RED workflows (workflows that utilize LUTs not withstanding).

• If your internal system SSD can handle 1000MB/s+ Read/Write, it's not a problem to house the database, cache and everything else locally when working in Resolve. Not like Premiere where you need to break out the media and cache into fast RAID drives, etc.

• 16GB RAM dedicated to Resolve is sufficient for a 4K RED workflow.

Thanks!

*bump*

Man this forum scrolls fast!

If any of you who regularly work with RED and/or 4K raw footage could take a look at the assumptions posted above and let me know if and where I've missed the mark, I'd appreciate it. Relatively new to film production in general and more familiar with Premiere and After Effects than I am Resolve.

Spent a good amount of time in documentation and forums before posting but want to make sure I have the big picture correct before I go making investments (time or money).

[Dwaine Maggart]

• RED Debayering is NOT CUDA-dependent; it works equally well in Metal

Not correct. Red debayering is not supported in Metal. If Metal GPU mode is selected, Red reverts to CPU debayering.

• If both GPUs in a trashcan Mac are selected in prefs, anything that CAN use them will...

Both GPU's are always used in 6,1 MacPro's even with free Resolve.


• No plugins or other software from RED are required to be installed before you attempt RED workflows (workflows that utilize LUTs not withstanding).

Correct

• RED Debayering is NOT CUDA-dependent; it works equally well in Metal

Not correct. Red debayering is not supported in Metal. If Metal GPU mode is selected, Red reverts to CPU debayering.

• If both GPUs in a trashcan Mac are selected in prefs, anything that CAN use them will...

Both GPU's are always used in 6,1 MacPro's even with free Resolve.


• No plugins or other software from RED are required to be installed before you attempt RED workflows (workflows that utilize LUTs not withstanding).

Correct

Thank you for taking a read and answering a couple of my questions, Dwaine!

Re: debayering process. OK so no metal... also no OpenCL? It's possible I don't have something set up right but even bringing in a 4K 24 FPS RED clip and trying to preview it in the media pool (no FX, etc) or in a simple timeline, doesn't result in anything close to RT playback. More like 12 FPS on avg. My assumption is that my AMD GPU is the problem. I was using Metal because I couldn't even preview the file in general when it was set to OpenCL in prefs. Previewing in Metal does seem to work so I went with that but the speeds aren't there.

Preferences / Manual: having checked today's manual update for 14.3, and given that the first two options I inquired about are still shown, the only conclusion I can reach is these are Studio-only prefs, and that this is the convention used throughout for screenshots. (BTW I'm using the Mac App Store free version of 14.3 but the manual from your web site, if that makes a difference.) If the screenshots are all from Studio I think it's important to set up some kind of visual key throughout the manual to denote when something will look different in the free version / App Store version. I looked again to see if there was something from the manual intro talking about this but I didn't see anything.

Re Workflow and CPUs: going to assume 4-core i7 in laptop is not going to cut it for RED workflow, that regardless of GPU (for example if I had an eGPU installed to work around my AMD situation), the CPUs handle decompression and for RED you need something more than 4 cores to get RT playback. That or transcode to ProRes or equivalent first (i.e. give up on RAW workflow until workstation hardware is available).

Re: RAM: found the answer to this after I posted (sounds like assigning more than 12GB is pointless).

Thanks again!

Re Workflow and CPUs: going to assume 4-core i7 in laptop is not going to cut it for RED workflow, that regardless of GPU (for example if I had an eGPU installed to work around my AMD situation), the CPUs handle decompression and for RED you need something more than 4 cores to get RT playback. That or transcode to ProRes or equivalent first (i.e. give up on RAW workflow until workstation hardware is available).

Re: RAM: found the answer to this after I posted (sounds like assigning more than 12GB is pointless).

Thanks again!

Resolve will use as much RAM as it needs, and can certainly use more than 12GB.

As for your i7 laptop, I think it should be capable of cutting Red footage if you are willing to lower debayer quality and/or timeline resolution, or create optimized media. I find DNxHR SQX at half resolution to be great for 4K material.

[Dwaine Maggart]

Thanks for pointing out the new manual. I hadn't seen that it was posted.

Re: debayering process. OpenCL is fine, when other parties haven't messed it up. In macOS 10.13.2 and 10.13.3, it's messed up and does not work. This should be addressed in 10.13.4. Resolve 14.3 addresses some of the issues and should be tried, but full fix requires macOS 10.13.4.

So, for people on MacPro 6,1 systems, and MBP and iMacs using AMD, if you have updated to 10.13.2 or 10.13.3, and prior to Resolve 14.3, you had to select Metal GPU mode to force Resolve to use CPU debayering. New iMac Pro Vega GPU's are not affected by this issue.

Hopefully all the Red Mac OpenCL debayering issues are behind us when 10.13.4 is released.

Preferences / Manual:The Use GPU for Red Debayer is not Studio specific. The manual update missed catching this. The ability to manually select to use GPU for Red Debayer has been removed.

The Use Display GPU for Compute is Studio specific. You can't have multiple GPUs in the free version, so you don't need the checkbox. If you have only one GPU, it gets used for both.

Re Workflow and CPUs: If you don't have a Red Rocket-X card, CPU's are used to decompress Red footage. For large format codecs, you need lots of CPU cores for Premium Decode with real time playback. Likely more than you can afford. If you do lots of Helium 8K work, and you need real time playback performance at Premium decode modes, it makes sense to get the Rocket-X, even though it can't debayer that type of footage. Note that you would not use a MacPro 6,1 or iMac or MBP for this type of work.

Peter: that was my thought also and initially allocated 16GB on a 32GB machine. But then I read this on page 86 of the guide: "Workstations with enormous amounts of RAM available (64 to 128GB for example), may find it desirable to raise this cap [from the default of 4000] in order to improve performance when rendering [anything higher than 4K resolution] clips, although the maximum recommended pre-allocation is 12GB of RAM."

Possibly I misinterpreted the bold part but I took that to mean "you can assign more than 12GB if you want to but it won't help." But intuitively, what you're saying makes more sense based on my prior experiences with other apps like Photoshop and Premiere Pro.

Dwaine: thank you for the additional information. I am indeed on 10.13.3 so that makes sense that I'm not seeing any benefit from the dual GPUs in the 6,1 testbed. Look forward to 10.13.4 as there are some major eGPU support improvements appearing in the betas for that OS already.

Re: Use GPU for Red Debayer, the only options I see under Configure Hardware are:

Pre-allocated system memory
Use Mac Display Color Profiles...
Use 10-bit precision in viewers...
GPU Processing mode

So given your point it's expected I wouldn't see Use GPU for Red Debayer (removed entirely), or Use Display for GPU Compute (studio only). Use Red Rocket if available is missing too but I have no plans to buy one of those given how infrequently they're updated and how expensive they are.

That said it sounds like the ideal setup is either a high-core-count CPU (like a top-end ThreadRipper setup for decompress) and two high-end GPUs (debayering), or, a standard issue 6-, 8-, 12-core CPU, a RED Rocket card (decompress stage) and two high-end GPUs (debayering). For my purposes in the short term I'm not too concerned about anything beyond RED 2K, 4K, some 5K. And both raw and ProRes transcoded workflows would be an option. I just hope to understand the base requirements for doing a raw workflow right if needed. I would only work with 6K or 8K for proof-of-concept workflows for testing and certainly NOT raw, at those resolutions. Isn't practical or even useful in the scenarios we're envisioning.

Machines I'm experimenting with right now are 6,1 and 2017 MBP but also have a desktop PC with M.2 drives, high-end GPU, higher core-count CPU. So far it's easily been the best performer but partly I asked these questions to ensure I wasn't further hobbling the Mac performance because something was set up wrong. Ultimately will include new Mac Pro among our options but who knows what that will look like.

Thanks again for the info!

Pre-allocated memory is just that, pre-allocated. Resolve will use more than that amount if it feels like it needs to and the memory is available (i.e. not being used by other programs or the kernel).

As for Threadripper, personally I'd go with an Intel CPU with nVidia GPU. It just seems to be the standard. But do be congizant of how many PCIe lanes the system has. If you are going to run multiple GPUs, you may need quite a few lanes.

The two top-end Intel i9 chips are technically faster than the top end Threadripper, but IMO it's sort of pointless - both will handle 4K RED RAW easily, but neither will handle 6K or 8K that well.

Thanks for pointing out the new manual. I hadn't seen that it was posted.

Re: debayering process. OpenCL is fine, when other parties haven't messed it up. In macOS 10.13.2 and 10.13.3, it's messed up and does not work. This should be addressed in 10.13.4. Resolve 14.3 addresses some of the issues and should be tried, but full fix requires macOS 10.13.4.

Thread bump...

Dwaine / others, any idea if the hoped-for OpenCL debayering fixes made it into 10.13.4? In preliminary tests with multiple AMD GPU configs, I'm only seeing small differences in frame rate for R3D playback vs. CPU-bound debayering. [Based on what I've read elsewhere I have a feeling the lackluster performance boosts I am seeing are related to the fact these are AMD GPUs / using OpenCL and not CUDA.]

Related: now that dual GPUs are supported on both macOS 10.13.4 and in Resolve Studio... is there any requirement in a single single display config to have either of the accelerators driving the screen, so long as they're selected in preferences and the app restarted? I'm assuming, since you can only have one GPU driving whichever screen has the timeline viewer, and that the app supports 2 or more GPUs (external or not), that the non-connected GPUs are still assisting in the playback / transcoding / whatever you're attempting. Is that accurate?

[Dwaine Maggart]

macOS 10.13.4 now works with Red OpenCL debayering.

I'm not aware that we've done any testing yet with eGPU Mac systems.

It's on my list of things to look into, in my spare time.

macOS 10.13.4 now works with Red OpenCL debayering.

I'm not aware that we've done any testing yet with eGPU Mac systems.

It's on my list of things to look into, in my spare time.

Thanks for the reply Dwaine. Presumably if the app recognizes the card installed in the eGPU and allows it to be selected in preferences, and the card's fan spins up at points during operation (even if not driving a screen), that would suggest Resolve is utilizing said card, correct?

[Update: based on GPU and CPU history meters, all OpenCL debayering and playback, as well as transcoding, happens on the CPUs. Even the internal GPU is idle throughout, although during playback I see what looks like a roughly 90/10 split between CPU and internal GPU. eGPUs are idle the entire time regardless of process. Playback of optimized footage however, seems to utilize all AMD GPUs, internal or external, active in preferences or not (strangely).

Not sure if that would be true with a CUDA card because they don't current work on macOS. Also unclear if v15 beta might offer some additional GPU processing power in these areas.]

[Dwaine Maggart]

In Resolve 14.1, we removed the ability to manually force Red Debayering to use CPU or GPU, and used some intelligence to determine to use CPU or GPU debayering. When Red OpenCL debayering was broke in macOS 10.13.2, we then had no way to force it use CPU debayering, except to change GPU mode to Metal. Since Red debayering doesn't work on Metal, it uses CPU debayering.

Happily, in Resolve 15, we've brought back the "Use GPU for Red Debayer" selection in Resolve Preferences - System - Configuration.

If you were using Resolve 15 when you monitored the GPU usage, make sure that the "Use GPU for Red Debayer" is checked in prefs, and make sure you are not using Metal GPU processing mode.

Thanks Dwaine. I edited my post above to include some data points, not sure if you saw it, but either way good to know that v15 might allow for additional utilization of eGPU. Near as I can tell right now, filter acceleration during playback of transcoded footage is the biggest "eGPU win" for v14.x [and the other good news - two eGPU clearly work better than one in that realm so there is some support looks like.]