TerryMasters
25th May 2015, 20:50
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:
I have a dual CPU setup and noticed it's only using one of them while encoding x264 video regardless of whether or not affinity is set or a threads flag is calling for it to use more cores. Is there something unique I have to do in order to get the x264 encoder to recognize the second CPU?
Edit- These guys seem to have had the same problem: http://www.servethehome.com/intel-xeon-l5640-60w-dual-core-processor-benchmarks-review-power/
Edit 2- Some information and findings below.
-----------------------------------------------------
The chips in question are two Xeon v3 series.
The problem occurs with both live streaming software such as XSplit or Open Broadcaster (aka OBS), as well as x264cli. It's my understanding that live streams are one pass encodings and as such can use less cores, but I'd be lying if I said it wasn't strangely coincidental that the less cores it may use just happen to be the exact amount left alone from processor two in tests both on my system and others (servethehome benchmark).
Through asking around, gathering data and trial and error I'm starting to piece together that something might be wrong with the way x264 handles multiple threads.
- The system in question houses 48 threads; 24 physical cores across two processors (12 a piece). By x264 standards, a default preset with multithreading enabled should autodetect the correct "threads" count by using (PhysicalCores)x1.5 - which in my case is 36. On my system, x264 autodetects and sets threads=48, despite only utilizing 24, and instead of the 36 it should have set the flag to.
- On occasion, x264 will autodetect and set threads=72.
- Disabling the only processor x264 is using allows the codec to properly run on the other, previously unused CPU just fine. Setting the affinity in Windows 8.1 Pro 64 to disable what would be just the HT cores on both processors (leaving 24 physical cores available instead of 48 logical) allows encodings to take place spread across both processors albeit with strange results - one CPU only topped out at 25% usage across 12 cores while the other CPU's 12 cores maxed out completely.
- The idea has come up that x264 may only utilize up to 24 threads, which would explain why only half my computing power is being used. This is not true, as the servethehome benchmark posted above shows the same problem with two 6 core CPUs - 12 threads are working the encoding while the other 12 remain idle.
- Another idea was tossed around that - while encoding does make an incredibly minimal impact on the second, seemingly unused CPU - it may actually be mistaking the entire secondary processor as one additional thread, which would explain the 1-2% usage increase across its cores during encoding.
- Yet another question that was thrown around is whether or not the encoder has enough to process - meaning that it's only using 24 threads because it doesn't need any others. This appears to be untrue, as the program being used to live stream reports "High CPU Usage!" and starts dropping frames when choosing a slower preset all the while still only utilizing one CPU - if it were a metaphorical lack of workload, the multithreaded aspects of x264 would have spread to the other unused cores when the preset slowed down, increasing it.
- The idea, as Kichigai states, that (servethehomes) "...comment was that the additional cores were under-utilized, which suggests that there could have been a bottleneck elsewhere in the system, such as SSD speed or decoding speed of the content to be transcoded" could be true, sans a few details: 1.) The live streaming application sends the encoding over a network specifically designed to handle a plethora of different encoding styles and bandwidths. This in combination with the local recordings should theoretically rule out a disk problem - and 2.) The decoding speed of the content would be through the data received from the capture card, in this case an Avermedia 1080p 60fps USB 3.0 device, yet the same problem occurs on Decklink cards - namely 4K Extremes - which are PCIE based devices designed to handle much more than 1080/60. Could it still be possible? Of course, but based on this data I don't believe it's likely.
This, along with new information I'm continuously debating is slowly becoming more and more supporting evidence that something in x264's current implementation may need to be fixed or changed, if at all possible, in regards to better supporting these systems. Unless there are other x264 dll's specifically catering to dual socket systems that I've just not been made aware of, this would imply that nearly half of the processing power in these machines is utterly going to waste. If there were someone I could reach out to that still works on and maintains this codec, I would love to share these findings with them in an effort to improve x264 (if need be). I'm currently researching multithreading in parallels - that this might be why these systems have problems - but the fact that "threads" doesn't override it/there isn't an option to un-limit them seems like something that was either overlooked or could be improved. Otherwise, without it, this could become confirmation that x264 cannot properly utilize the second CPU in a dual CPU system. I would truthfully hate to see that happen.
- ServeTheHome's 6-Core Dual Xeon Benchmark Utilization - http://www.servethehome.com/wp-content/uploads/2011/03/Handbrake-Task-Manager-Utilization-HDQ.png
- My personal 24-Core Dual Xeon Benchmark Utilization - Test 1: http://imgur.com/rXGvwat / Test 2: http://imgur.com/sYy0l70 (the first picture shows the last two threads of the first CPU being used properly, above the second CPUs threads being barely used at all. Only settings: preset=medium)
The post:
I have a dual CPU setup and noticed it's only using one of them while encoding x264 video regardless of whether or not affinity is set or a threads flag is calling for it to use more cores. Is there something unique I have to do in order to get the x264 encoder to recognize the second CPU?
Edit- These guys seem to have had the same problem: http://www.servethehome.com/intel-xeon-l5640-60w-dual-core-processor-benchmarks-review-power/
Edit 2- Some information and findings below.
-----------------------------------------------------
The chips in question are two Xeon v3 series.
The problem occurs with both live streaming software such as XSplit or Open Broadcaster (aka OBS), as well as x264cli. It's my understanding that live streams are one pass encodings and as such can use less cores, but I'd be lying if I said it wasn't strangely coincidental that the less cores it may use just happen to be the exact amount left alone from processor two in tests both on my system and others (servethehome benchmark).
Through asking around, gathering data and trial and error I'm starting to piece together that something might be wrong with the way x264 handles multiple threads.
- The system in question houses 48 threads; 24 physical cores across two processors (12 a piece). By x264 standards, a default preset with multithreading enabled should autodetect the correct "threads" count by using (PhysicalCores)x1.5 - which in my case is 36. On my system, x264 autodetects and sets threads=48, despite only utilizing 24, and instead of the 36 it should have set the flag to.
- On occasion, x264 will autodetect and set threads=72.
- Disabling the only processor x264 is using allows the codec to properly run on the other, previously unused CPU just fine. Setting the affinity in Windows 8.1 Pro 64 to disable what would be just the HT cores on both processors (leaving 24 physical cores available instead of 48 logical) allows encodings to take place spread across both processors albeit with strange results - one CPU only topped out at 25% usage across 12 cores while the other CPU's 12 cores maxed out completely.
- The idea has come up that x264 may only utilize up to 24 threads, which would explain why only half my computing power is being used. This is not true, as the servethehome benchmark posted above shows the same problem with two 6 core CPUs - 12 threads are working the encoding while the other 12 remain idle.
- Another idea was tossed around that - while encoding does make an incredibly minimal impact on the second, seemingly unused CPU - it may actually be mistaking the entire secondary processor as one additional thread, which would explain the 1-2% usage increase across its cores during encoding.
- Yet another question that was thrown around is whether or not the encoder has enough to process - meaning that it's only using 24 threads because it doesn't need any others. This appears to be untrue, as the program being used to live stream reports "High CPU Usage!" and starts dropping frames when choosing a slower preset all the while still only utilizing one CPU - if it were a metaphorical lack of workload, the multithreaded aspects of x264 would have spread to the other unused cores when the preset slowed down, increasing it.
- The idea, as Kichigai states, that (servethehomes) "...comment was that the additional cores were under-utilized, which suggests that there could have been a bottleneck elsewhere in the system, such as SSD speed or decoding speed of the content to be transcoded" could be true, sans a few details: 1.) The live streaming application sends the encoding over a network specifically designed to handle a plethora of different encoding styles and bandwidths. This in combination with the local recordings should theoretically rule out a disk problem - and 2.) The decoding speed of the content would be through the data received from the capture card, in this case an Avermedia 1080p 60fps USB 3.0 device, yet the same problem occurs on Decklink cards - namely 4K Extremes - which are PCIE based devices designed to handle much more than 1080/60. Could it still be possible? Of course, but based on this data I don't believe it's likely.
This, along with new information I'm continuously debating is slowly becoming more and more supporting evidence that something in x264's current implementation may need to be fixed or changed, if at all possible, in regards to better supporting these systems. Unless there are other x264 dll's specifically catering to dual socket systems that I've just not been made aware of, this would imply that nearly half of the processing power in these machines is utterly going to waste. If there were someone I could reach out to that still works on and maintains this codec, I would love to share these findings with them in an effort to improve x264 (if need be). I'm currently researching multithreading in parallels - that this might be why these systems have problems - but the fact that "threads" doesn't override it/there isn't an option to un-limit them seems like something that was either overlooked or could be improved. Otherwise, without it, this could become confirmation that x264 cannot properly utilize the second CPU in a dual CPU system. I would truthfully hate to see that happen.
- ServeTheHome's 6-Core Dual Xeon Benchmark Utilization - http://www.servethehome.com/wp-content/uploads/2011/03/Handbrake-Task-Manager-Utilization-HDQ.png
- My personal 24-Core Dual Xeon Benchmark Utilization - Test 1: http://imgur.com/rXGvwat / Test 2: http://imgur.com/sYy0l70 (the first picture shows the last two threads of the first CPU being used properly, above the second CPUs threads being barely used at all. Only settings: preset=medium)