The naked truth about the RED Rocket

[Tony Lorentzen]

Catchy title, I know ;-)

It's been somewhat discussed in the past, but it would be nice to get the full details on the RED Rocket's debayer quality. RED.com says it delivers "full quality realtime 4K". I asked Graeme on Twitter about the Rocket vs. Software debayer and his response was "Rocket v Software is a choice. They look different in "texture". R=sharper. S=smoother.".

My question to all of you that are working with finishing and DI if you're using the Rocket or Software debayering for the final conform?

If anyone knows Michael Cioni from LightIron then I'd be most interested to hear his take on this for the projects they've worked on in the past.

My own experience is exactly that of Graeme's, that the Rocket's output is very sharp - sometimes a bit too "edgy", actually.

Thanks for everyone's input in advance :smile5:

[Gunleik Groven]

Hm...

I have often thought that if I could setup a proper renderfarm, that would be better, but for all practical purposes, the rocket is it...
But I have access to enough machines to do the cluster thing, so I guess in the end the Rocket makes me lazy...

Gunleik

[Stephen Pruitt]

How does a deBayer in the new CS5.5 Premiere Pro (set on "high") differ from a deBayer using other techniques?

Thanks.

Stephen

[Tony Lorentzen]

Hm...

I have often thought that if I could setup a proper renderfarm, that would be better, but for all practical purposes, the rocket is it...
But I have access to enough machines to do the cluster thing, so I guess in the end the Rocket makes me lazy...

Gunleik

How would you set up a render farm for software rendering of R3Ds? Using Redline in some way, maybe?

[Jean Déraps]

That is one of my pet peeves about the Rocket, that I have no control over the amount of 'sharpening'. This means I often have to do this as part of an extra step in some other software. I wonder why sharpening controls aren't available in 'rocket-powered' debayering...

[Mike 'Fireman' Ross]

Forgive the clueless newbie, but why should there be any difference at all? The code is the same, the algorithms are the same (?), the Rocket simply uses dedicated hardware to accelerate the process, I thought?

If the output from a software render is not bit-for-bit identical to an output with all the same parameters, but rendered with hardware assistance, something is wrong - to my way of thinking anyway.

Mike

[Graeme Nattress]

The software demosaic is not the same as the Rocket hardware demosaic. The software demosaic is too complex to run in hardware, but it benefits from being smoother, whereas the Rocket demosaic is sharper. The R3D decode, matrix and LUTs are fully matched between hardware and software.

Jean - there is no sharpening in Rocket, and that's fine because we don't recommend you sharpen until the end, with respect to the desired output format.

Graeme

[Mike 'Fireman' Ross]

Thanks for the clarification Graeme. We live and learn!

When the Rocket cards show up in the Battle Tested store again, I'll grab one and experiment for myself.

Amongst my toys, I have a deskside SiCortex supercomputer: 72 CPUs, 48GB memory. It would be interesting to see how that would run RED-related codes :-)

Mike

[Graeme Nattress]

I'm sure the SiCortex will keep your office warm!

Graeme

[Noah Kadner]

Gotta say- if you are doing anything like regular work with the RED- the Rocket is not optional it's essential. That is unless you have a lot of free time (both yours and your clients) to wait for renders.

Noah

[Jean Déraps]

Graeme, I certainly appreciate the fact that there is no sharpening by default. When I'm working on more important projects the sharpening gets done "in post". But there are times when I just need to get some dailies out 'quick and dirty' using REDCine and certain clients judge the shots as being 'soft'. It's a pain to have to do an extra step every time just to make them look as great as they can be...

[Stephen Pruitt]

I hate to ask twice, but how does the deBayer in CS5.5 differ from that obtained via the RR or other means? Is it inferior? Or the same?

Thanks.

Stephen

[Graeme Nattress]

Stephen, they all access the same code through the SDK, so if it uses the Rocket card it'll look the same as the use of the Rocket in REDCine-X, and similarly, if it uses the software demosaic it will look the same as the software demosaic in REDCine-X.

Graeme

[Stephen Pruitt]

Okay, great, Graeme. I really appreciate this. So, just for the sake of reiteration into my usually thick skull, the deBayer I'm getting from the CS5.5 set to "high" is the same quality I'd get if I were having the footage processed via a Scratch system or something similar that didn't have a RR card?

Stephen

[Graeme Nattress]

Say you're comparing software to software - they all go through the SDK, they all get the same pixels back for the same settings and R3D going in.

Graeme

[Tony Lorentzen]

Say you're comparing software to software - they all go through the SDK, they all get the same pixels back for the same settings and R3D going in.

This is an important point. It should be framed and hung on a wall for all to see :-) One thing to note - though - is that the software apps can have different versions of the SDK implemented, which could give different results.

[Stacey Spears]

Stephen,

Does CS5.5 give you the option of 8, 10, 12, and 16-bit? SCRATCH does offer all of these choices,, so this will have an impact. RCX does not expose this and I am not sure which bitdepth they use.

[Mike 'Fireman' Ross]

I'm sure the SiCortex will keep your office warm!

Graeme

You jest!

The SiCortex is a wee ATX deskside box. If I need warmth, I fire up much more serious hardware:

http://reduser.net/forum/attachment.php?attachmentid=15276&d=1310583624

:-)

Mike

[Graeme Nattress]

When I googled it, it came up with this: http://cgullworld.blogspot.com/2007/11/sexiest-super-computer-sicortex-sc5832.html hence my thought it was a room heater!

Graeme

[Gunleik Groven]

Gotta say- if you are doing anything like regular work with the RED- the Rocket is not optional it's essential. That is unless you have a lot of free time (both yours and your clients) to wait for renders.

Noah

You could allways distribute the renders...

[Graeme Nattress]

I've seen Resolve running great on native files without a Rocket, just dropping the rez and it looked pretty darn good for grading in real time - even worked pretty good with Epic 5k files. That said, a Rocket is nice indeed :-) Just puts less strain on the CPU and you'll get more immediacy and image detail while grading.

Graeme

[Tim Whitcomb]

+! for ROCKET workflow. I can barely tell any difference in HW or SW debayer and the speed advantage is something I cant live without...

I also think the mild sharpness advantage of HW debayers helops improve the transcode qualities... ESPECIALLY when transcoding to DPX

[Matthias Hutter]

@Grame: With new GPUs switching to SIMD architectures with out-of-order resource allocation, do you think it will be feasible to run parts of the deBayer algorithm on them?

[Graeme Nattress]

GPUs are funny beasts - there's some math they do great at and others not-so-great. I'm not an expert on how GPUs are progressing, so it's really hard for me to judge there.

Graeme

[Matthias Hutter]

From what I understand, GPUs are in-order processing only while X86-CPU can do out-of-order too.
Additionally, GPUs before Nvidia Fermi/AMD Graphics Core Next had a terrible architecture for general purpose graphics computing.
AMDs GCN Chips are radically redesigned with focus on Compute. They will use SIMD units, similar to the streaming SIMD extensions (SSE) in CPUs

I think Anandtech has the best coverage here (http://www.anandtech.com/show/4455/amds-graphics-core-next-preview-amd-architects-for-compute)

[John Hable]

@Matthias: It depends on what you mean by general computing. The two things that GPUs are really bad at are algorithms with lots of branches and anything that requires random memory access patterns. Most debayering code that I've seen in the past would run just fine on the GPU, but I have no idea how Red does it.

@Graeme: Out of curiosity, is the debayering algorithm publicly known, or is it a trade secret? Also, is the CPU version AVX optimized?

[Tony Lorentzen]

@Graeme: Out of curiosity, is the debayering algorithm publicly known, or is it a trade secret? Also, is the CPU version AVX optimized?

The principles of debayering is pretty straight-forward, but as with everything else - the devil is in the details; which in Graeme's case are called "magic pixies" ;-)

[Harcharan Singh]

Hi,
We cannot even imagine to deliver projects without the RR on our Scratch system...It really pumps up the workflow and the final renders.

Thanks
Harcharan

[Matthias Hutter]

@Matthias: It depends on what you mean by general computing. The two things that GPUs are really bad at are algorithms with lots of branches and anything that requires random memory access patterns. GCN SIMD doesn´t have the scheduling problems the old architectures (VLIW) had, but it is still an in-order processor. Also GCN will provide out-of-order memory access.

In short I think it could be used pretty easily, but we don't now anything about RED's debayer, or do we?

[John Hable]

GCN SIMD doesn´t have the scheduling problems the old architectures (VLIW) had, but it is still an in-order processor. Also GCN will provide out-of-order memory access.

In short I think it could be used pretty easily, but we don't now anything about RED's debayer, or do we?

Hm. I'm a bit skeptical that scheduling is the issue. Keep in mind that recent GPUs have thousands of threads in flight, so any time you have a thread stalling there is usually another thread that can run in it's place. I'm oversimplifying of course. If you have a loop with no branches (often the case with ALU-heavy code), there no reason why the GPU could get better results at runtime than the compiler can do. The article is a bit misleading on this point. They state that one advantage is you might have a bad compiler, but the final compilation step is done at the driver level with your video card. You'd only get better scheduling with really branchy code. At least that's how I read it.

Btw, NVIDIA dropped their VLIW-like architecture years ago with the 8800 series of cards. Each thread only runs scalar operations, so it's much easier to keep the ALUs fully saturated.