Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
25th May 2015, 20:50 | #1 | Link | |
Registered User
Join Date: May 2015
Posts: 2
|
The x264 Dual CPU Conundrum
Hello everyone! I originally posted this in a few other places since there was a five day waiting period to make threads here... it put a very important project on hold, but having not found a solution to this problem I now get to ask those widely considered the experts. The slightest bit of help will be greatly appreciated because I know not everyone has this problem, but I also know I'm not the only one trying to fix it.
The post: Quote:
|
|
25th May 2015, 21:28 | #2 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Have a look at this thread, I think the problem there is similar to yours.
__________________
Groucho's Avisynth Stuff |
26th May 2015, 18:59 | #3 | Link | |
Registered User
Join Date: May 2015
Posts: 2
|
I appreciate the link, really I do, as I mentioned before any help is truly greatly appreciated. I've been going through it and another like it for a while now, and maybe it's hard for me to understand what's going on because his english didn't appear to be that good... but that thread actually made me feel worse. From what I gather he's networking multiple computers together in order to speed up an encoding job. Which is great, but also means we have the ability to network six machines together to help with an encoding but can't properly utilize the second CPU in the same machine.
I have some new information to share as well:
With as much research as I've been doing, there just doesn't seem to be any escaping the fact that a great amount of processing power is being thrown away. |
|
26th May 2015, 22:00 | #4 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Stop by #x264dev on Freenode IRC, you can directly talk to the devs there.
Dual CPU is a more difficult problem than a single CPU with tons of cores. x264 does support it, but isn't particularly optimized for high-end situations where memory pools are split, whereas x265 includes explicit support for NUMA pools (and AE probably does too). So if you have NUMA pools, you may be getting hosed by memory transfer latency and bandwidth, starving the CPUs of anything to encode; even if not, memory bandwidth is still a strong contender for the bottleneck. With NUMA, typically you would start one x264 per CPU, set its affinity to the cores on just that CPU, and lock it to use only the memory pool for that CPU. Unfortunately, if you're encoding a single stream you can't use two x264s. So far you're kind of guessing and grasping at straws, and I don't think your analysis is correct that it's ignoring a whole CPU. I'd strongly recommend installing XPerf (basic instructions here) and checking out this post for how to set it up to analyze the recording; with that you should have a much better idea of the real distribution and utilization in the system. A good free low-level analyzer particularly suited to memory latency analysis is AMD CodeXL, which does work on Intel as long as you only use Time-Based sampling. Unfortunately, Intel's VTune costs almost a thousand dollars. Unfortunately, there are no easy answers we can give you, so everything will be based on tedious tuning. Hopefully with some more data, we might be able to come up with some recommendations. |
Tags |
dual, streaming, twitch, x264, xeon |
Thread Tools | Search this Thread |
Display Modes | |
|
|