Page 5 of 6

Re: GPU based DCP encoding

Posted: Sun Aug 01, 2021 9:28 pm
by carl
That is the current plan, yes.

Re: GPU based DCP encoding

Posted: Mon May 09, 2022 10:19 pm
by CRogers
Any news on the GPU accelerated encoding front?

Re: GPU based DCP encoding

Posted: Wed May 11, 2022 11:04 pm
by carl
None, I'm afraid. It's interesting to note, however, that nvidia have made some libraries for J2K decoding which we may be able to use (while hoping that nvidia are also working on some encoding libraries!)

Kakadu is also a possibility, but I don't know how much that would end up costing the end user.

There are still some practical difficulties. The first problem is that (I think) I would need to build for Windows using the Microsoft tools (rather than cross-compiling with mingw64) and that involves quite a lot of not-especially-fun work.

Re: GPU based DCP encoding

Posted: Thu May 12, 2022 10:45 am
by Carsten
Would it be possible to prototype an encoding solution for you, to find out what the actual benefit would be (overall conversion time)?

Because, e.g. Threadripper 5950X and M1/M2 performance has increased considerably, while GPU prices have grown to the insane.



- Carsten

Re: GPU based DCP encoding

Posted: Thu May 12, 2022 8:46 pm
by carl
Because, e.g. Threadripper 5950X and M1/M2 performance has increased considerably, while GPU prices have grown to the insane.
It's an interesting point - my guess would be that since claimed GPU performance is/was so far ahead of CPU it should still be better bang per buck. It's hard to be sure though.

I'm happy to talk to anybody who has a J2K encoding library (whether CPU or GPU) and see about integrating it into DoM. There are considerable practical hurdles but nothing insurmountable. It's not a massive priority for me but I think I have mellowed a bit on my previous IT MUST ALL BE OPEN SOURCE stance :P

Re: GPU based DCP encoding

Posted: Tue May 17, 2022 5:12 pm
by rl1983
I've demo'd another piece of software that uses GPU encoding for creating DCPs. It's absolutely worth it to incorporate it, even if DOM becomes a licensed software.

I ran two tests, encoding the same trailer with DOM, got 16.5FPS on my 5600x CPU.

Test 2, was on the software that uses GPU - 105-120FPS for encoding the same trailer. This is just a 1660 Super GPU, nothing top of the line.

The UI on that other software is horrendous, which explains the amount of errors we get when we receive DCPs authored with them.

Re: GPU based DCP encoding

Posted: Wed May 18, 2022 9:41 am
by barber
carl wrote: Wed May 11, 2022 11:04 pm None, I'm afraid. It's interesting to note, however, that nvidia have made some libraries for J2K decoding which we may be able to use (while hoping that nvidia are also working on some encoding libraries!)
The nvJPEG2000 Documentation does talk about encoding too! https://docs.nvidia.com/cuda/nvjpeg2000/userguide.html

Re: GPU based DCP encoding

Posted: Wed May 18, 2022 9:51 am
by Carsten
We had the idea in the past to implement GPU encoding only for the encoding server. It would be easy to sell just the encoding server as a small separate package commercially. It could be offered separately from the main open source distribution. And having GPU support only in the encoding server means no performance penalty, at least not within a single machine. Across a network, network saturation would hit a lot earlier, though. Licensing would also be a lot easier for a separate module not tied into the main development branch.

- Carsten

Re: GPU based DCP encoding

Posted: Wed May 18, 2022 7:27 pm
by rl1983
That's exactly the path I was looking to explore with GPU encoding. Having a GPU server in the IT room that can act as an encode server and have all workstations that need to make DCPs be on that network. It would probably require 10Gbit Ethernet, but that's easily available these days for a reasonable cost.

Re: GPU based DCP encoding

Posted: Thu May 19, 2022 3:05 pm
by carl
The nvJPEG2000 Documentation does talk about encoding too! https://docs.nvidia.com/cuda/nvjpeg2000/userguide.html
Wow - I hadn't spotted that (maybe it's new?) If that produces cinema-compliant codestreams (and that's quite a big "if") it could be the answer.