<div dir="ltr">Michael,<div>Adding --lookahead-threads 2 statically allocated two threads for lookahead. Therefore, the worker threads launched to work on WPP will 32-2 = 30 in count. We've found some situations in which statically allocating threads for lookahead was useful and therefore decided to expose it to the user. Please see if this helps your use-case and enable appropriately.</div><div><br></div><div>Now as far as scaling up for 8K goes, a single instance of x265 scales up well to 25-30 threads depending on the preset you're running in. We've found pmode and pme help performance considerably on some Broadwell server systems but again, that is also dependent on content. I would encourage you play with those settings and see if they help your use case. Beyond these thread counts, one instance of x265 may not be beneficial for you.</div><div><br></div><div>Pradeep.<div class="gmail_extra">
<br><div class="gmail_quote">On Fri, May 5, 2017 at 3:26 PM, Michael Lackner <span dir="ltr"><<a href="mailto:michael.lackner@unileoben.ac.at" target="_blank">michael.lackner@unileoben.ac.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I found the reason for "why did x265 use 30 threads and not 32, when I have 32 CPUs".<br>
<br>
Actually, it was (once again) my own fault. Thinking I know better than x265, I spawned<br>
two lookahead threads starting with 32 logical CPUs ('--lookahead-threads 2').<br>
<br>
It seems what x265 does is to reserve two dedicated CPUs for this, but then it couldn't<br>
permanently saturate them.<br>
<br>
I still don't know when I should be starting with that stuff for 8K content. 64 CPUs? 256<br>
CPUs? Or should I leave everything to x265? My goal was to be able to fully load as many<br>
CPUs as possible in the future.<br>
<br>
In any case, the culprit was myself.<br>
<span class="im HOEnZb"><br>
On 05/04/2017 11:18 AM, Mario *LigH* Rohkrämer wrote:<br>
> Am 04.05.2017, 10:58 Uhr, schrieb Michael Lackner <<a href="mailto:michael.lackner@unileoben.ac.at">michael.lackner@unileoben.ac.<wbr>at</a>>:<br>
><br>
>> Still wondering why not 32, but ok.<br>
><br>
> x265 will calculate how many threads it will really need to utilize the WPP and other<br>
> parallelizable steps, in relation to the frame dimensions and the complexity. It may not<br>
> *need* more than 30 threads, would not have any task to give to two more. Possibly.<br>
> Developers know better...<br>
<br>
--<br>
</span><span class="im HOEnZb">Michael Lackner<br>
Lehrstuhl für Informationstechnologie (CiT)<br>
Montanuniversität Leoben<br>
Tel.: +43 (0)3842/402-1505 | Mail: <a href="mailto:michael.lackner@unileoben.ac.at">michael.lackner@unileoben.ac.<wbr>at</a><br>
Fax.: +43 (0)3842/402-1502 | Web: <a href="http://institute.unileoben.ac.at/infotech" rel="noreferrer" target="_blank">http://institute.unileoben.ac.<wbr>at/infotech</a><br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/<wbr>listinfo/x265-devel</a><br>
</div></div></blockquote></div><br></div></div></div>