No hardware acceleration for Canon RAW?

Hi all,

Canon RAW CRM files are running very slowly on Linux (a few frames per second) with version 18.5.1. The same files on the same computer with the same DaVinci project play in real time on Windows.

Is there any component missing on Linux?

Thanks.

Same on 18.6 :\

I'm getting barely realtime performance with C4K 23.976 clips in Studio 18.6 on Windows 10 with an RTX 3060 12 GB.

Yes it's fine on Windows.

[Dwaine Maggart]

My crm sample is from a Canon C200, and is 4096x2160 at 23.98 and is 7.6GB and plays back in real time on an HD timeline on my Rocky 8.6 Linux system with Resolve Studio 18.6.

Can you share a link to a file that's not playing well for you, so I can test that?

Yes, sure: https://easyupload.io/myrq7m

Hello Dwaine,

Have you been able to have a look? The link expires in two days.

Thanks.

[Dwaine Maggart]

Yes, I've had a look. And with your file, I see similar behavior. I've asked the dev team to investigate.

Thank you!

I think I'm seeing the same thing.
I see virtually no GPU usage but all CPU cores are pinned at 100% ...

(18.6.1 on linux with CUDA RTX4070. The CRM clip is from Uli's benchmark project)

That same clip is playing smoothly here in an UHD timeline.
All cores, both CPU and GPU are around 30-40% if only playing that clip. With the demanding benchmarking effects activated, the GPU cores get maxed out and the CPU cores are not very active.

Getting back to the initial question: I doubt there is hardware acceleration for CRW on any system. But the SDK for Linux might be less efficient.

Is there any update from the dev team?

[Dwaine Maggart]

No update.

Adobe is adding Apple Silicon Acceleration for Cinema Raw Light Codecs. It's currently working the latest beta of Premiere Pro.

Is BMD aware that this is possible? Any chance they can implement as well?

Hi Dwaine, still no update in 2025?

Adobe is adding Apple Silicon Acceleration for Cinema Raw Light Codecs. It's currently working the latest beta of Premiere Pro.

That would be some optimisation for Apple's silicon, but those machines have specific hardware only for H.264, H.265 and ProRes.

Hi,

How could this topic get some love ? It's a pitty to have such good CODEC and no proper way to use it in linux, the performance is really terrible. I couldn't even find information on the canon CRM internal format, and there is no way it's not possible to achieve good performance on a desktop where a camera can do it.

This would so much of a good thing for both Blackmagic and Canon to have a usable RAW CODEC.

Please get some linux love here and fix Canon Raw Movie performance on DaVinci Resolve !

There is never going to be hardware acceleration as OP asks for.

This would require Intel or Nvidia to add silicon specific to Canon Raw like NV did in 50 series for H.265 4:2:2 and Apple has for PR. And the ROI for Canon raw would be absolutely zero.

Reading this thread, it does sound like the software decoding on Linux is slower than in Windows, which does seem like a Black Magic code problem they could solve.

I have used 8k raw from my R5 on Windows, it is slow. But I have not tried on Linux to know if it is even worse.

BM did apparently fix the Canon Raw ISO bug very recently, years after I reported it. It would be worth retesting decode speeds and see if anything else changed.

Isn't R3D from Red decoded on the GPU?

The issue might be Canon keeping things closed more than the need for new task specific hardware

Thanks for your feedback !

I'll test again on linux and come back to you (With some numbers)

Isn't R3D from Red decoded on the GPU?

The issue might be Canon keeping things closed more than the need for new task specific hardware

You got a point, while GPU implementation would be so cool, GOOD CPU would be fine.
Let's do the math with some lame SSE impletation
You need to weigth adjacant pixels, let's say 4 cycles, accumulate, let say 2 cycles, and scale let's say 2 other cycles. Let's add 8 cycles more just because we want to minor performance so that 16 cycles per pixel (Cache works well, you work with nearby data) and let's add 16 more again because I'm a moron. At 4Ghz, that's 166 Million pixels per second per thread. With 8 threads you have 1.3GPixel per second so 28FPS at 45MPixel per frame.

So with something like AVX proper implementation I'm sure we can reach 60Fps at 8k with a proper and rather genereic CPU implementation.

Isn't R3D from Red decoded on the GPU?

The issue might be Canon keeping things closed more than the need for new task specific hardware

Red wrote red code to be gpu accelerated.


Inviato dal mio iPad utilizzando Tapatalk

RED RAW is JPEG2000 which can benefit a lot from GPU decoding. Still bad format and overkill even today. New RED RAW is simple DCT based codec, like BRAW or ProResRAW etc. Efficient enough and a lot easier to decode. No need for crazy 10K$ accelerator

Hi, just tested on Resolve 20 beta, 8k30 RAW .CRM file from R5, on LinuxMint, Threadripper 7960 file local on a brand new M2 gen 5 drive, I get all 48 threads to 100% and it's clearly not smooth. I don't know how to mesure actual decode frame per second, I would guess something around 10-15.
Underwhelming.

Will try other formats like SRAW 8k and 4k from the R5mk2 when I got the time to qnd post results, if someone can tell me how to get real FPS counter it would be perfect.

I hope it helps.

In my experience the counter in the Color page is realistic.

Isn't R3D from Red decoded on the GPU?

The issue might be Canon keeping things closed more than the need for new task specific hardware

It looks like Linux isn't using the GPU for acceleration of the Canon CRM codec, but it is using the GPU on Windows, but not to same extent as R3D.

On Windows 8K24P CRM is using 75% CPU on an 8K timeline, but smooth playback/scrubbing even with dissolve transitions, it's a poor starting point though for that level of CPU to merely play the media, choosing the 1/2 timeline playback resolution and CPU use cycles between 15-30% giving lots of CPU headroom. Considering the OP's CPU is more than twice as powerful as mine it must indicate the GPU is playing no part at all in the decode of CRM on LInux.

Was using 33% of GPU for full resolution playback, 1/2 that for 1/2 resolution.

Hi, just tested on Resolve 20 beta, 8k30 RAW .CRM file from R5, on LinuxMint, Threadripper 7960 file local on a brand new M2 gen 5 drive, I get all 48 threads to 100% and it's clearly not smooth. I don't know how to mesure actual decode frame per second, I would guess something around 10-15.
Underwhelming.

Will try other formats like SRAW 8k and 4k from the R5mk2 when I got the time to qnd post results, if someone can tell me how to get real FPS counter it would be perfect.

I hope it helps.

Switch under 3 dots on editing page to "show all frames".

Hi, just tested on Resolve 20 beta, 8k30 RAW .CRM file from R5, on LinuxMint, Threadripper 7960 file local on a brand new M2 gen 5 drive, I get all 48 threads to 100% and it's clearly not smooth. I don't know how to mesure actual decode frame per second, I would guess something around 10-15.
Underwhelming.

Will try other formats like SRAW 8k and 4k from the R5mk2 when I got the time to qnd post results, if someone can tell me how to get real FPS counter it would be perfect.

I hope it helps.

It's still not fixed. No GPU acceleration at all.

I have no idea what Canon uses underneath CRM RAW files. They do have some compression, but they don't say anything about the technology used. They say "easy to decode", but this seems to be far from the truth. Resolve allows to choose 2 methods of handling Canon RAW, so looks like SDK does offer access to RAW pixels (after decoding). Still decoding is done using Canons libraries, so this will be out of BM control and they can't speed it up (same like in case of RED), neither they can "magically" add GPU acceleration for this step.
You can only improve debayering step, but this in Resolve is already fast and fine. Besides GPU acceleration makes sense only if codec can benefit from it, which heavily depends on codec design.

The question is why the SDK is implemented correctly in Windows but not Linux.

If it works better on Windows then there may be some issue with implementation or issue is in actual Canon's SDK itself, which is not equal for all OS systems.

https://developercommunity.usa.canon.co ... opment-Kit

This suggests it should work about the same for all OS. Note that Nvidia series 5.x is not officially supported/tested as per this document.