The naked truth about the RED Rocket

[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

 

[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]

RR

RR

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.