GPU based DCP encoding

[carl]

That is the current plan, yes.

[CRogers]

Any news on the GPU accelerated encoding front?

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

[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

[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

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

[barber]

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

[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

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

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