render time issue

[Johann Tür]

Hello,
first of all a great thanks to team developement !

I am a french colorist , you can check my work @ www.colorist.online

I have a big issue : RENDER TIME

On Dell t7500 2010 2x xeon 5680 3,33ghz 12cores 96gb ram gtx 780, it takes 5h (90% load cpu) to render 100mn 150mb dcp 5,1 ununcrypted : not so bad

BUT on z820 2013 e52680 3 ghz v2 20 cores 130 gb ram quadro k5200, which is 2x or 3x time faster than the dell on every application , same DCP takes more than 20 hours to render (5% load CPU) : a nightmare because the dell is busy sometimes

They both start for same content at about 8fps speed, and at about 10% job the z820 falls to 2fps and then 1fps... when Dell keep on doing good job @ 8fps

I tried to uninstall reinstall dcp omatic, clean files, checked driver, checked cpu ram and gpu load with occt 100%, I cant believe the z820 can't run normaly dcp omatic with 20 cores turbo 3ghz

Any suggestion ? Help !

system is windows 7 sp1

Thanks

[Carsten]

The 820 should indeed run MUCH faster. Actually, even the dual 5680 machine should perform faster than it does. I render scope features (bluray) in 2k in about 3-4 hrs on my dual XEON 5660 machine. Your's should even be slightly faster, at least if you stay in 2k.

You may need to save a log (I suggest you tick all log options under advanced prefs), and send it to Carl, he should be able to find out where the bottleneck is.

I assume you use the latest versions of DCP-o-matic? What are your thread settings in prefs for both machines? Is the 820 also a dual CPU machine, or is the 20cores you mention single 2680v2-10coreHT?


You may also try the SINTEL Benchmark. https://dcpomatic.com/benchmarks/contributing - I suggest you use that in a new project to create that log you should then send to Carl.

Maybe your problem is not the actual J2K encoding, but something between DCP-o-matic and your content. Are these two machines networked? Make sure you don't use encoding servers as long as you are testing.

When you open task manager in WIN7, how many core/thread load scales can you see? For a 10coreHT machine, there should be 20.

- Carsten

[Johann Tür]

Hi Carsten

Thanks for your reply, (edit : yes I use last "stable" version available 10/04/2018)

I was trying to renew test comparing dell and z820 (yes dual ten core so 40 ht), to send you logs

but everything went worst on both machine ... more than 30 hours undedless render time, I gave up after 10h remembering your post

about "content" problem" , so I tried with DPX instead of apple pro res 4444, and everything went fine : 2h30 to render on z820 full load 40 thread

As reliability is my prioryty I won't go further with prores and dcp omatic on windows.

I opened the log file and the line "unknown codec" sample 2 was very often written.

What's strange is sometimes it worked to render, sometimes never with prores.

By the way I have another question : about level scaling :

ProRes was video levels rec 1886 2.4 > fine dcp scaling > fine looking

DPX10b are full range with rec 1886 2.4 , will dcpomatic scale the same way the black and white level neither its is video source nor full range source to final XYZ 2.6 ?

I very appreciate your detailed response with leads me to the soluce : "content problem"

Cheers & thanks for your work !

[Carsten]

Hmm, makes some sense that this is caused by a Prores codec issue. How did you create that Prores in windows? Prores in windows is a bit special, as there is no public encoding codec for it. In Windows, I would try DnxHD, or Cineform. DPX should be fine, but yes, I guess you need to test the DPX parameters. I can only assume that DPX decoding in DCP-o-matic uses full range. I am pretty sure DPX is interpreted by DCP-o-matic as RGB full range and 2.4 gamma. Maybe Carl will comment. Have you noticed the video analysis window? This will help you check black and white levels.

Do you use Resolve to create these files?



- Carsten