Welcome to our community

Be a part of something great, join today!

  • 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 :)

RED & GPU's

Paul Schneider

Well-known member
Joined
Dec 28, 2009
Messages
449
Reaction score
0
Points
0
Location
LOS ANGELES
Website
www.concreteandclay.com
I don't believe RED allows for any utilization of GPU in the decoding and playback of r3d files. I could be wrong (and if so please enlighten), but if this is in fact the case I am wondering why.

RED Rockets are great, but its becoming a bottleneck. I direct and shoot EPIC a ton. However anyone who knows commercial production also knows that the agency usually determines the editorial and post. I can suggest, but more often than not where the footage is taken is out of the hands of the initial production. Most post and editorial houses do not have RED Rockets...of course they should...but they don't. What they do have are fast systems with fast graphics cards.

Basically what I'm asking here is if anything can be done to make the RED workflow a little more easy & ubiquitous with standard off the shelf tech. Allowing GPU processing would almost certainly help if such a thing is possible.
 
I'll leave the details to folks like Jeff K., but as I understand it, decoding RedCode (similar to JP2K) is very CPU intensive and AFAIK not a task that can be done efficiently by the GPU. Perhaps Ivy Bridge procs and Kepler GPUs will change things but AFAIK we're not there yet. Looking forward to it though!

Cheers - #19
 
The bulk of the processing required to decode R3D frames is the decompression of the wavelet-compressed data. The de-bayer or de-mosaic process takes place after the decompression and is actually rather trivial. Wavelet decoding is a huge drain and a task that is not well suited to GPUs, or at least not most current GPUs as they exist at this time. This is changing as newer options enter the market and hopefully as other technologies like Intel's MIC compute card and the nVidia Tesla K20 which both should debut around the first of next year will provide a solution.

The Rocket is a good solution and it is indeed starting to show itself as being a bottleneck with 5K footage on fast workstations. The Rocket is purpose-built for decoding wavelet data and is still going to do it far better than any single GPU card currently on the market could. IMO, what really needs to happen is a major price reduction on the RED Rocket. And that may or may not happen, but I really don't think the Rocket has more than another year or two of usability left in relation to other hardware coming to market. It will continue to be more of a bottleneck as time goes on. My money is on the Intel MIC (formerly known as Knight's Corner). It's similar in design to newer GPUs with many cores, but is built for larger scale operations. It can accelerate OpenCL to assist in GPU-oriented computations, but it also accepts the full x86 instructional library, so it will be easy for developers to port Intel-specific code directly to it. It's quite a beast and runs as its own self-contained compute cluster. It even has its own onboard operating system and can run independently of the host system.
 
I don't believe RED allows for any utilization of GPU in the decoding and playback of r3d files... Basically what I'm asking here is if anything can be done to make the RED workflow a little more easy & ubiquitous with standard off the shelf tech. Allowing GPU processing would almost certainly help if such a thing is possible.
In my testing of 6k workflow, there needs to be a ton done in the GPU, or things go glacially slow (even for high end machines - i.e. my new test system is 12 core, 64 gig ram, 3000 cuda's - and I'm at seconds per frame on 6k workflow). Only other options is to convert the r3d to an open DI wavelet that is GPU'able as one of the first steps in the workflow using color3 redlogfilm (i.e. redlogilm -> jpeg 2000 "like" wavelet as a DI, also would want to pick a wavelet type that could "strip" the needed dimensionality without impacting performance).

[Edit ... probably not the jpeg 2000 like wavelet ... the openexr 2.0 using the pixar wavelet "piz" seems perty cool, is non destructive too]
 
Last edited:
The bulk of the processing required to decode R3D frames is the decompression of the wavelet-compressed data. The de-bayer or de-mosaic process takes place after the decompression and is actually rather trivial. Wavelet decoding is a huge drain and a task that is not well suited to GPUs, or at least not most current GPUs as they exist at this time. This is changing as newer options enter the market and hopefully as other technologies like Intel's MIC compute card and the nVidia Tesla K20 which both should debut around the first of next year will provide a solution.

The Rocket is a good solution and it is indeed starting to show itself as being a bottleneck with 5K footage on fast workstations. The Rocket is purpose-built for decoding wavelet data and is still going to do it far better than any single GPU card currently on the market could. IMO, what really needs to happen is a major price reduction on the RED Rocket. And that may or may not happen, but I really don't think the Rocket has more than another year or two of usability left in relation to other hardware coming to market. It will continue to be more of a bottleneck as time goes on. My money is on the Intel MIC (formerly known as Knight's Corner). It's similar in design to newer GPUs with many cores, but is built for larger scale operations. It can accelerate OpenCL to assist in GPU-oriented computations, but it also accepts the full x86 instructional library, so it will be easy for developers to port Intel-specific code directly to it. It's quite a beast and runs as its own self-contained compute cluster. It even has its own onboard operating system and can run independently of the host system.

Thanks for that. Makes sense.

I'm sure RED realizes the bottleneck whether they'd admit it or not. Its a difficult thing, this RED. Its got everything it needs to be the perfect commercial camera...a replacement for the venerable Arri 435 in every way with bonuses. However an understanding of just how commercials get finished and who actually finishes them has become literally as important as the tech for me now. If the footage gets in the wrong hands...which happens a lot...the game is over. 4k processed like crap is worse than shooting in HD. Period.

Commercials demand to be made fast. Dailies the next day at the latest. Edit in a couple days. VFX in a week. I hope that as things move forward into 6K and beyond there is equal focus towards how this rapid expansion in sensor and camera tech effects the post side. Cheaper cards and innovative real time proxy workflows for not just editing, but vfx and compositing will be required if RED wants a sustained revolution.
 
Back
Top