Mojave on MP5,1: FCPX with AMD GPU

[bazza5938]

Hopefully the people involved with this discussion elsewhere will join in here, as I do think it's interesting conversation, although not entirely appropriate to the original thread.

I'm not sure the following will work on you but you can give it a try.

1. In the preference of FCPX. Check Leave files in place. Where you should place your source files on a very fast drive or virtual drive (LUN). This drive should have at least 10Gbps consecutive read/write speed. To try out a consecutive read/write test. You can download AJA System Test software (https://www.aja.com/products/aja-system-test). Do a benchmark yourself with a file 4k media at 64GB file size. Let the AJA software to stress the drive. See if the drive can have a read and write test consecutively doing of a speed > 1,000Mbps. If you see it is fluctuating during the read or write (Not constantly stable at peak performance, such as very fast at the beginning but the performance drops sharply after a few or ten seconds later). Then your drive performance is not ok for FCPX. The AJA software can tell the fact for you. And the timeline could be lagging on those who cannot get qualified on this test. And that drive should always have at least 30% of free space. In this case, the drive where it houses the FCPX Library doesn't have to be very fast. But at least it should have the speed of a SSD drive 500Mbps Read/Write.
2. In the preference of FCPX. Enable the Create optimised media checkbox and disable the Create Proxy media check box. Proxy media is for poor performance Mac only. Not your case I think if you have a Mac Pro + Radeon 7970 (or Metal supported cards) or above.
3. Close and reopen FCPX.
4. Create a new event and project. Import the media. Leave files in place during the import.

See if there is any improvement to the performance of the timeline scrolling.

And QuickTime is a native media player by default to use hardware h264 decoding on Mac. Basically all recent Radeon Cards will do. On VLC, you need to enable the checkbox "hardware decoding" in the preference. But no guarantee.

Optimised/proxy media work as I'd expect, this was purely a test to see how working on raw h264 footage would go, as had been shown by h9826790 so I wanted to see what my system would do.

With regards to testing performance, I keep a library for current work on my NVME, then back up things to other libraries elsewhere when I'm done with them, and I'm not doing this professionally at all, though I intend adding some video work to what I do, but I'm always interested in getting what performance I can from what I have

Aja set to DCI 4k, 64gb, 10 bit YUV (since you didn't mention changing codec) didn't reach 1,000mps write, but didn't fall below 800, and reads were over 1,400 consistently, which is fair enough, as I'm not using an nvme carrier with a PLX chip on it, just the Kyro one and for what I've spend, I'm happy with the speeds of it, just if I could get extra decode/encode help from the GPU while doing stuff, it's an added bonus

 

[PowerMac84]

Thanks for creating the thread. I think the discussion about data I/O speed is absurd when it comes to H.264 and HEVC editing speed. Those are like on the lightest video formats. Those formats were created in mind with small data sizes. Compression is great and also very efficient. A normal SSD is more than enough for editing. That’s true for Premiere Pro and FCPX. Even traditional NAS or SAN are sufficient. Access times may be slightly slower without SSD caching involved - but still almost everyone can edit it from their main system ssd.

 

[bazza5938]

Thanks for creating the thread. I think the discussion about data I/O speed is absurd when it comes to H.264 and HEVC editing speed. Those are like on the lightest video formats. Those formats were created in mind with small data sizes. Compression is great and also very efficient. A normal SSD is more than enough for editing. That’s true for Premiere Pro and FCPX. Even traditional NAS or SAN are sufficient. Access times may be slightly slower without SSD caching involved - but still almost everyone can edit it from their main system ssd.

I agree, but there are times when it would be a really big requirement, and in solaris8x86's situation, I'm sure that's the case, it *shouldn't* have anything to do with this particular test, but as I said, in the interested of squeezing all the performance possible out of what we have, I thought I'd include it anyway, if I was trying to decode red raw footage, I'm sure the throughput would make a much bigger difference, but I'm also going to do want to see if I can do this with hevc as well as h264, as if I could edit without transcoding, it'd shave a lot of time off doing anything, if h9826790 could join in too and list his tweaks here, it could be helpful for a lot of people looking to do similar things, and no doubt we're all doing different levels of things in final cut, if we can do it quicker, it's good for everyone, right? Even if we're not putting together full 4k HDR blu-rays, the methodology behind it could be useful for someone sticking a quick vlog up on youtube too

 

[PowerMac84]

Sure, storage is always important. Throughout helps a lot. I have administered an XSAN that i’ve Built myself with a couple of Linux storage servers. Fibre channel is really fun. I’m afraid times have come and now 10 GBit/s-NAS is the new King of the Hill. Recently I built a 288 TB storage server with FreeNAS and the Xeon-D Plattform. So it’s ZFS plus Optane caching for ZIL and L2ARC.

The cool thing is since apple started to use those crazy fast pci-e SSD a few years back ago, throughout became almost irrelevant. It’s mandatory for 8K editing in complex projects (we edit feature films of 90-120 Min shot in Red Raw 8K). That’s a hopping 20 TB of source footage btw.

Right now I’m working on my Hackintosh and it’s so nice to work here. Even if I don’t really like to rely on Hackintosh (it’s never as stable as a real Mac and lots of work) editing is fun. Tried various H.264 clips, EVA-1 footage. Smooth as butter. As is 4K,6K, 8K. Sigh.

 

[bazza5938]

Sure, storage is always important. Throughout helps a lot. I have administered an XSAN that i’ve Built myself with a couple of Linux storage servers. Fibre channel is really fun. My I’m afraid times have come and now 10 GBit/s-NAS is the King of the Hill. Recently I built a 288 TB storage server with FreeNAS and the Xeon-D Plattform. So it’s ZFS plus Optane caching for ZIL and L2ARC.

The cool thing is since apple started to use those crazy fast pci-e SSD a few years back ago, throughout became almost irrelevant. It’s maybe for 8K editing in complex projects (we edit feature films of 90-120 Min shot in Re Raw 8K). That’s a hopping 20 TB of source footage btw.

Right now I’m working on my Hackintosh and it’s so nice to work here. Even if I don’t really like to rely on Hackintosh (it’s never as stable as a real Mac and lots of work) editing is fun. Tried various H.264 clips, EVA-1 footage. Smooth as butter. As is 4K,6K, 8K. Sigh.

Have thought about building a little box to do something similar, pretty much using lower versions of what you have, maybe a normal NVME for bcache, not as much storage, and doubt I'd use xeon on it, though would probably end up with a CPU bottleneck not being able to push through bigger files.

As for Hackintosh, I know, roll on the new Mac Pro, I really hope they do it right, it's bad when hobbyists such as myself are running a 10 year old system that's doing things better than the current things in every way but CPU, and intel are even struggling at that point. So being able to add on 4k h264/hevc editing without transcoding handing it off fully to the GPU would be a great addition, maybe I should go through the old thread and pick out the relevant bits to get onto here for reference if nothing else, but will maybe be able to tomorrow, after midnight here and don't really want to have to go through the whole thread right now

 

[PowerMac84]

Go for it! There‘s numerous NAS builds out there. I think it‘s still very difficult to tune it. I have heard that experts are able to tweak another 50% extra. If you want good speed on your 10 Gbit/s Ethernet prepare for reading a lot of forums and discussions how to tweak it. Large sequential files is like a special interest in the world of data storage. Most is prepared for small database applications.

 

[solaris8x86]

normal NVME for bcache, not as much storage, and doubt I'd use xeon on it, though would probably end up with a CPU bottleneck not being able to push through bigger files. interesting conversation, although

Too slow for the write I think. The result that I've achieved in the demo video is from a both 15Gbps on write and read (symmetric, (read/write at identical speed)) RAID-0 drive. Mine is a [SAS 6Gbps write cache enabled Controller] formed a RAID-0 SSD SANDISK Extreme Pro 480GB x 4. Of course, the performance parameters on the SAS BIOS has been fine tuned for video editing oriented performance. My storage configuration is purely for video post-processing purpose in my configuration. Before this on my old RAID storage, I was at 600Mbps RAID-0 but couldn't achieve the similar result (lag on timeline scrolling).

 

[h9826790]

Hopefully the people involved with this discussion elsewhere will join in here, as I do think it's interesting conversation, although not entirely appropriate to the original thread.



Optimised/proxy media work as I'd expect, this was purely a test to see how working on raw h264 footage would go, as had been shown by h9826790 so I wanted to see what my system would do.

With regards to testing performance, I keep a library for current work on my NVME, then back up things to other libraries elsewhere when I'm done with them, and I'm not doing this professionally at all, though I intend adding some video work to what I do, but I'm always interested in getting what performance I can from what I have

Aja set to DCI 4k, 64gb, 10 bit YUV (since you didn't mention changing codec) didn't reach 1,000mps write, but didn't fall below 800, and reads were over 1,400 consistently, which is fair enough, as I'm not using an nvme carrier with a PLX chip on it, just the Kyro one and for what I've spend, I'm happy with the speeds of it, just if I could get extra decode/encode help from the GPU while doing stuff, it's an added bonus

I am more than happy to join this thread, but since solaris8x86 also here, you better ask him how to edit RAW H264 with hardware accel. Apparently he know more than all of us (despite he actually recommend you to use optimised media, which is ProRes but not RAW H264).

Until we can prove his Vega doesn't have H264 hwaccel in FCPX, you better keep the OS clean, and do not install extra kext, or insert unnecessary boot argument, etc.

In fact, I am still waiting for his video to show me how his cMP perform when doing the exact same test as I did. Which means, no background rendering, no proxy, no optimised media, all generated files clear, just import a 4K RAW H264, and edit that straight away.

If he can show me how his cMP can do with 4K HEVC, that will be even better

Also, how fast he cMP can export H264 in BruceX

I did everything to show him how to perform proper test with the required data to show on the screen recording (to validate the test). I am now waiting for his turn. (P.S. What I showed in the video has Mac Pro ident, CPU config, BootROM version, PCIe card's info, real time clock, background rendering OFF, proxy OFF, optimised media OFF, generated files clear, source / product video metadata, real time CPU / GPU utilisation, the whole process to perform the raw H264 / HEVC test, and the whole process of the BruceX test...)

I really hope that I am wrong, and his Vega is so special that activated hwaccel by default in macOS. In that case, we hope that he can share his Vega's ROM to us, which may be specifically blessed by Apple (a bit like only some RX580 can use Orinoco framebuffer in macOS).

Last but not least, this is what I can see in VideoProc hardware info

As you can see, Graphics is N/A, but H264 hwaccel is supported up to 4K DCI. Since there is no other GPU in my cMP. The hwaccel can only be coming from the RX580.

It says no HEVC hwaccel, but I actually successfully enabled HEVC hardware decode, just no encode.

I used this video to perform the HEVC hardware decode test.

https://4kmedia.org/sony-swordsmith-hdr-uhd-4k-demo/

And this is the result.

I hope all you can enjoy this, shared how to perform the tweak. But since solaris8x86 says my knowledge is outdated. Please ask him how to get you the latest codec hwaccel support.

Or until solaris8x86 apologise for his misbehaviour, then I will re-post the software modification guide again. Of course, if end up he really has hardware accel, then I will say sorry to him (because I didn't trust his info). And I will join you guys to ask him to teach us how to do that properly.

I want to stay objective, stay with facts, and keep the system as clean / safe as possible.

N.B. please watch the video in 4k resolution in order to see the details clearly.

 

[solaris8x86]

Ok. as you wished.

 

[h9826790]

When working on 4K video. The NVMe is not as fast as expected. It is a mis-conception to most users. Under a practical situation. Blue is you. Red is me. So be aware don't over estimated the NVMe storage when working on a video editing.

View attachment 835872

This 4K is completely different than that 4k.

We are talking about 4K (3840x2160) video resolution, not that 4kB blocks random read on the hard drive.

4K video is a single large sequential file, not multiple random 4kB small files.

For video resolution, we have SD, HD, 4K (UHD), etc.

For hard drive, we have block size 4K, 64K, 512K etc.

PLEASE STOP spreading the wrong info. You may confuse other members.

And RAID 0 CANNOT improve 4K random read QD1 performance.

 

[tsialex]

When working on 4K video. The NVMe is not as fast as expected (you won't have 1500Mbps). It is a mis-conception to most users. Under a practical situation. Blue is you. Red is me. So be aware don't over estimated the NVMe storage when working on a video editing. It is fast. But "not really that fast" unless you have a dedicated RAID controller.

View attachment 835874
View attachment 835872

Large video files are the perfect example file for large sequential reads. 4K video resolution has absolutely NOTHING to do with 4KB random access reads.

 

[solaris8x86]

Large video files are the perfect example file for large sequential reads. 4K video resolution has NOTHING to do with 4KB random access reads.

You are right this time. So...emm.. mine is the only one who has optimal performance on this thing. That's funny. But ok to me. Fortune takes care to me. And I can't simulate why you guys's Mac are so slow emm. I'm chosen... emmm... but I do believe the RAID controller has some secret juice applied to the mechanism behind my gears to achieve that super fast performance for me.

Hope you can have improvement soon.
FCPX by Vega 56 hardware acceleration on my Mac Pro 2010 runs so fast for me now.The storage of mine is so cooperative to me now. So I'm so happy now at work.

 

[h9826790]

You are right this time. So...emm.. mine is the only one who has optimal performance on this thing. That's funny. But ok to me. Fortune takes care to me. And I can't simulate why you guys's Mac are so slow emm. I'm chosen... emmm... but I do believe the RAID controller has some secret juice applied to the mechanism behind to achieve that fast for me.

Because you turned on optimised media. Please turn that OFF (and also turn OFF proxy, turn off background rendering, and clear all generated files), and try again. Then you should able to see what we are talking about.

This is the Apple support page about Optimised / Proxy media.

https://support.apple.com/kb/PH12702?locale=zh_HK

They are all ProRes 422. In fact, their bitrate is quite low, which allow them to stay within traditional HDD's sequential performance for smooth video editing.

 

[tsialex]

You are right this time. So...emm.. mine is the only one who has optimal performance on this thing. That's funny. But ok to me. Fortune takes care to me. And I can't simulate why you guys's Mac are so slow emm. I'm chosen... emmm... but I do believe the RAID controller has some secret juice applied to the mechanism behind to achieve that fast for me.

Don't be daft. Some people here have PCIe switched adaptors with ~6000MB/s sequential read. This is useless to encoding.

Secret juice is a nice argument. I'll be using it in the future.

 

[solaris8x86]

Don't be daft. Some people here have PCIe switched adaptors with ~6000MB/s sequential read. This is useless to encoding.

Secret juice is a nice argument. I'll be using it in the future.

You should try out some bands of RAID controller which is exclusively designed for multi-media processing if you can afford the price (SAS RAID controller is not cheap, mine is almost USD$760 per card. And I got 2 x SAS RAID cards for 16 x SSDs). At least there is a dedicated I/O processor to handle the multimedia streaming processing. Must be better than those standard NVMe or SSD I/O controllers I think when handling a stressful multitasking workload.

 

[h9826790]

For disk performance, BlackMagic make a very good tool

This is just from a SATA III connected 840 Evo. Even for ProRes 422 HQ (which is more demanding than normal ProRes 422), 507MB/s is good enough for up to 128 FPS.

But if we want to edit 2160P 10Bit YUV 4:2:2, then only 22 FPS.

For H264 or HEVC, disk speed really doesn't matter, the data rate is so low, even real time internet streaming is possible. Any modern HDD can do that (I really mean HDD, not SSD).

 

[tsialex]

You should try out some bands of RAID controller which is exclusively designed for multi-media processing if you can afford the price (SAS RAID controller is not cheap). At least there is a dedicated I/O processor to handle the multimedia streaming processing. Must be better than those standard NVMe or SSD I/O controllers I think when handling a stressful multitasking workload.

Yeah, sure. Even striped RAMDISK makes zero difference for encoding. Now you are going to say that your magic SAS is faster than striped RAMDISK.

 

[solaris8x86]

Yeah, sure. Even striped RAMDISK makes zero difference. Now you are going to say that your magic SAS is faster than striped RAMDISK.

My SSDs are stripped actually. They are stripped at 4k block I/O size (configurable depends on your needed). They are stripped disks to form a LUN (RAID 0 is a stripping technology actually. Also RAID-5 does the same stripping but with parity check.).

 

[tsialex]

My SSDs are stripped actually. They are stripped at 4k block I/O size. They are stripped disks to form a LUN (RAID 0 is a stripping technology actually. Also RAID-5 does the same.).

When you gonna get the basic fact that for encoding the throughput needed is so low that anything is faster than the codec input? It's CPU and GPU bound, not I/O or disk throughput bound.

 

[solaris8x86]

When you gonna get the basic fact that for encoding the throughput needed is so low that anything is faster than the codec input? It's CPU and GPU bound, not IO or disk throughput bound.

We were talking about timeline. So we were discussing the storage. And the Timeline performance on FCPX depends on both storage and graphic cards which are true.

If you change the focus back to encoding. My Vega card does the job pretty well on exporting a h264 movie AND the performance of timeline on FCPX (shown already previously on youtube). For why you guys can't have the same performance. Be honest, I don't know and I couldn't simulate your environment. Mine is a production environment for commercial activity. Sorry. I can disassemble it for the test for you guys. May be somebody can offer help.

 

[tsialex]

We were talking about timeline. So we were discussing the storage. And the Timeline performance on FCPX depends on both storage and graphic cards which are true.

If you change the focus back to encoding. My Vega card does the job pretty well on exporting a h264 movie AND the performance of timeline on FCPX (shown already previously on youtube). For why you guys can't have the same performance. Be honest, I don't know and I couldn't simulate your environment. Mine is a production environment for commercial activity. Sorry. I can disassemble it for the test for you guys. May be somebody can offer help.

The point of all this is encoding, and decoding, H264 and HEVC with MP5,1 natively.

You are trying to make this about timeline and prove that you are right. For now, you just proved that you don't understand the most basic facts.

 

[VillasManzanill]

Hello. I have a 5.1 Mac Pro with dual x5690 processors 128gb ram Apple ssd the one that read 1500mb ssubx or something like that (can’t remember the name) rx 580 8gb this machine mainly for fcpx.

I use GoPro 4K files h264 that then get transcoded to GoPro cineform codec. And then I edit with those files on fcpx.

If I upgrade the rx 580 to a frontier edition Radeon 16gb (used one) would I see much improvement ? What about a Vega 56 (new one) ?

I’m using the latest Beta OS X with latest botrom 144.

 

[tsialex]

Hello. I have a 5.1 Mac Pro with dual x5690 processors 128gb ram Apple ssd the one that read 1500mb ssubx or something like that (can’t remember the name) rx 580 8gb this machine mainly for fcpx.

I use GoPro 4K files h264 that then get transcoded to GoPro cineform codec. And then I edit with those files on fcpx.

If I upgrade the rx 580 to a frontier edition Radeon 16gb (used one) would I see much improvement ? What about a Vega 56 (new one) ?

I’m using the latest Beta OS X with latest botrom 144.

We still don't have any reproducible results that show that VEGA GPUs improve FCPx performance yet.

For now, it's better just to wait and see reproducible tests and proved performance improvements.

 

[solaris8x86]

What about a Vega 56 (new one) ?

This is the ultimate result from Sapphire Pulse Vega 56 hardware acceleration on Mac Pro 2010 (5,1) ProRes 4444 coding. 4K movie editing in real world. Production platform. Make sure your drive has to be very fast too.

But Frontier is a bit better. Also it needs a power Mod. 16GB RAM is more. So it is faster is expectable. And most people experienced that it is very very hot. But frontier has an issue on Mac Pro is that it has no BIOS alternative (ported from other family boards) to solve the fans-crazy-top-speed problem. So the fan may run at top speed even the system is idle. It is very loud.

RX580, 590 are very fast already comparing to Vega 56 when processing Metal on FCPX. In terms of performance. They are close. No need an upgrade indeed. Just spend money on the enterprise-grade flash drive or storage controller if you have any room in the PCI bay. The result is more noticeable on FCPX. If you spend on those desktop grade NVMe storage. There is no guarantee. They have been reporting not ok on those drives when running FCPx. I'm the only one with a successful result in here. (I had a ok result with 7970 at 1080p editing too when running the same enterprise SAS storage system. Desktop storage system just can't predictable sometime even they claim they are NVMe high tech or somethings fancy. In real world. They all... emmm.... )

If really need an upgrade. Go for reference board Vega 64 or Frontier with any power mods. (both cards do have fan crazy speed problem at idle. Also very very hot.). Good luck.

 

[PowerMac84]

This is the ultimate result from Sapphire Pulse Vega 56 hardware acceleration on Mac Pro 2010 (5,1) ProRes 4444 coding. 4K movie editing in real world. Production platform. Make sure your drive has to be very fast too.

But Frontier is a bit better. Also it needs a power Mod. 16GB RAM is more. So it is faster is expectable. And most people experienced that it is very very hot. But frontier has an issue on Mac Pro is that it has no BIOS alternative (ported from other family boards) to solve the fans-crazy-top-speed problem. So the fan may run at top speed even the system is idle. It is very loud.

RX580, 590 are very fast already comparing to Vega 56 when processing Metal on FCPX. In terms of performance. They are close. No need an upgrade indeed. Just spend money on the enterprise-grade flash drive or storage controller if you have any room in the PCI bay. The result is more noticeable on FCPX. If you spend on those desktop grade NVMe storage. There is no guarantee. They have been reporting not ok on those drives when running FCPx. I'm the only one with a successful result in here. (I had a ok result with 7970 at 1080p editing too when running the same enterprise SAS storage system. Desktop storage system just can't predictable sometime even they claim they are NVMe high tech or somethings fancy. In real world. They all... emmm.... )

If really need an upgrade. Go for reference board Vega 64 or Frontier with any power mods. (both cards do have fan crazy speed problem at idle. Also very very hot.). Good luck.

Everyone knows that ProRes requires almost zero processing power. I can also edit 4K video on a slow MacBook Air. ProRes (be it HQ, LT, 4444) is built for that. The discussion is about H.264 and HEVC formats.
What you are saying about NVME SSD is not correct. Editing with data rates as low as 50 or 100 MBit/s
does not requires NVME enterprise SSDs. It‘s wrong. This is easily done with every SSD I can image. Please stop spreading wrong infos. I know because I build SAN and NAS servers.