Anyone know how R3D is implemented in metal and how it scales? M1/M1P/M1M

[Jason Gorman]

Is it fully parrellelized or just x threads? Anything funky or just straight metal calls?

Editing Komodo footage on my M1 13" MBP is already not bad outside of the initial scans and/or proxy creation if you bother. For just cutting footage, I haven't really noticed any issues just running raw the whole way through lol. Certainly a smoother experience with the proxy/optmized versions though.

Mostly curious how well it will R3D footage will be able to keep up with the claimed 10x prores prores/raw improvements (especially with me and my friend dreaming of a future v-raptor) which if all asic based should be relatively accurate, though quality remains to be seen, but I guess you can always slow transcode at the end.

I'm hoping 32core gpu vs 8core gpu should yield roughly 4x perf for normal metal giver or take extra scheduler overhead and different clock speeds and such. At that level I THINK it should be able to handle v-raptor HQ footage, at least if its normie 23.98/24/30. But I don't know squat about how the r3d codec works, and how much like vector math and such is involved. But at least in my mind, 4x decent 6k Komodo footage performance should be at least equal but ideally better 8k v-raptor footage and much smoother/faster Komodo handling.

TBH I'm not sold on buying this year anyway, at least not another laptop, but I'd love the big chip in a Mac mini . Mostly just curious about the potential, mainly for Komodo since its what I got, but given how expensive the full cpu/ram upgraded MacBook Pro with any sensible sized SSD (cause of endurance) for a media laptop is, it's enough to scare me off for now lol.

 

[Ryan Chernin]

I'm having trouble playing back 8K HQ Raptor footage on a M1 Max (32 Core 64GB), for what it's worth

 

[Mike P.]

Nope, nada! Would love to be told otherwise, but there is no Metal R3D debayer/decompression support *or* native Apple Silicon support. It’s just being brute-forced via CPU and not taking advantage of anything...

Pretty sure OpenCL decompression is still single threaded after ~3.5years too, which is why CUDA is still faster (but CUDA isn't on Apple).

 

[Jason Gorman]

I'm having trouble playing back 8K HQ Raptor footage on a M1 Max (32 Core 64GB), for what it's worth

What's the fps/datarate on that? I noticed on my 13 M1 16gb MBP, with Komodo footage I could play MQ just fine even if I started adjusting the footage and stuff, but it definitely struggled with HQ. In my case tho the GPU is teeeeeny. But I'm pretty sure raptor footage at the highest settings can actually like stress my SSD (though the one in m1max is supposed to be 2x as fast and should be fine) before the gpu/cpu even get a chance to run into problems lol.

I'd also be curious if it plays any better in the latest Mac version of RedCineX since it was updated a few days ago and mentions improved OpenCL GPU Decode. No idea if the same changes would be applicable to the "Red Apple Workflow" FCPX plugin stuff (and what exactly its referring to when it says "Added native support for Apple Silicon (requires FCP 10.5.2 or newer)").

I'm also curious what this press release from 2 years ago was referring to: https://www.newsshooter.com/2019/12/13/red-apple-complete-metal-gpu-accelerated-r3d-support/

 

[Phil Holland]

Nope, nada! Would love to be told otherwise, but there is no Metal R3D debayer/decompression support *or* native Apple Silicon support. It’s just being brute-forced via CPU and not taking advantage of anything...

Just a reminder that native Metal support is in the RED SDK for a while now, native Apple ARM/Metal support, etc. It's in the release notes for the SDK, but I imagine not many keep up with that. Resolve has it currently as well as I believe the FCPX plugin.

SDKs as well as other things are subject to how and when anybody implements anything into whatever you're using. Resolve as of late has been the fastest to implement new code.

 

[Mike P.]

I’ve read the release notes and presumed that was just debayer assist (which doesn’t really increase playback performance regardless of API) and not decompression (since the performance is so meager). Separately, as of last month’s RCXp, it still doesn’t have Metal as a GPU mode (only Cuda and OpenCL, even though Cuda is no longer supported by Apple).

Also there’s never been mention of OpenCL (never mind metal) being multi-threaded, just Jarred saying it’s ‘single threaded and hence doesn’t offer an advantage unless you’re running the highest-end desktop AMD GPUs’ when OpenCL was first implemented ~3.5years ago (plus, again, performance hasn’t improved noticeably since then).

And is Apple Silicon natively supported or “supported” (via Rosetta 2 behind the scenes)? Regardless the performance seems to be lacking there as well, as there was no discernible bump in playback performance on M1/pro/max from the non-AS versions.

 

[Phil Holland]

Unknown on further/future optimizations, but RCX will likely get some love for Metal which will likely have some beneficial side effects to the SDK.

Just don't know when.