- Moderator
- #121
Jeff Kilgroe
Well-known member
Hm, I hope I don't get in trouble for this.
While at NAB at one of the demos I was present, I overheard couple of manufacturers talking. First, one complained of being screwed by another manufacturers, that had decided to break the rules and do ARRI RAW debayer in strictly GPU, which was expressly prohibited, but they did it anyway. They demoed ARRIRAW debayer in real time with only GPU. Then another manufacturer complained about the same thing with RED. They even said, that they had managed to do an almost real time debayer of Red RAW without technically breaking the GPU rule, but apparently it was just a clever trick. Something about multiple copies of libraries... I'm not an engineer, so I have no idea what that means. Anyway, they had mentioned, that it was very difficult to have a conversation with Gramme about any kind of SDK implementation, other than Red's way. I guess, it's not that surprisingBut now I'm curious, Gramme, is it possible to do debayer in GPU?
ARRI views their RAW debayer process the same as RED -- they want control and want to provide the tools that perform the debayer process. The primary reason behind this is to guaranty the same results and quality within any application that debayers their footage. If you remember back to the early days, circa NAB '08, companies like CineForm were attempting to deconstruct R3D files and provide their own debayer tools, even though Jim had asked everyone not to. Others were mostly doing this out of desperation to release new products and they did not want to wait around for the SDK. But there are a few side effects to this approach. First and foremost, not being officially supported by RED, inconsistent quality of debayer from different software creators, software that breaks every time the format gets updated, etc.. ARRI is going through many of these pains right now.
As for the GPU support, yes it's possible to debayer on a GPU. But frankly, it's best not to. GPUs are always in a constant state of flux with new products and core processor designs. If you optimize for CUDA on the GT-2xx platform, it may run dog-slow under CUDA on Fermi. If you want to support more GPUs, or anything other than nVidia, you have to use OpenCL, which has its own share of quirks and issues. Or you can forego both standardized GPU APIs and hit the metal yourself... Which no one in their right mind is going to even think of attempting. Not with dozens of GPU flavors commonly in use today.
Keeping the debayer process based on the CPU makes a lot more sense. It's more stable and has more room to scale with newer CPUs and increased numbers of cores. The RED SDK is rather simple and straight-forward, it's pretty darn easy to integrate R3D support into a new application and not so bad adding it to existing applications, if your software is written in a way to add new formats without breaking everything else. The big problem I currently see with R3D integration is not the CPU-based debayer process, it's the software developers' continued misunderstanding multithreaded design. Adobe is getting it and we're seeing some pretty good performance out of MPE. Looks like Apple is finally stepping into the current era with FCP-X. Avid? Uh, well, MC5 barely scales efficiently between two CPU cores, so who knows... Current i7-based (or Westmere Xeon based) systems should be able to play back 4K REDCODE in real-time and still have some resources left to spare, if multithreaded playback is decently written. I wrote a simple R3D player app when I first got the SDK and it gave me real-time playback at half-res high scaled to 2K on an '08 Mac Pro 2.8GHz quad-core. Of course, that was just playback and nothing else going on and not particularly optimized, just written as part of a few tests to get my head around the SDK when they released it. I just used the standard Mac GDI and didn't touch any of the Core libraries or OpenGL for performance.
GPU could still be used for a lot of operations that take place after the debayer process. This happens on a small scale with REDCINE-X. Adobe is using the GPU within MPE for colorimetry, GPU-accelerated FX, scaling and transformation options, etc.. In fact, it's pretty easy to saturate the GPU in CS5 what what it supports -- best to keep all those CPU cores under the hood churning away on the decompression, decoding and/or debayer of your footage. There is a lot going on in MPE and even with all that is going on, I can cut 2 or 3 streams of 4K REDCODE quite comfortably on a Macbook Pro or similar system and not feel like I've got the system pushed to the max.
As for the other post comments, etc.. I see that too, especially regarding colorists. I've been essentially repeating what RED has been saying since the beginning. Think of R3D as your film neg. You want to stay RAW as long as possible. Avoid REC-709, there's a reason you now have to specifically turn it on in the advanced options within RC-X. Don't transcode to DPX at the start of your color workflow. In fact, don't use DPX at all unless you have support for 16bit log DPX. 10bit DPX is so 2008 at this point. And I personally waved goodbye to QT proxies and transcoding to edit for most of my projects about 2 years ago. I don't have the camera generate/record QT proxies in most situations. They just confuse most of my clients, who are PC based, and run Avid or Premiere.
