CPU vs GPU vs Rocket vs RocketX Quality

[Christopher*Seguine]

In the Dragon threads there were questions about differences between software and rocket decode qualities so I thought it would be good to have a current example.


Below are samples to compare the current processing quality of CPU, GPU, and Rocket.
Sorry I do not have a Rocket-X to test yet, it is my hope someone who does will also contribute to this thread a similar comparison as I am very curious if this problem has been adressed with the Rocket-X.


What you are looking at is the blue channel from a green screen shot. This was not a test, this is part of an upcoming film


With the version tested, there is No difference between CPU and GPU, which is great.


There is a significant difference between CPU/GPU and Rocket processing.
As you can see in the image, the Rocket adds a significant amount of sharpening which can not be disabled or adjusted.
In this case it greatly exaggerates the noise, which would make the composite more work - in motion the random noise is much more apparent.
The blue channel is the worst, but it effects all channels.


Currently CPU decode is single threaded and extremely slow. GPU decode is better, but is currently fixed at 16 threads so is also limited in speed.
I hope more effort is put into parallelization of the CPU and GPU software and sdk so we can work at the best quality with reasonable speed.


The last image is a difference matte to highlight the difference between CPU/GPU and Rocket, it would be solid if there were no differences.


RCX 21.2, OpenCL 1.1 CUDA, Rocket 1.4.36.0/1.1.17.3
Source: Epic 5120x2700 7:1 R3D
No adjustments.
All exports: Sharpness 0, Denoise 0, Detail 2
(These settings are fixed when using Rocket and can not be changed)


Process: Export 16bit DNX Full Resolution, import in AE floatingpoint comp for comparison.
(Currently EXR output using GPU is broken, so I used DPX)
Select Blue Channel, 1:1 Crop, add title, export to 16bit PNG for web viewing.

 

[Matthew Scott]

Wow, what a difference!!

 

[alexjentz]

is it possible to set the sharpness and detail settings in CPU mode so that the results are the same as rocket? which would mean that it is not in general worse quality but more a locked setting issue - which might also of course not be good.

 

[Christopher*Seguine]

Sure, if you want to make the CPU/GPU decode look as bad as the rocket output.

Sharpness 2, Denoise 0, Detail 2 with CPU/GPU is close to the Rocket's fixed setting of Sharpness 0, Denoise 0, Detail 2.

 

[alexjentz]

thx for the info! let's hope the rocket x will be flexible here, so we can choose what we need.

would be a big argument to buy or not buy the rocket x, since it definitely has its price especially if you own rockets already…

 

[Robert Ruffo New]

It appears that GPU and CPU are the same - and only Rocket is different. Has that been your observation? It seems the GPU mode simply uses the exact same math as CPU, but offloads this processing to GPU chips. Is that true do you think?

ANd BTW CPU+sharpening may look similar to Rocket decode, but it's not really the same. Color precision is also lesser with a Rocket - and you can sometimes see it in imperfect talent skin - if the skin is just a bit splotchy to begin with it will be even splotchier with Rocket - some lighting conditions show this more than others.

If you try to do strong secondaries (strong background light gel shifts, for example, qualified by HSL) you get a LOT more noise off the rocket decoded footage than CPU.

In in all, we consider Rocket to be a great tool for creating offline editor files, but that's all, the modern equivalent of "time code burn-in" files from film, but never will a Rocket decode ever go near any final outputs.

Maybe Rocket X is better. We can hope.

Then again for the price of a Rocket X you could probably buy a 16-24 core monster Windows machine that would decide almost as fast, maybe exactly as fast, and could also be used for other things as well.

 

[Elliott Balsley]

Chris, what an interesting test! Thank you for posting. I'd like to hear RED's take on this.

In in all, we consider Rocket to be a great tool for creating offline editor files, but that's all, the modern equivalent of "time code burn-in" files from film, but never will a Rocket decode ever go near any final outputs.

Do you consider the Rocket close enough to use through the whole grading process, then disable it for the final render? Or do you feel think that would cause inconsistencies with certain keys, etc.

Then again for the price of a Rocket X you could probably buy a 16-24 core monster Windows machine that would decide almost as fast, maybe exactly as fast, and could also be used for other things as well.

Perhaps, but there is also something to be said for the size and weight factor.

 

[alexjentz]

Chris, what an interesting test! Thank you for posting. I'd like to hear RED's take on this.


Do you consider the Rocket close enough to use through the whole grading process, then disable it for the final render? Or do you feel think that would cause inconsistencies with certain keys, etc.


Perhaps, but there is also something to be said for the size and weight factor.

very good Question, Elliott i wonder that too. would at least be convenient to be grading along with the rocket without either transcoding to dpx first or having to have such a cpu beast as a machine.

 

[Robert Ruffo New]

Chris, what an interesting test! Thank you for posting. I'd like to hear RED's take on this.


Do you consider the Rocket close enough to use through the whole grading process, then disable it for the final render? Or do you feel think that would cause inconsistencies with certain keys, etc.


Perhaps, but there is also something to be said for the size and weight factor.

Agreed! Thank you Chris!

The problem with grading using Red Rocket is that indeed, the keys are very different, and even the gamma is different. suing1/4 res playback, but CPU rather than GPU is in fact much closer than Rocket/Full. Then you can sometimes do little pre-renders of tricky bits at Full to check. again, Rocket si just for off lien files for the editor (and sometimes a lifesaver for that)

As for size and weight - indeed bringing a tower on set is a pain, but we so far have avoided bringing any post on set. Especially with todays ever tighter budgets and smaller crews, the last thing I need is spending some of that money/time doing on set what should be done in an office afterwards. But if you must make off lien files on set, then a Rocket is worth it, but maybe even easier is simply an on-camera recorder like the Pix.

 

[Christopher*Seguine]

It appears that GPU and CPU are the same - and only Rocket is different. Has that been your observation? It seems the GPU mode simply uses the exact same math as CPU, but offloads this processing to GPU chips. Is that true do you think?.

Yes, I just rendered a big chunk of fx plates out with the latest 21.2 version that fixed EXR output. Doing a difference matte between CPU and GPU I currently see no difference is sharpness or color rendering. Rocket is still the same, not good.

Then again for the price of a Rocket X you could probably buy a 16-24 core monster Windows machine that would decide almost as fast, maybe exactly as fast, and could also be used for other things as well..

CPU decode is single threaded. For full resolution decode its miserably slow no matter how many cores you have. There is no reason it has to be this way, wavelet decode can be made multi-threaded, its not 1980 anymore. Do they really need to handicap it just to sell rockets?

GPU decode is currently limited to 16 threads, not sure why it is also being handicapped. I thought initially it was limited to 1 numa node, which would cause the thread limit on my systems. I've since tried a 2nd OS install with NUMA disabled, and still same 16 thread limit. Again no reason it has to be this way.

So, you can throw a lot of cores at it, but decoding a single r3d in a editing or color correction realtime situation, will not be faster.

For dailies, transcodes, etc - you can can run multiple simultaneous conversions and make use of your cores, but your out of luck when just trying to play back a single r3d.

I'm doing further testing, but so far if you have 2+ cpus disabling NUMA and Hyper-Threading gives best performance , 1990s style.

Do you consider the Rocket close enough to use through the whole grading process, then disable it for the final render? Or do you feel think that would cause inconsistencies with certain keys, etc.

There is a pretty big shift which would cause problems with your keys, etc - so no I don't recommend it.


I don't have very high hopes for the Rocket-X, multiple threads saying how amazing it is, yet I've asked nicely several times to post a simple still image comparison like I have done here, nothing.

 

[Jeff Kilgroe]

CPU decode is single threaded. For full resolution decode its miserably slow no matter how many cores you have. There is no reason it has to be this way, wavelet decode can be made multi-threaded, its not 1980 anymore. Do they really need to handicap it just to sell rockets?

The original REDCINE, in the days before the Rocket, was multithreaded and it scaled to about 8 threads rather well. After that, the laws of diminishing returns set in and it seemed like it was burning up more resources trying to schedule threads than execute them. The story goes with REDCINE-X is that they concentrated on optimizations for the Rocket and not the CPU. While it's nice that RED is working on GPU acceleration now, and it clearly has a lot of room to improve, I still find it strange that they didn't continue down the path of multithreaded CPU processing. Which is darn simple to implement with their own SDK. Or at least we can lock a frame processor to an individual thread.

I can also confirm that disabling of HT gives superior performance. But that is to be expected with the way the SDK tools are implemented and with this sort of operation. Still lots of stuff out there works this way and HT is just a cheat of loading

I've written a simple R3D player that is multithreaded, no Rocket, and it performs rather well. It was more as a test to keep myself familiar with the R3D SDK. I don't know if there's any reason to re-visit it and it'ss rather basic. Presumably, GPU support will be in the RED Player as we continue forward, if it's not already I really haven't checked it out.

 

[alexjentz]

Hi Everybody,

since our first Dragon is gonna land back in Germany soon, the decision of if or how many RED Rocket X's to buy is on the doorstep.

Did anyone ever since make a comparison with RED Rocket X vs Software / CPU Debayer?

thanks a lot, and sorry if the question ended up in 2 threads.

 

[Mike P.]

Jeff, do you have to disable HT in the bios, or do you just limit programs to 4 operations (and assume the physical cores are used first/foremost)?

 

[Mark Phelan]

Love these types of discussions, so very informative. Thank you for sharing!

 

[Bob Gundu]

From what Graeme has mentioned about the RR-X card, is that's its much more ahead in quality from the previous generation one (which was designed before he came aboard). I believe he has said that the software and hardware decoding now will be the same, unlike the RR-1.

 

[Blair S. Paulsen]

In theory, the RR-X will have enough grunt to match CPU precision and still be real time for 6K FF 30fps, perhaps even 48fps after more optimization. The last note I saw from Jarred indicated they were just starting to get the second of three registers into the game which would lead one to believe there is plenty of untapped potential in the X.

I think it will be a good investment for the projects I typically work on. Of course I wish it was fully optimized from jump, but even at half power I'm in. YMMV.

Cheers - #19

 

[Manfred Lopez]

From what Graeme has mentioned about the RR-X card, is that's its much more ahead in quality from the previous generation one (which was designed before he came aboard). I believe he has said that the software and hardware decoding now will be the same, unlike the RR-1.

I hope this is true. Do you remember in what thread was this mentioned?

 

[alexjentz]

In theory, the RR-X will have enough grunt to match CPU precision and still be real time for 6K FF 30fps, perhaps even 48fps after more optimization. The last note I saw from Jarred indicated they were just starting to get the second of three registers into the game which would lead one to believe there is plenty of untapped potential in the X.

Cheers - #19

In theory i believe it might too, but there might also be just algorithm limitations which would not allow it to match CPU quality, no matter how fast or slow it renders.

so only a real world test will show

 

[David Battistella]

From what Graeme has mentioned about the RR-X card, is that's its much more ahead in quality from the previous generation one (which was designed before he came aboard).

Graeme was at RED day 1, I don't think the rocket came out until about a year after the RED One.


battistella

 

[DJ Meyer]

When i finally get my RR-X i am planning to test it thoroughly against the K6000's and highest end CPUs.